Stories
Slash Boxes
Comments

SoylentNews is people

SoylentNews is powered by your submissions, so send in your scoop. Only 15 submissions in the queue.
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: 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?