Password-Based Key Derivation Function 2 is the gold standard to derive a key from a password (RFC 2898). Having a salt added to the password reduces the ability to use precomputed hashes (rainbow tables) for attacks.
Number of iterations can be adjusted over time to adapt to brute force capabilities.
Alternatives to PBKDF2 include bcrypt and scrypt.
"Qt Cryptographic Architecture (QCA) http://delta.affinix.com/qca/ aims to provide a straightforward and cross-platform crypto API, using Qt datatypes and conventions."
QCA will give us access to TLS, CMS, X.509, RSA, DSA, Diffie-Hellman, PKCS#7, PKCS#12, SHA0, SHA1, SHA224, SHA256, SHA384, SHA512, MD2, MD4, MD5, RIPEMD160, Blowfish, DES, 3DES, AES128, AES192, AES256, CAST5, HMAC(SHA1, MD5, RIPEMD160), PBKDF1(MD2, SHA1), PBKDF2(SHA1) and OpenPGP through plugin providers (dependent on OpenSSL and GnuPG) that we could use in the future to
encrypt databases
encrypt connection to remote databases
Let's use scrypt for client side KDF:
https://github.com/Tarsnap/scrypt/tree/master/lib/crypto
scrypt is already an IETF draft and should become an RFC soon: https://tools.ietf.org/html/draft-josefsson-scrypt-kdf-04
It is used by several cryptocurrencies such as Litecoin as proof-of-work hashing mechanism.
We also need to use the scrypt derived key to feed MySQL password() function because this password() hashing function is actually:
SELECT SHA1(UNHEX(SHA1(“this_is_a_random_string”))) pass\G
which is not a very GPU proof PBKDF...
Of course, on top of this, we have to implement TLS between client and server, as Qt5.6 allows us to do.
You can safely delete the old hashing function: QString Utils::cryptPassword(const QString &toCrypt)
Only old default sha1 (no prefix) and new Default SHA3_512 have ever been used to record passwords in FMF/FHIO. You don't need to take into account other hash algorithms for the transition to a sensible PBKDF
Suggestion made by @nm_s
See the first version of the issue on Google Code here: https://code.google.com/p/freemedforms/issues/detail?id=366&q=password
Password-Based Key Derivation Function 2 is the gold standard to derive a key from a password (RFC 2898). Having a salt added to the password reduces the ability to use precomputed hashes (rainbow tables) for attacks. Number of iterations can be adjusted over time to adapt to brute force capabilities. Alternatives to PBKDF2 include bcrypt and scrypt.
"Qt Cryptographic Architecture (QCA) http://delta.affinix.com/qca/ aims to provide a straightforward and cross-platform crypto API, using Qt datatypes and conventions."
The git of the project is actively maintained and updated: http://quickgit.kde.org/?p=qca.git
QCA will give us access to TLS, CMS, X.509, RSA, DSA, Diffie-Hellman, PKCS#7, PKCS#12, SHA0, SHA1, SHA224, SHA256, SHA384, SHA512, MD2, MD4, MD5, RIPEMD160, Blowfish, DES, 3DES, AES128, AES192, AES256, CAST5, HMAC(SHA1, MD5, RIPEMD160), PBKDF1(MD2, SHA1), PBKDF2(SHA1) and OpenPGP through plugin providers (dependent on OpenSSL and GnuPG) that we could use in the future to
Huge projects like https://github.com/bitcoin/bitcoin use OpenSSL PBKDF2 implementation. https://github.com/bitcoin/bitcoin/blob/master/src/crypter.cpp https://github.com/bitcoin/bitcoin/blob/master/src/crypter.h Bitcoin source code is high quality & highly peer reviewed (264 contributors, many more watching), I suggest using it.
Let's use scrypt for client side KDF: https://github.com/Tarsnap/scrypt/tree/master/lib/crypto scrypt is already an IETF draft and should become an RFC soon: https://tools.ietf.org/html/draft-josefsson-scrypt-kdf-04 It is used by several cryptocurrencies such as Litecoin as proof-of-work hashing mechanism. We also need to use the scrypt derived key to feed MySQL password() function because this password() hashing function is actually: SELECT SHA1(UNHEX(SHA1(“this_is_a_random_string”))) pass\G which is not a very GPU proof PBKDF... Of course, on top of this, we have to implement TLS between client and server, as Qt5.6 allows us to do.