Using MySQL 'encrypt' / crypt() to store passwords?

Question

I've been tasked with deploying a FTP instance with a MySQL backend for storing user logins.

Looking online I found Pure-FTPD, which on paper is great. However documentation states it only allows these hashing / encryption options for passwords:

#MYSQLCrypt md5, cleartext, crypt() or password()

MD5 and cleartext fall outside the requirements, password() should apparently be avoided (according to MySQL documentation) which leaves crypt().

Usage of crypt() to insert a value into a database relies on 'encrypt', which in turn is a crypt() system call. See: https://dev.mysql.com/doc/refman/5.5/en/encryption-functions.html#function_encrypt

So come's the question, how secure is this encryption method to actually store sensitive data, wikipedia states that crypt() -

"Rather than encrypting the password with a key, which would have allowed the password to be recovered from the encrypted value and the key, it used the password itself as a key, and the password database contained the result of encrypting the password with this key."

Which seems great, however I can't seem to find any info on this 'password' database it speaks of, the inserted value also are stripped down to a max of 16 bits if I recall correctly, which really doesn't seem secure.

Any input on this would be appreciated, thanks!

Answer 1

If you read the documentation: SHA1, MD5 and MySQL password() are only supported for legacy reason and scrypt or crypt(3) are advised. However, that would not really answer your question, so let me emphasize which one I would choose.

crypt(3) This is Unix's password hashing (some call it encryption) function. This is a modified DES cipher that uses a 12-bit salt based on the system clock, for per-user diversification. The really downside of this function is that it takes only eight ASCII characters (equals 56 bit) as the key. That key is then used to encrypt a 64-bit string of 0 and the modified DES cipher. The output is again encrypted with the key and this procedure is repeated 25 times. The repetition was chosen to slow down dictionary attacks. However, cracking crypt(3) password hashes is not really a big deal and greatly depends on the password strength of your users. Bear in mind, this solution dates back to the 1970s and all modern Unix/Linux systems use modern hash algorithms, such as SHA-256 or SHA-512.

scrypt This method was developed by Colin Percival who identified that password hashing was predominately CPU-hard, but not memory-hard. The problem when a password hashing algorithm is only CPU-hard is, that the more CPUs are present, the quicker you can brute-force it. The limiting factor is memory and CPU power. Therefore scrypt consists of a series of functions that extend the CPU-hard approach by a memory-hard approach.

Conclusion If you have the option to choose for either password protection method, I would go for scrypt rather than crypt(3). The reason being that crypt(3) is actually deprecated already and scrypt offers more protection against brute-force attacks. However, it also depends on the number of users your solution should serve. Naturally, a CPU-,Memory-hard function will not only use more resources during brute-forcing, but also during normal authentication compared to functions which do not offer this.