12
$\begingroup$

According to this report : http://www.ecrypt.eu.org/csa/documents/D5.4-FinalAlgKeySizeProt.pdf
SHA2-512, SHA3-512, Whirlpool and Blake2b are hash functions that could be safe for the next 50 years.

For a system that will never receive security updates, to hash passwords, what of these 4 functions should I use for maximum security ?

$\endgroup$
  • $\begingroup$ 50 years? Are assuming that a functional quantum computer can or cannot be built in the next 50 years? $\endgroup$ – James K Polk Jul 25 '18 at 19:21
25
$\begingroup$

None. Cryptographic hashes are not directly suitable to store password hashes.

You should use a password hash (or PBKDF) such as one of the secure variants of Argon2 to store passwords, not a generic secure hash function. However, if you're working with passwords then not updating your security for 50 years is madness; there is a lot of debate on the security of passwords as it is. Passwords generally only deliver a certain amount of security, often in the range 30-50 bits. That already doesn't provide enough entropy, let alone in 50 years time.

You could also go for 128 bits of security and let people write down a randomly generated password / key instead (for instance as 32 hexadecimal digits). That way you could use a simple hash just to hide the password / key at rest. For this you could use one of the hash algorithms above; I'd go for SHA-3. However, your password management becomes more complicated. This can be solved by having people use a password manager that is secured with a less complex password and, hopefully, is not directly availability to hackers and which can be updated.

$\endgroup$
  • $\begingroup$ There may be other solutions that are applicable in your problem domain (which we don't know), but this is a relatively generic solution that should work. $\endgroup$ – Maarten Bodewes Jul 24 '18 at 13:26
  • $\begingroup$ Thanks a lot. I'm planning it for 50 years because the update process needs manual intervention (it's for a embedded system with no internet). I'm considering to switch to something else for passwords. However, If I need to get the checksum of a file, is SHA3 good enough ? (To prevent a file from being edited with a collision attack like with MD5 en.wikipedia.org/wiki/MD5#Security) $\endgroup$ – Myrage2000 Jul 24 '18 at 17:37
  • 9
    $\begingroup$ @Myrage2000 If you are designing a system like that, you really need a threat model. Then you demonstrate that you are safe against that threat model. Much of the time, generic advice is good and useful, but if you're pushing the limits of what can possibly be said about cryptography, it's worth your time to actually do a one-off analysis of your unique individual problem. $\endgroup$ – Cort Ammon Jul 24 '18 at 19:03
  • 4
    $\begingroup$ At the moment I am unaware of any cryptographic algorithm that has survived unbroken for 50 years, though RSA is getting up there. Someone with more experience may be able to correct me on that. Given our track record, you'll at least want to define what "safe" means to you on the 50 year scale. $\endgroup$ – Cort Ammon Jul 24 '18 at 19:06
  • 6
    $\begingroup$ @CortAmmon I'm unaware of any implementation of RSA or other cryptographic algorithm where serious bugs (or design decisions in retrospective) aren't found every other year. This seems to be the much larger issue at hand. Who cares if the mathematical algorithm is theoretically sound for eternity, if someone finds a serious issue in the implementation (or the used hardware) next year? (from this point of view it might even make sense to go with the most tested implementation of an older algorithm instead of going with the latest , coolest algorithm) $\endgroup$ – Voo Jul 25 '18 at 9:17
8
$\begingroup$

As Maarten writes you should use specialized password hashing algorithms and not generic hash functions.

But I would like to discuss the futility of planning for 50 years into the future. It's really impossible to know what the future so far ahead has in store for us. There could be all kind of changes we can't even imagine now.

Nevertheless our best bet for what will change in 50 years, is to look back 50 years ago. In the last 50 years everything changed. Cryptography was reinvented. We didn't even have DES 50 years ago, let alone anything we consider secure. We didn't salt passwords, we didn't have memory hard functions or side channel attacks or anything we consider essential now.

The oldest password hashing which gives some security is probably the unix crypt based on DES; it had a salt and iterations to slow it down. But it only supported 8 byte passwords, couldn't tune the iteration count, and had small salt. And that was 40 years ago.

Perhaps cryptography will plateau and our best crypto of today will hold. But I won't give you very good odds for that.

We may find specific weaknesses in whatever you chose, we may find broad new generic attacks. We may discover there are no one-way functions at all.

Planning crypto for 50 years in the future is a futile exercise.

$\endgroup$
  • $\begingroup$ Thanks. This is for a embedded system with no internet so it requires manual intervention to update it. This is why I'm planning it for 50 years. $\endgroup$ – Myrage2000 Jul 24 '18 at 17:30
  • 1
    $\begingroup$ nobody knows what will hold in 50 years. But you can be paranoid today and hope for the best. Use the best, make no compromises and you have a chance. With embedded you mayvjave to compromise due to performance. For password hashing argon2i is a safe choice(except for being a bit new) for file fingerptinting sha3. $\endgroup$ – Meir Maor Jul 24 '18 at 18:11
2
$\begingroup$

None of them should be used because none of them were ever made for the purpose of hashing passwords.

Cryptographic hash functions such as SHA-512, Blake etc. are completely safe to use for data integrity purposes, but are practically useless for hashing passswords, as they are trivially easy to bruteforce on commercially available GPUs, even PBKDF2, a common Key Derivation Function.

Planning 50 years ahead is not possible, as it is impossible to guess what kind of hardware will actually be available then. However, planning for the next few years is a feasible venture, and as such, it is best to use a hashing algorithm dedicated for passwords, such as Argon2, which won the Password Hashing Competition, or use another hashing algorithm that made it to the finals such as Yescrypt or Lyra2.

When you hash passwords to store them, always remember to do these two things:

---Never reuse salts, or any additional data used in the hash function.

---Set the parameters such that it makes bruteforcing the passwords infeasible, but practical to still use (i.e. number of bytes generated, iterations, memory size etc.).

It would also help to ensure that passwords are checked against a list of exposed passwords, such as through the API provided by Troy Hunt, and also implementing your own checks so that the passwords have enough entropy.

$\endgroup$
  • $\begingroup$ Thanks a lot. When you say "never reuse salts" : If I randomly generate a salt for each account, should I check that it his unique in the database ? Or can I suppose that the randomly generated salt will always be unique ? $\endgroup$ – Myrage2000 Jul 25 '18 at 10:08
  • $\begingroup$ Would it matter of some of the additional data were reused, if no two records feature the exact same combination of supplemental data? If e.g. the supplemental data contains a timestamp and an account identifier, an attacker who captured the states of the password record after each of two updates that occurred within the same second may be able to tell if the second update was setting the same password as the first, but I'm not sure in what contexts such information would offer any inappropriate benefit to an attacker. $\endgroup$ – supercat Jul 25 '18 at 15:55
  • 1
    $\begingroup$ @Myrage2000 You're welcome. When randomly generating a salt, you should use generate it with a high number of bytes to prevent any collisions from occurring. A good size would be to use 32 bytes (256 bits). With such a size you can have the piece of mind of never having to worry about a collision, and not have to go through the task of checking the salt against existing ones. $\endgroup$ – Azxdreuwa Jul 25 '18 at 16:29
  • $\begingroup$ @supercat The additional data should be randomly generated for each password and never reused just as the salt is, in order to retain its efficacy. I am unsure as to what situation would require reuse of the additional data if it could just be randomly generated each time. The attacker would not be able to find out if the same password was being used if there is some randomness thrown into the hashing through the use of salts, additional data etc. $\endgroup$ – Azxdreuwa Jul 25 '18 at 16:39
  • $\begingroup$ @Azxdreuwa: It's not always easy for user-level programs to ensure that any "randomness" they generate is truly independent from any other instance of the program that may be running elsewhere. By contrast, if part of the salt is deterministically guaranteed to be different for every account, that will guarantee that no two distinct accounts' salts will match perfectly. $\endgroup$ – supercat Jul 25 '18 at 19:43

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.