Develop anti-pattern-plaintext password

First, target: restore or Reset Password

Each password program will encounter the user forgets the password situation, most of today's programs through e-mail feedback mechanism to let users recover or reset the password. This solution has a premise that the service has a premise that the user can access the mailbox he left at the time of registration.

second, anti-mode: use plaintext to store passwords

A common mistake in this recovery password solution is to allow the user to request that the system send a message with a clear text password. This is a terrible vulnerability in database design and can lead to a range of security issues that may allow unauthorized people to gain access to the system.

　　1. Store password

First we design a table as follows:

　　

Similar to this table, we insert a record of the SQL statement as follows:

INSERT  into Account (Accountid,accountname,email,password) VALUES (+,'admin','[email protected]',' 123456 ')

It is not safe to use plaintext to store passwords or to pass passwords over the network using clear text. If an attacker is able to intercept the SQL statement you used to insert the password, they can get the password directly. This is done when the password is updated or if the user enters the correct password, and the same password is used, and the hacker can steal the user's password in the following ways:

• Intercepts packets on a network line that interacts with the client and server-side databases. It's much easier than you think. Many software can do this, for example: Wireshark.
• Search for SQL query logs on the database server. The premise is that hackers can access the server where the database resides, assuming they can actually log on to the server, and they can view the database execution logs with SQL statements.
• Reads data from the database backup file from the server or backup media. Is your backup file properly stored? Do you thoroughly clean up the data before you recycle or discard your backup device?

　　2. Verify the password

Most of the time, the authentication query I see is to place the AccountId and password two columns in the WHERE clause for matching lookups:

SELECT *  from  Account WHERE = ' Admin '  and = ' 123456789 '

When the account does not exist or the user enters an incorrect password, the entire query returns NULL. Your program cannot distinguish between an incorrect account or an incorrect password. It is best to use a query method that distinguishes between the two situations, so that you can choose the processing method appropriately based on the error.

For example, when you find that there are many failed login requests for the same account in a short period of time, you may want to temporarily freeze the account because this could be a malicious attack. However, the problem is that you use Query statements can not distinguish whether the user name is wrong or the password is wrong.

　　3. Send the password in e-mail

Since the password is stored in clear text in the database, you can easily get the password in the program:

SELECT  from  Account WHERE =  -

Then your program can be based on the user's request to send the password to the user's mailbox, the contents are as follows:

 from : xxx.com  to: admin@126. Comsubject:password request password for your account called "Peter" to remind you that the password is "123456  "Click the link to login to your account: http:///www.xxxxx.com/Login

Sending plaintext passwords through mail is a serious security risk. e-mail may be hijacked, recorded, or stored in many ways by hackers. Even if you use a secure protocol to view your messages, the services that send and receive mail are maintained by trusted administrators and are not guaranteed to be secure. Since e-mail is sent and received through the network layer, the data may be intercepted on other routing nodes. At the same time, if the user's e-mail is cracked, then the user's account password is also the downfall.

iii. identification of anti-patterns

Any program that can recover your password or send your password via email in plaintext or reversible encryption will inevitably make the anti-pattern of this article. If your program can obtain a user's plaintext password in a legitimate way, the hacker can do the same.

　　1. Rational use of anti-pattern

Not all programs have the risk of being attacked, and not all programs have sensitive information that needs to be protected. For example, an internal procedure that may only be accessed by a few reliable internal personnel may be sufficient for the authentication mechanism. In those informal environments, a simple login box is enough. Additional resumes a strong verification system may not be reasonable.

Iv. Solution: First hash and then store

　　1. Understanding the hash function

The original password is encrypted with a hash function, which refers to converting the input character to another new, unrecognized string function. With the hash function, even the length of the original input string becomes difficult to guess because the length of the string returned by the hash function is fixed.

At present, the SHA-256 algorithm is more reliable.

MD5 is a 01 popular hash function that produces a 128-bit hash string. MD5 is also proven to be weak encryption, so you'd better not use it to encrypt passwords.

　　2. Using hashes in SQL　　

The Account table is redefined below. SHA-256 is always a 64-byte string, so this type can be changed to a fixed-length char.

In SQL Server, a method is provided that allows you to invoke the usual hash functions at will: Hashbytes, since SHA-1 was the standard of the National Standards and Technology Association in the United States before 2010, the SHA-1 standard was phased out after 2010 years, Followed by SHA-225, SHA-256, SHA-384, SHA-512. So, in my SQL Server2008, there's no such support. The department only takes Sha-1,md5 as an example (and later):

--SHA1 SELECT hashbytes ('sha1','123') --MD5 SELECT hashbytes ('MD5','123')

　　3, to loads hash material

If you replace the original code with a hash string, and then the attacker gains access to the database (he turns over your bin and finds the discarded backup CD), he can still get the user's password by trial and error. It may take a long time to guess the password, but he can prepare his own database beforehand-storing the possible password and the corresponding hash string, and then comparing it to the hash string found from your database. As long as a user chooses a word that exists in the dictionary, the attacker can easily find the corresponding cipher text by searching the hash value on either side. He can even do it directly with SQL.

Suppose it has a dictionary table that stores many cipher strings and encrypted strings:

　　CREATE TABLE  VARCHAR(+-CHAR); 

Query statement:

SELECT A.accountname,h.password  from  as JOIN  as h  on = h.password_hasn

One way to defend against this "dictionary attack" is to add some spice to your password encryption expression. The specific method is to encrypt the user password into the hash function, and a meaningless string splicing together, even if the user chooses a dictionary exists in the word as a password, the string of the feed password is not very likely to appear in the attacker's hash database, You can see that adding a random string to the resulting hash value is not the same as the original value:

　　

　　each password should be provided with a different random string so that the attacker would have to create a new hash dictionary for each password. Then he will go back to the starting point, because it takes more time to crack the password in the database than to guess the difference.

The proper length of the seasoning should be 8 bytes. You need to randomly generate seasonings for each password. This prevents the hacker to crack the one almost equals to crack all.

A more elegant technique for recovering passwords from hashes is called a rainbow table, and its performance is surprising, but the introduction of random strings can also protect against this technique.

　　4. Hide the password in SQL

Now that you have a strong hash function to encrypt your password before you store it, and you use a random string to block the dictionary attack, you might think it's safe enough. However, the password will still appear in clear text in the SQL expression, which means that if an attacker intercepts a packet of network traffic, or logs an associated query statement to the wrong person, the password is compromised.

This type of disclosure can be avoided as long as the plaintext password is not placed in the SQL query statement. All you need to do is generate a hash string of the password in the program code, and then use the hash string in the SQL query. The advantage of this is that when the attacker intercepts the packet, it has no way of reversing the hash to the password he needs.

That is, after encrypting in C #, it is executed in the SQL statement.

In the network program, there is another place where attackers have the opportunity to intercept network packets: between the user's browser and the Web server, when the user submits a login form, the browser sends the user's password in clear text to the server side before the server can use the password for the hash described earlier. You can solve this problem by hashing the user's browser before sending the form data. But the problem with this scenario is that you need to get the same ingredient associated with the password before you do the right hashing, which is best done on the server side. Or, use a secure HTTP (https) connection when the browser submits the password form to the server.

Browser-side encryption once, the server side to add the seasoning re-encryption This method is also good.

　　5. Reset the password, not the recovery password

Now the password has been stored in a more secure way, but there is one more problem to solve, that is, to help the forgotten password of the user to retrieve the password. Now that the passwords stored in the database are hash strings instead of the original passwords, you cannot recover their passwords. You have no way to reverse a hash value faster than an attacker. However, you can allow users to gain access in other ways.

Scenario 1

When the user forgets their password and asks for help, the program sends a message with a temporary generate password to the user instead of sending it its own password directly.

The contents of the message are as follows:

From:adminto:[email protected] 126 . Comsubject:password reset you asked to reset your account password. Your temporary password is "admin123", after 1 hours, this password will not be used, click on the following link to directly login to your account and set your password: http://  Www.xxx.com/login

Scenario 2

Record this request in the database and assign it a unique token as the identity instead of sending a message with a new password

 　　 CREATE TABLEpasswordresetrequest (TokenCHAR( +)PRIMARY KEY, account_idintExpirationTIMESTAMP  not NULL, Foreighkey (account_id)REFERENCESAccount (account_id))SET @token =MD5 ('Admin' || Current_timestamp); INSERT  intopasswordresetrequest (token,account_id,expiration)VALUES(@token,123,Current_timestamp +INTERVAL1HOUR)

You can then include the token in your e-mail, or you can use another way to send the token, such as a text message, as long as you can send the message to the account owner who requested the password reset. Using this method, if a stranger illegally requests a password reset, the system directs the sender to send an e-mail to the actual owner of the account.

Password reset page temporary link message:

 from : admin to: admin@126. Comsubject:password reset you asked to reset your account password. After 1 hours, click on the connection below to change the password 1 hours later, this link will not be able to use http://www.xxx.com/Reset_password?token= F5KAJKJKDSJFS1DNJPOQW

When the program receives a request to reset the password page, the token value must exist in the password reset request table, and the execution's past point in time must be a future point in time instead of a past point in time, and the account_id of the line references the Account table, so This token is constrained to reset only one of the specified accounts.

Of course, if someone else visits this page, it can also cause problems. There are some simple ways to mitigate the risk, such as a very short validity period for this particular page, and the page will not show which account password requirements have been reset.

Develop anti-pattern-plaintext password