. . . [out of order]
This is very important work and I wish you great success, but realistically even if it is a technical triumph, it will take many years, maybe decades, to see widespread adoption. In the meantime the world will continue to depend on password based systems and my focus has been on ways to make passwords work.
Because of the increased power of cracking rigs you describe, since 2014 my Diceware.com recommends 6 word passphrases for strong security. If generated per instructions given there, 6 words offers about 77.4 bits of randomness. At a trillion (2^40) attempts per second, that requires ~2^36 seconds or ~2,800 years for a 50% chance of cracking, a reasonable margin. Many people find such passphrases memorable if used frequently (happy users have contributed Diceware(tm) word lists in 28 languages). For very long term passwords (e.g. crypto currency wallets) I suggest 7 words or more.
But I agree that many users find passwords that long unacceptable. That is why I have to challenge with your rejection of slower digest functions. Resource intensive hashes are a way to restore some balance between users and crackers. Crackers have to a large extent taken advantage of progress in consumer electronics, namely the development of powerful but inexpensive GPUs for computer gaming. Ordinary cryptographic hashes such as the SHA family, are designed to be fast. If they are used to secure passwords, the crackers advantage only grows with time. Back in 1999, in proposing that password hashes be designed to also use large amounts of memory, I wrote ( https://theworld.com/~reinhold/HEKSproposal.html ):
''A key stretcher can also try to level the playing field against an attacker with the resources to build massively parallel search engines by utilizing as much as possible of the computing resources that the user already possesses. In the ideal limit, the best such an attacker could do would be to replicate the user’s computer many times.’'
To do that today would require key stretchers to employ the GPUs consumers already have, but that should be possible. And over time the number of iterations and amount of RAM required should increase to match the increase in available computing power. That’s why I suggest password systems include a version field with each password hash so passwords can be rehashed as more intensive hashes are introduced.
Yes, resource intensive hashing will impose a burden on organizations that offer password-protected services, but that may be the price for security.
On Nov 17, 2020, Kent Borg added:
Passwords are only readable on systems that are already quite broken.
Unfortunately, experience show that files containing password hashes are stolen all too frequently. I’ve also come up with a very different concept for storing password validation data securely using a very large (e.g. terabyte) secret that doesn’t require resource intensive hashing, which I call Rock Salt:(https://www.researchgate.net/publication/305849439_Rock_Salt_A_Method_for_Securely_Storing_and_Utilizing_Password_Validation_Data )
If a user’s machine is infected, the malware can harvest passwords directly as the user logs in to protected services. There are several password managers out there with good reputations. A reasonable compromise might be to use a password manager for the vast number of passwords whose compromise would cause limited damage and use strong passwords, backed up on paper, for ones most valuable accounts.
_______________________________________________ The cryptography mailing list cryptography AT metzdowd.com https://www.metzdowd.com/mailman/listinfo/cryptography