Announcement

Collapse
No announcement yet.

FESCo Says "Yes" To Fedora 35 Using Yescrypt For Hashing Shadow Passwords

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • FESCo Says "Yes" To Fedora 35 Using Yescrypt For Hashing Shadow Passwords

    Phoronix: FESCo Says "Yes" To Fedora 35 Using Yescrypt For Hashing Shadow Passwords

    The Fedora Engineering and Steering Committee has said "yes" to using Yescrypt for hashing shadow passwords with this distribution's next release. Using Yescrypt in place of SHA256/SHA512 should lead to greater security for new user accounts...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Well, how could you even say "No" to "Yescrypt"?

    Comment


    • #3
      Originally posted by brent View Post
      Well, how could you even say "No" to "Yescrypt"?
      Give it a second line funeral and bury it in a NOLA family crypt.

      Comment


      • #4
        Why weren't they using bcrypt before?

        Comment


        • #5
          Originally posted by stormcrow View Post

          Give it a second line funeral and bury it in a NOLA family crypt.
          Hi Lestat.

          Comment


          • #6
            Originally posted by brent View Post
            Well, how could you even say "No" to "Yescrypt"?
            Alexa, Disable Encryption

            I'm sorry, did you say, "New Table Kitchen"?

            Comment


            • #7
              Originally posted by microcode View Post
              Why weren't they using bcrypt before?
              I believe bcrypt was not an approved NIST secure hash.

              Comment


              • #8
                Originally posted by CommunityMember View Post

                I believe bcrypt was not an approved NIST secure hash.
                Oh god, was that why? Salted SHA is okay, but it is a lot less okay than any multi round alternative.

                Comment


                • #9
                  Originally posted by microcode View Post

                  Oh god, was that why? Salted SHA is okay, but it is a lot less okay than any multi round alternative.
                  That was the excuse Ulrich Drepper gave when he added SHA-256 and SHA-512 to glibc in 2007. It was a BS excuse though. He presented the situation as a false dichotomy: bcrypt XOR SHA-256/512. bcrypt was well proven by that point (introduced in 1999) and shipped in all the BSDs, Solaris, and a few Linux distros (I think SUSE was the most notable). Openwall has provided a patch set for glibc/shadow/etc since bcrypt was introduced. The license is compatible and it is straightforward to apply (I've done it to more than a few Slackware releases). There has never been a valid reason why bcrypt could not be in glibc in addition to SHA-256/512.

                  I suspect that Drepper created SHA-256/512 to prove some point about improving the existing MD5 scheme. When that didn't quiet the demand for bcrypt, he took it personally and dug his heels in. He was the glibc gatekeeper so password hashing on Linux was held back for over a decade.

                  Comment

                  Working...
                  X