Fedora 35 Looking To Use Yescrypt For Hashing User Passwords

[phoronix]

Phoronix: Fedora 35 Looking To Use Yescrypt For Hashing User Passwords

Adding to the list of planned improvements for Fedora 35 is switching to make use of Yescrypt for hashing of user passwords...

https://www.phoronix.com/scan.php?page=news_item&px=Fedora-Yescrypt-PW-Hashing

[polarathene]

Interesting how the resources are listing the benefits from the authors notes, but exclude disadvantages section.

There's no mention of Argon2id in the comparison either, perhaps due to date, but the author has been updating their comparison document on their github repo.

IIRC bcrypt does fair a bit better vs Argon2 on a GPU (I had a discussion on reddit with one of the PHC judges a while back about it and they laid out the math), they too were arguing that argon2 was weaker than bcrypt for password storage, but the original tweet(s) that have been referenced all over the place by that judge was a bit vague/bogus in the statement... argon2 was still plenty strong, and when you consider FPGA is more effective at bcrypt than GPUs (at least even the current nvidia RTX 3xxx series still doesn't have enough local per core memory for bcrypt 4KiB requirement bottlenecking perf) and cheaper (there's a company that specializes in this and blogs about their FPGA rigs price/perf against modern GPUs), argon2 ends up being stronger than bcrypt.

Plus argon2 is more flexible for how you want to balance the resources required to perform the workload. Since this is for offline login, and desktop usage? It can up the requirements a bit more that I'm doubtful it'd make any pragmatic difference using yescrypt? (nothing against yescrypt, the NIST justification is probably quite valid reason for it's choice / acceptance too)

In regards to being attacked, if you have a decent password policy (like say 64-bit entropy from getapassphrase.com, even 44-bit may be fine since a slow hash is in use), you're highly unlikely to find any attacker wasting the amount of time and money (if they can even afford to attack that) brute-forcing against entropy.

Still a welcome improvement over SHA512crypt imo!

[skeevy420]

Fedora now uses the yescrypt hashing method for new passwords. There are no visible changes nor impacts to the end-user. Users are recommended to change their existing passwords after upgrading.

Technically speaking, I'd say that being "less secure" by doing nothing other than an upgrade is a visible change that effects the user.

Would it be possible to add in a check during the upgrade that changes the existing password to something random and then that random password back to the existing one so users don't have to change their passwords to reap the benefits?

[edgmnt]

No, the system does not know the actual password to upgrade it to yescrypt, that's the point of the KDF.

[edgmnt]

The best they can do is prompt the user to forcibly change the password, even if it's the same one. And yeah, even that won't work as an unattended upgrade.

[skeevy420]

I'm thinking from a desktop perspective where there's likely only a single user using sudo and having that pw trapped and reused (if possible).

What about some sort of post-install hook that prompts a person to enter a new password for at least the account used and times out to default (no change) after 10-30 seconds if no input in inputted?

I imagine most Fedora users will RTFM and know what to do...but still...relying on user intervention seems flaky at best if you start thinking of terms of Debian Stable and Ubuntu users picking this up in the near future.

[jntesteves]

I'm thinking from a desktop perspective where there's likely only a single user using sudo and having that pw trapped and reused (if possible).

What about some sort of post-install hook that prompts a person to enter a new password for at least the account used and times out to default (no change) after 10-30 seconds if no input in inputted?

I imagine most Fedora users will RTFM and know what to do...but still...relying on user intervention seems flaky at best if you start thinking of terms of Debian Stable and Ubuntu users picking this up in the near future.

Come on, there's absolutely no reason to take the risk of general migration. Current password hashing is not insecure and is unlikely to become insecure in the next decade(s). A password is unlikely to still be relevant after that many years and if it is still relevant, it's the user's fault. There's little you can do to protect people who couldn't care less for security, and they are more likely to lose their password in some other manner in the meantime anyway.

[jntesteves]

I don't like the license situation on the reference implementation. scrypt source files in the codebase are pretty clearly BSD-2-Clause, but the new files use a "custom" license where the author has simply used the same BSD license but removed both clauses! I understand the author's probable view that he shouldn't care much what people do with his code, but inventing a new license to do that is counter productive and a way to fill lawyers pockets even more. If you really want people to be able to do anything they want with your code I'd advise to use a FSF- and OSI-approved license that does justs that, so it's clear to layman users they don't need to worry about it and we stop enriching lawyers. The https://unlicense.org/ is a great resource on how to do just that.

EDIT: This is just a small rant. Overall project seems solid, though.

[Jabberwocky]

Come on, there's absolutely no reason to take the risk of general migration. Current password hashing is not insecure and is unlikely to become insecure in the next decade(s). A password is unlikely to still be relevant after that many years and if it is still relevant, it's the user's fault. There's little you can do to protect people who couldn't care less for security, and they are more likely to lose their password in some other manner in the meantime anyway.

I won't say that there's absolutely no reason, but I agree there's no immediate dangers that are made public. Not even quantum algorithms... according to the expects which I am not.

Technically speaking, I'd say that being "less secure" by doing nothing other than an upgrade is a visible change that effects the user.

Would it be possible to add in a check during the upgrade that changes the existing password to something random and then that random password back to the existing one so users don't have to change their passwords to reap the benefits?

The theoretical answer response to the technically speaking part of your comment can be multiple pages long. I'm going to ignore that part.

Regarding the flow/workflow/process - IMO this is something GNU/Linux can improve on. If the distro is super, err I mean very, user friendly it can update an existing password with a new hash method without informing the user.

For "power-user" distros it could offer some options after first login:
A) Use existing password (this would typically rehash your existing password-login, it would probably require that your plaintext password is stored in RAM longer than usual)
B) Change password (If the previous method had severe problems or you are paranoid)
C) Do nothing (If you are concerned about bugs in new implantation)

I'm sure distros will choose to do this differently, which is a good thing IMO.

I doubt that many admins would need to update the passwords of all the users immediately... not wanting to wait for first login. There's interesting solutions to this problem too, some methods don't even require a plaintext password. We would probaby have to modify some of the shadow files definitions for that to work though.

Let's just hope that other service providers do the same in their backends. Most companies fail in this regard in one way or another. My friend's ISP printed a sticker on his router that was delivered to his house with his web-login-account password in plain text. Everyone makes mistakes, Google's plaintext GSuite problem wasn't that big afaik... but Linkedin no hashes on all ~164 million users and Facebook/Instagram plaintext password on allegedly millions of users. We can do better than that.

[skeevy420]

hreindl
Create a new account or ask the powers that be to unblock you. Nothing you post shows up. I only know you posted because you quoted me.