Application Security thinking series: How to Protect passwords for security

These two days are a bit blank. Please write more. There are too many [stories] involved in the previous article, so I will not keep up with them. I just want to explain what is easy for most people to understand, let's talk about it.
 
[Background]
In recent years, the background user information of some enterprises in China has been disclosed by hackers. I believe all of them have heard of it. This is just published. What if it is not released? How much else do you think about the amount of user data stored by many Chinese Internet companies? These are often the "surplus grain" of hackers. The losses caused by these events will not be sensational, in similar incidents, there are a lot of user privacy information, the most sensitive of which is the password itself. Today we will talk about how to protect the security of users' passwords for enterprise applications.
 
The word "security thinking" comes from my belief that these principles do not need to be memorized, but are written by your confidence after the formation of security thinking.
 
[Password protection principles]
1. Never save in databases, sessions, and this articlePlaintext Password, Temporary variable storage in the middle should be cleared in time after use
2. For a product running on the official product line, no one should have a channel to obtain the user password, including but not limited to product developers, product O & M personnel, and technical support personnel.
3. the user password is hashed only by sha2-256 or a later version of more digits, rather than Encryption by AES Algorithms
4. Any user's password must include but are not limited to: 1) long string Key can be configured; 2) a random string is dynamically generated when the user sets the password; 3) the user password itself
5. Never log the user's password in any form. Whether you want to debug the problem or collect user information, the password's plaintext cannot be touched.
6. Do not think that the above 1-5 blocks your business logic implementation, that is your implementation method is wrong, the above principles are correct
7. enterprise application systems must strictly log users' operations on user sensitive information.
 
Someone may ask, "Isn't account leakage caused by the following possible reasons?"
 
1) vulnerabilities at the application layer, such as SQL Injection, which may cause unauthorized data to be queried.
 
2) HTTP server (e.g. apache \ Tomcat ...) remote code injection and execution are caused by the buffer overflow caused by the program language used in implementation, and the buffer overflow caused by business logic, so that the database content can be directly screwed in the background.
 
3) remote code injection and execution resulting from buffer overflow and buffer overflow caused by business logic during implementation of the network operating system, so as to directly screw the database content into the background.
 
4) when the database server (e.g. MySql) is implemented, remote code injection and execution are caused by the buffer overflow caused by the programming language, and the buffer overflow caused by the business logic. Thus, the database content is directly screwed in the background.
 
......
Yes, the above is often the direct cause of database explosion, but here I suggest you think about these three concepts: the attacker, the victim, and the responsible person, for the above reasons, only cause 1) the responsible person is the product owner, and various server software providers and operating systems are often not directly maintained by the enterprise code. You can perform security settings through security settings and configurations, but what about its system? For enterprises that use products, the best principle is:Even if a whole system is moved away, I can protect user privacy and sensitive information to the maximum extent!
 
OK. Let's continue to interpret the above 7 Principles.
Principles1.This article is easy to understand. The clear code means that someone has a channel to obtain it. This person may be a friend now and may be an enemy in the future. Therefore, the place where the clear code and a password are the evil source.
Principles2.As I said just now, the hash password should not be restored to the original text through a simple reverse algorithm. If so, it is not encrypted for enterprise developers: there is no one to trust in protecting users' sensitive information. There is only the right method.
Principles3.I have been avoiding the word "encryption". These two words are easy to think of as simple as adding. Therefore, it is easy to habitually use encryption algorithms to encrypt and store passwords, in this way, the product implementers can easily obtain the user password through reverse methods.
Principles4.Configurable keys can effectively prevent product developers and testers from using the same method to Crack user sensitive information on the official product line in reverse ways, the purpose of the random Key is to make it difficult for the maintainers on the official product line to reverse Crack user information, more importantly, users with the same password in the user information table should not have the same hash value! How can we implement it? There must be some solutions and wisdom is needed ~ _~
Principles5.A common problem in many companies is that developers and testers often write a lot of information into logs for their convenience to facilitate debugging and problem tracking, all security measures have become futile. Never do this!
Principles6.This is to block the specific implementer's mouth. If there are principles, there must be implementation methods. If there is no straight line method, there may be curve methods. In short, there must be. The specific service logic of a specific product is specific. If there is no uniform method, you can unify it. I will tell you ~ _~, However, the overall idea is the same.
Principles7.Records sensitive operations (including but not limited to) by Enterprise Product administrators, maintenance personnel, and technical support personnel. It is quite meaningful for tracking major security events and eventually has a "Lock" mechanism, if the sensitive log cannot be written successfully, the operation cannot be executed. The log of the sensitive operation should be placed on a relatively independent server to prevent the log from being destroyed ~ _~. I have a bold conjecture: at least one of the database explosion events of many enterprises may come from within the enterprise, not necessarily from "hackers in the true sense ", do not attack me. I just say there is at least one possibility.
 
The process of application security is like a process in which you can master your applications from getting started with bicycles. When you first get in touch with a bicycle, there is usually a confusion: Why don't two wheels fall? They even questioned whether they could learn it. After you have learned it, you don't need to worry about it. Any kind of inclination to fall, you will be able to save money inadvertently, this is what you have understood and implanted into your subconscious. The application security thinking is also formed, but the process is much longer.If we learn any knowledge, what will ultimately benefit for life is not the knowledge itself, but its way of thinking.For example, Mathematics gives you the habit of thinking in reasoning, history gives you the habit of thinking in reflection, and philosophy gives you the habit of thinking through phenomena. After graduation from college for several years, if you are not in a related profession and want to take the test, how many points can you take the test? However, this does not mean that everything you have learned has been forgotten. In fact, the most valuable things are stored, that is, the way of thinking. The same applies to application security. We hope you can control application security as soon as possible!