Stories
Slash Boxes
Comments

SoylentNews is people

posted by chromas on Thursday May 24 2018, @01:24PM   Printer-friendly
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.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 4, Interesting) by FakeBeldin on Thursday May 24 2018, @02:20PM (6 children)

    by FakeBeldin (3360) on Thursday May 24 2018, @02:20PM (#683551) Journal

    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.

    Starting Score:    1  point
    Moderation   +2  
       Interesting=2, Total=2
    Extra 'Interesting' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   4  
  • (Score: 5, Interesting) by JoeMerchant on Thursday May 24 2018, @03:15PM

    by JoeMerchant (3937) on Thursday May 24 2018, @03:15PM (#683576)

    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)

    by FatPhil (863) <pc-soylentNO@SPAMasdf.fi> on Thursday May 24 2018, @04:37PM (#683609) Homepage
    The best bit of the article for me, as someone who's been accused of using a "carp" architecture (ARM) rather than the non-carp x86, was this bit:
    "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)

      by LoRdTAW (3755) on Thursday May 24 2018, @05:17PM (#683629) Journal

      ARM is a carp architecture? Something fishy about that accusation...

      • (Score: 3, Funny) by JNCF on Thursday May 24 2018, @09:51PM

        by JNCF (4317) on Thursday May 24 2018, @09:51PM (#683773) Journal

        It's a riscy claim to make.

  • (Score: 2, Funny) by Anonymous Coward on Thursday May 24 2018, @05:13PM

    by Anonymous Coward on Thursday May 24 2018, @05:13PM (#683626)

    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

    by TheRaven (270) on Thursday May 24 2018, @06:23PM (#683658) Journal

    - A long password hogs CPU - too many and you have denial of service.

    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