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.
(1)
(1)
(Score: 2) by JoeMerchant on Thursday May 24 2018, @02:00PM (4 children)
This is a big red flag saying: be suspicious of bcrypt and PBKDF2. Not that he's wrong, just suspicious.
🌻🌻 [google.com]
(Score: 2) by FakeBeldin on Thursday May 24 2018, @02:06PM (3 children)
As the fine article points out, bcrypt and PBKDF2 are "CPU hard" (see the article to make that precise).
Argon and scrypt are both CPU hard *and* "memory hard" meaning that you cannot easily trade off CPU time for memory.
That's why those two come higher recommended: they offer additional protection against time-memory trade offs, which bcrypt nor PBKDF2 do.
(Score: 2) by JoeMerchant on Thursday May 24 2018, @02:09PM (1 child)
He's making an easily verifiable and valid point about password length correlation to processing time.
The suspicious bit is when there are such a limited number of remaining "acceptable" software suites.
🌻🌻 [google.com]
(Score: 4, Informative) by JNCF on Thursday May 24 2018, @03:48PM
Argon2, scrypt, bcrypt, and PBKDF2 are not software suites, they're algorithms, and each have multiple implementations available. Your concerns about diversity are still valid, but less so, and at a different level.
(Score: 0) by Anonymous Coward on Thursday May 24 2018, @03:20PM
Doesn't that mean those two algos offer more potential for DoS attacks? Running out of RAM seems more like a DoS situation than high CPU usage.
Seems like the author is biased if he can claim that high CPU usage due to long passwords is DoS potential but give high recommendations to algos with high memory usage:
You can limit the password length to something manageable so there's no CPU DoS. But if you reduce the memory usage then where's the "security by obesity" advantage over stuff like PBKDF2?
(Score: 0) by Anonymous Coward on Thursday May 24 2018, @02:06PM (1 child)
So what's an end-developer?
Why does it feel like he's associating them with rectal excretions?
(Score: 3, Informative) by c0lo on Thursday May 24 2018, @02:21PM
A developer close to the retirement age.
How do you think the prospective employers are looking at your CV when you reach the end-developer stage?
(large grin)
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 4, Interesting) by FakeBeldin on Thursday May 24 2018, @02:20PM (6 children)
The danger here is relative. As the article points out (I accidentally read it before it became an SN post, don't hate me), shaXXXcrypt has the property that longer passwords take longer to hash. This leads to two issues:
- Someone can guess the password length if they observe the computation
- A long password hogs CPU - too many and you have denial of service.
The first one is treated (in the article) as not too worrisome. The second one is what would warrant the cry of "Danger Will Robinson!".
This is applicable in a specific use case: if you have many users using the system default password hashing. That's not going to be an issue for any desktop machine, so we're only worried about servers. (Maybe when you log in on Ubuntu the password hashing could've shaved of a few milliseconds off - big frigging deal).
But this doesn't apply to every kind of server, this issue applies to servers that have to deal with a lot of password hashing requests that would be rooted to glibc. I'm not sure what those would be, but if you use a standard, generic OS and default settings to act as any type of specialised server, you're nuts.
Case in point: consider an authentication server. If you're going through the trouble of setting up a dedicated machine for this, you might want to figure out how to configure it to do its job properly. In that process, you should figure this out.
Having said that: there are more secure alternatives whose running time is not dependent on password length, so there's really no need to use sha*crypt. So he has a point. But "dangerous" seems rather overblown.
(Score: 5, Interesting) by JoeMerchant on Thursday May 24 2018, @03:15PM
The long password DOS attack on an authentication server seems like a case of crying wolf while on the 32nd floor of a Manhattan office building... unlikely, and there are plenty of layers of protection to deal with such things.
First: how long does a password really need to be? I mean, we encourage: the longer the better, but is it hurting anything to declare a max length of, say, 1024 bytes (not bits)? If that's the max password length, then your attacker is limited to 64x normal password length (article mentions a block size of 16) loading on the authentication server - plus they're going to stick out like a sore thumb with these unusually sized passwords, not something that most attackers should try for if they want long term success in their efforts.
If the password is fed straight to a SHA256 or similar hash before processing with the rest of the library, that should equalize loading and preserve enough uniqueness between passwords. I think he mentions something along these lines in the article, so... is that all that's really required to use these "worrisome" libraries safely?
🌻🌻 [google.com]
(Score: 2) by FatPhil on Thursday May 24 2018, @04:37PM (2 children)
"Ulrich Drepper tried creating something [better than what already was there], and ended up creating something worse."
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 3, Touché) by LoRdTAW on Thursday May 24 2018, @05:17PM (1 child)
ARM is a carp architecture? Something fishy about that accusation...
(Score: 3, Funny) by JNCF on Thursday May 24 2018, @09:51PM
It's a riscy claim to make.
(Score: 2, Funny) by Anonymous Coward on Thursday May 24 2018, @05:13PM
Make your clients compute the hash and then send the result through an encrypted channel to be verified.
Like what? Why would you spend any of your own resources doing that computation?
(Score: 5, Interesting) by TheRaven on Thursday May 24 2018, @06:23PM
That's a feature, not a bug. Computing the hash for a single login is not very expensive in terms of total CPU resources, but attempting to brute-force a password is. The CPU cost acts to rate limit attackers. This is not just a nice benefit, this is something that is an explicit design goal for password hash algorithms.
sudo mod me up
(Score: 3, Informative) by Anonymous Coward on Thursday May 24 2018, @02:30PM
Just saw this in the article...
To be fair to Drepper, while OpenSSL is free software, the copyright license of OpenSSL is not compatible with the license of the GNU C library so in general it is not legally possible to use OpenSSL code in glibc. That's isn't NIH syndrome.
The author did not mention any other specific implementations but perhaps similar arguments would apply to others.
(Score: 1, Informative) by Anonymous Coward on Thursday May 24 2018, @02:35PM (3 children)
What's current best practice? Is Sha3-224 + salt suitable, is there some advantage in padding or do we do it like the "professionals" and use plain text (or rarely md5)?
(Score: 0) by Anonymous Coward on Thursday May 24 2018, @06:13PM (1 child)
you use fucking bcrypt like everyone who halfway pays attention does.
(Score: 0) by Anonymous Coward on Thursday May 24 2018, @08:32PM
bcrypt is not a cypher but you'd know that if you had been paying attention.
(Score: 0) by Anonymous Coward on Wednesday May 30 2018, @08:55PM
I think they like to pepper the hash as well as salt.
The reason is that salt is part of the database, so if someone hacks in they get the hash and the salt, so they can try to crack it.
If your pepper is part of the code base instead of the database, it might not end up compromised in such an attack.
(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]
(Score: 3, Insightful) by DrkShadow on Thursday May 24 2018, @05:25PM (4 children)
So.. the argument is that knowing whether the password is within a 16-character range if you can time the execution of that particular function call is bad. The next argument that longer passwords can lead to denial of service is bad. Thus use this thing that's fast.
First, hashing functions are _built_to_be_slow_!!!
Suppose everyone switched to scrypt. Now we have custom-build ASICS, insanely-optimized hardware, to do these computations. That Is Bad. It then becomes cheaper to check the whole search space and find the cleartext of a given cipher text. This is the specific reason why these algorithms are slow. This is also why we don't use a _single_ sha1 iteration to generate the password hash. (One could expect the password hashing function to be constant time for all password lengths -- once you hash, you take that hash and hash it again. You take that hash and hash it again. The hash output each time is the same length, so only the first iteration has a differing length and differing execution time. As that's not the case, the original password much be used each time, somehow, to modify the output hash. I haven't read that far into these functions. Again, this intentionally added time is to make it computationally too expensive to reverse the hash.)
The argument of password length as it increases, maybe not all software, but _much_ software will limit password length. I've seen a lot use 8, 12 character limits. (This isn't practical for a secure password.) Limiting it to the length of the hash, however, is eminently practical: if you pass a 32-character MD5 has to the md5 function, you can get as much entropy out the other side as if you passed 33 hex characters -- it's a hash, not compression. So limit password length to 32. For sha1, limit it to 160 characters. Etc. You can't reasonably get more entropy after that.
Choosing your hash by computational efficiency is a demonstration that the problem is not understood.
(Score: 0) by Anonymous Coward on Thursday May 24 2018, @06:16PM (3 children)
"maybe not all software, but _much_ software will limit password length"
closed source shitware, maybe
(Score: 2) by maxwell demon on Thursday May 24 2018, @08:01PM (2 children)
640 characters should be enough for anyone.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 0) by Anonymous Coward on Thursday May 24 2018, @08:57PM (1 child)
Well, 640 Chinese characters is 2/3 off an essay... And it's in Chinese so the hackers will ignore your account :D
(Score: 3, Funny) by RamiK on Thursday May 24 2018, @09:20PM
4 should be good enough for anyone: 正确 的 马 电池 订书针全
compiling...