SoylentNews is people
SoylentNews
posted by
chromas
on Thursday May 24 2018, @01:24PM
from the 694a5b3e413a0ac1a7daaba2116966ea356ff40328b556ed14781f2a67e2e909 dept.
from the 694a5b3e413a0ac1a7daaba2116966ea356ff40328b556ed14781f2a67e2e909 dept.
Aaron Toponce demonstrates why he thinks that using sha256crypt or sha512crypt on current GNU/Linux operating systems is dangerous, and why he thinks that the developers of GLIBC should move to scrypt or Argon2, or at least bcrypt or PBKDF2. After going into a bit of analysis, he concludes that practically everything else should be avoided, especially md5crypt, sha256crypt, and sha512crypt and many others.
This discussion has been archived.
No new comments can be posted.
A Critique of sha256crypt / sha512crypt on GNU/Linux
|
Log In/Create an Account
| Top
| 28 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
sillema sillema nika su
(Score: 3, Interesting) by Anonymous Coward on Thursday May 24 2018, @03:10PM (3 children)
If you can claim that an algo where long passwords = long time = DoS issue then can't someone also say that those algos which require a lot of memory are a bigger potential DoS issue? Say some joker hits your auth server with 1000 concurrent auth requests you suddenly need 1000 x 16MB (as per scrypt default) extra RAM? Seems to me that a server that runs out of RAM is a more serious DoS issue than a server that runs slower from trying to handle long passwords especially when you can trivially reduce the maximum allowed password length to 1000 characters without too many users complaining.
Typically if an attacker has got access to the hashes they can often get the plaintext passwords anyway and/or do most/all of the transactions they want to do. e.g. the attacker breaks into a server and gets access to the database and in that database are the hashed passwords but also in the database is all the juicy data anyway. Don't forget most of the passwords are still the same as the ones floating around the internet 10 years ago... It's like breaking into a bank vault and finding the customer passwords stored there too. Yeah you might find a few extra passwords for your collection but the main thing is the loot and money.
Lastly yes security is important but remember in the real world so many service providers have stored passwords in plaintext and most people use easy to guess passwords. And when those passwords regularly go public the sky doesn't fall. Heck nothing much really happens, people go add a number to their passwords or something. For years in the USA the credit cards or bank routing numbers were all you need to transfer money, no need for passwords even. Some crimes were committed but the whole industry seemed to find the risks acceptable.
(Score: 2) by JoeMerchant on Thursday May 24 2018, @03:22PM (2 children)
One point to factor in is: secure memory vs general RAM.
🌻🌻 [google.com]
(Score: 0) by Anonymous Coward on Thursday May 24 2018, @03:35PM (1 child)
So it's an even bigger DoS problem?
(Score: 2) by JoeMerchant on Thursday May 24 2018, @04:18PM
If the attacker is overloading secure memory, then yes - it's easier to DoS because there's much less of it.
Follow on questions include: is secure memory even necessary in most situations? Instead of just drawing a pretty graph with a ramp on it, can you demonstrate a real-world attack scenario of any value? etc.
🌻🌻 [google.com]