Yescrypt – Scalable KDF and password hashing scheme
openwall.com
openwall.com
> yescrypt is the default password hashing scheme on recent ALT Linux, Debian 11, and Kali Linux 2021.1+. It is also supported in Fedora 29+ (and is recommended for new passwords in Fedora CoreOS) and in Ubuntu 20.04+.
I would not at all be surprised if future Ubuntu versions follow Debian 11 in making this the default, although I don't know their actual plans, since I don't see why Canonical would want to bother maintaining this particular delta from Debian.
The Drepper hash functions were already obsolete in 2007 at introduction, because they were worse for all criteria than the existing older hash functions (e.g. bcrypt from 1999 or PBKDF2 from 2000).
Replacing them with yescrypt (e.g. when libxcrypt is used instead of the older glibc functions), hardens the systems with minimal effort.
Yescrypt includes the standard PBKDF2 function, so there can be no argument that it might be less adequate for security certifications than the ad-hoc Drepper hash functions.
Other hash functions might be in fact better, but they are newer and they are not standardized yet, even if e.g. RFC drafts may exist, so organizations that want to follow standards may be reluctant to adopt them.
> Most notable for large-scale deployments is yescrypt's optional initialization and reuse of a large lookup table, typically occupying at least tens of gigabytes of RAM and essentially forming a site-specific ROM. This limits attackers' use of pre-existing hardware such as botnet nodes.
> yescrypt's other changes from scrypt additionally slow down GPUs and to a lesser extent FPGAs and ASICs even when its memory usage is low and even when there's no ROM, and provide extra knobs and built-in features.
> [...] computationally expensive (bcrypt, PBKDF2, etc.) and more recently also memory-hard (scrypt, Argon2, etc.) password hashing schemes have been introduced. Unfortunately, at high target throughput and/or low target latency their memory usage is unreasonably low, up to the point where they're not obviously better than the much older bcrypt (considering attackers with pre-existing hardware). This is a primary drawback that yescrypt addresses. > > Most notable for large-scale deployments is yescrypt's optional initialization and reuse of a large lookup table, typically occupying at least tens of gigabytes of RAM and essentially forming a site-specific ROM. This limits attackers' use of pre-existing hardware such as botnet nodes.
When the hash function needs 40 GiB of RAM, most consumer hardware bails out, which is what botnets usually are made up of. So that site-specific ROM is mainly a defense against running the hash checking on cheap laptops/desktops etc, forcing attackers to use server hardware, which might be less readily available to them.
Note that this advantage is far from the only improvements of yescrypt. Obviously it's not even configured to need 40 GiB of RAM in the settings where it's used as default password hardening algorithm for various distros.
Yescrypt seems to be the best choice for creating password hashes for the case of servers that may need to verify a large number of passwords simultaneously.
The reason is that computing the yescrypt hash requires a lot of work even when the hash is not configured to use much memory.
In the case of servers that must verify simultaneously many passwords, it may not be possible to configure the hash function to use a large memory, as that would limit the number of passwords that can be verified simultaneously.
On the other hand, for password-based key derivation applications, e.g. for file or file system encryption, where there is no reason to avoid configuring the password hash function to use a few gigabytes of RAM, other password hash functions are more appropriate than yescrypt, e.g. Argon2.
Yescrypt has some significant improvements over scrypt, but it still inherits from scrypt the use of the PBKDF2 key derivation function.
The PBKDF2 has some defects, but when it is used inside scrypt or yescrypt it is likely that this never has any practical importance. It just is ugly, because it is suboptimal compared to a key derivation function designed correctly.
PBKDF2 was chosen intentionally, because it is specified by various standards, so the systems using it are easier to be certified for security purposes.
While most NIST security standards are excellent, there are also cases when the standard solutions do not correspond in fact to the best practices.
Besides PBKDF2 and other suboptimal key derivation functions, another historical example is the NIST standard for the modes of operation of block ciphers, where all the modes of operation described in its 1980 edition were already obsolete at that date.
Is this needed? Assuming proper salting it is not feasible to crack SHA-2,blake2 etc hashes, let alone bcrypt and argon2 with thousands of iterations of them, is that not correct?
If you have a good password (say, 16 alphanumerics = 36^16) even if the password storage is literally MD5 you're fine, I can't get anywhere. Fancier password schemes make no difference.
If you have a bad password (say "password") then even if the storage uses an incredibly complicated GPU-hardened, ultra-impossible hash I can just guess "password" and I'm in, fancier password schemes still make no difference.
So these schemes are intensely focused on the middle - trying to shore up the quite-bad passwords, the people who don't actually have a random password, but they put a little work in. Maybe bad guys would need a million guesses to find their password, and if we can make that cost $1000 instead of $1 they won't bother?
I don't believe this justifies continued effort and instead we should throw those resources at getting rid of passwords.
I wanted a way to allow a temporary machine (new employer wants me to be productive from day one but can't ship me company hardware in the first week) to share data with my own systems. I almost added a password step, with a random secret known to the temporary machine and in my password store. And then I stopped myself and just gated the whole data sharing behind WebAuthn. Tap tap, temporary laptop and main systems are both signed in, done. No passwords.
When its about company property, you might not care too much about the consequences so a solution without passwords can be fine.
On the other hand, when it is about your personal data or devices, it may be unwise to trust anything else except the passwords stored in your head.
If I would design myself some kind of security token with a microcontroller or better with a FPGA, I could trust it, but I could never trust any kind of commercial device to be free of backdoors or defects.
So the most secure method for most people remains to memorize passwords.
In principle you can use a human memorable password to do something like the Socialist Millionaire's Protocol by hand, and thus escape any need for unanalysable hardware but the whole point of the SMP is that it's done in real time between humans, so you'd better get really good at maths and find a really patient correspondent to wait while you do it.
If you're typing the password into, say, GMail, your worry makes no sense.
From the UX perspective there's also the issue that adding a second of latency during login or registration could increase user drop off.
How many sites really incur the higher costs and higher latency?
It's not that shocking-- there is a lot less need for standardization of password hashing than protocols, and there were a lot of legitimate disagreements and ambiguous tradeoffs in the contest. (e.g. about things like timing sidechannels, the relevance of memory hierarchy, or support for other features like precomputed tables).