Stories
Slash Boxes
Comments

SoylentNews is people

A Critique of sha256crypt / sha512crypt on GNU/Linux

posted by chromas on Thursday May 24 2018, @01:24PM   Printer-friendly
from the 694a5b3e413a0ac1a7daaba2116966ea356ff40328b556ed14781f2a67e2e909 dept.

canopic jug writes:

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.
A Critique of sha256crypt / sha512crypt on GNU/Linux | Log In/Create an Account | Top | 28 comments | Search Discussion
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: 2) by FakeBeldin on Thursday May 24 2018, @02:06PM (3 children)

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

    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.

    Starting Score:    1  point
    Karma-Bonus Modifier   +1  
    Total Score:   2  

  • (Score: 2) by JoeMerchant on Thursday May 24 2018, @02:09PM (1 child)

    by JoeMerchant (3937) on Thursday May 24 2018, @02:09PM (#683547)

    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

      by JNCF (4317) on Thursday May 24 2018, @03:48PM (#683595) Journal

      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

    by Anonymous Coward on Thursday May 24 2018, @03:20PM (#683580)

    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:

    Still, the larger concern would be users creating a DoS on the CPU, strictly by changing password length.

    scrypt recommends a default RAM cost of at least 16 MB. I like to think of these expensive functions as "security by obesity".

    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?