Bug #91303 documentation says you can use pure hash to store passwords
Submitted: 18 Jun 2018 13:46 Modified: 21 Jun 2018 1:55
Reporter: Z T Email Updates:
Status: Closed Impact on me:
Category:MySQL Server: Documentation Severity:S3 (Non-critical)
Version:8.0, 5.7, 5.6, 5.5 OS:Any
Assigned to: CPU Architecture:Any

[18 Jun 2018 13:46] Z T
The documentation for SHA1 (https://dev.mysql.com/doc/refman/8.0/en/encryption-functions.html#function_sha1) says (in part):

"You can also use SHA1() as a cryptographic function for storing passwords."

This is terrible advice. Naive application developers might believe the developers of the MySQL RDBMS know what they're talking about and consider the advice authoritative and develop insecure applications. This is like having a bug in example code and then being surprised this bug is copy-pasted into production.

Using any hash function (whether it's secure against collisions or not) directly to store passwords, even with long per-user salt, is extremely insecure, because password cracking rigs use multiple GPUs to check billions of combinations per second.

NIST sp800-63b says:

"Memorized secrets SHALL be salted and hashed using a suitable one-way key derivation function. Key derivation functions take a password, a salt, and a cost factor as inputs then generate a password hash. Their purpose is to make each password guessing trial by an attacker who has obtained a password hash file expensive and therefore the cost of a guessing attack high or prohibitive. Examples of suitable key derivation functions include Password-based Key Derivation Function 2 (PBKDF2) [SP 800-132] and Balloon [BALLOON]. A memory-hard function SHOULD be used because it increases the cost of an attack."

It is possible to build a secure password storage system using SHA1 or SHA2, but not by just adding salt and a loop. PBKDF2, the least secure password hashing method that is still secure, is not just a loop over SHA1. It is not memory-hard, which even NIST now says you should use because of GPUs.

People should use, in increasing order of preference: PBKDF2, bcrypt, scrypt, Argon2, all of which should also be tuned initially and from time to time as attacks improve.

MySQL/Oracle should not be recommending specific password storage methods to application developers.

How to repeat:
Read https://dev.mysql.com/doc/refman/8.0/en/encryption-functions.html#function_sha1

Suggested fix:
Please either remove this sentence from the documentation entirely or replace it with something to the effect of "use special password storage methods to store passwords, don't use plain hash to store passwords".
[19 Jun 2018 5:24] MySQL Verification Team
Hello Zeev Tarantov,

Thank you for the report and feedback!

[21 Jun 2018 1:55] Paul DuBois
Posted by developer:
Sentence removed. Thanks!