将哈希密码存储到Mysql

Question

I was researching about hashing and storing passwords to database on PHP.NET. This site said:

If you are for example storing the data in a MySQL database remember that varchar fields automatically have trailing spaces removed during insertion. As encrypted data can end in a space (ASCII 32), the data will be damaged by this removal. Store data in a tinyblob/tinytext (or larger) field instead.

which of this suggests are better? or may be I have to ask: Is one of them better? and if the answer is yes, which? and finally how should I store passwords to db using PDO. I thought I can write information to a blob row just like files, but if I get the values from input, which method or function have to used? Would you explain about please?

Answer 1

When storing hashed passwords, then whitespace removal is a non-issue:

• You never store the passwords themselves, but the output of a hash function instead.
• This hash function produces fixed-size output (or you are likely using a reversible encryption algorithm).
• The output of most hash functions is already fixed-sized plaintext^[1] that doesn't include any spaces. Otherwise, you are probably using a hash function not intended for password hashing.
• The fixed-sized salt is stored along with the hash output (Password hashing functions which are aware of salting usually output the salt with the hashed password).
• If you want to be flexible and be able to upgrade to a better hash function in the future, you also have to remember which hash function was used. It is recommendable to use plaintext^[1] for this information, which makes the complete record variable-length. RFC 2307 describes such a possible plaintext^[1] storage scheme.

Passwords should be hashed with a modern and proven key-stretching algorithm, but not with cryptographic hash functions like SHA-256 or MD5. Suitable algorithms include PBKDF2, bcrypt, or scrypt.

For example, hashing the string "pass phrase" with bcrypt and a new salt may produce

$2a$12$PuYHvYwgKeD.hQ1Dv6nLQuxUkv5zP3lYLPHqdMOzgwPVaGGSAs07u
`-----'`-----------·······                  ·········-------'
algorithm       random salt                    password hash
parameters

The whole string can be used as salt, as the actual password hash will be cut off and not be used as salt.

Recommended workflow for validating a login attempt:

1. The user provides an username and password. Be careful to handle Unicode normalization and encodings.
2. The hashed password is fetched from the DB based on the username.
3. The hashed password is parsed to determine the algorithm used.
4. The correct algorithm is invoked with the user password as input with the hashed password as salt.
5. If the two hashes match, then a correct password was provided by the user.

Recommended workflow for setting a new password:

1. If the user already exists, authenticate him.
2. Obtain a new password from the user. Take care to handle Unicode normalization and encodings. Give the user feedback on the strength of his password (but do not frustrate the user with silly requirements like forbidden characters or restrictive maximal lengths).
3. Create a new salt, which must not depend on user input like the password or user names.
4. Pick a strong password hashing function and hash the password with the new salt.
5. Update the DB to store the new password along with an identifier for the hash function.

Further comments:

• Encrypted data is binary data, and should not be stored as text (use a blob instead).
• Hashes are usually often represented as plaintext and not as binary data because text is easier to store.
• In many scenarios you can use OpenID instead of implementing your own authentication. E.g. Stack Exchange offers login with OpenID. Because I use this option, I never had to disclose a password to SE.
• I have no cryptographic background. Information Security is frequented by people who understand more of the matter.

---

^{[1] Here, “plaintext” means printable ASCII characters. It does not refer to the clear text of a password.}