LinkedIn and eHarmony Lesson: Salt or Die

Adding random bits to create a unique input to a one way function would have most certainly prevented the LinkedIn and eHarmony password fiasco last week. If this sounds complicated and expensive, it isn’t;  I explained it right here on Techblog  last year. It’s called “salting,” it’s been around for decades and it’s practically free both from the standpoint of implementation and performance.

If salting passwords improves security, doesn’t degrade performance, and is very inexpensive to implement than why didn’t LinkedIn and eHarmony do it?

I’m one of the 6.5 million people whose password was exposed that would love to know.

  • http://www.facebook.com/scibuff Tomas Vorobjov

    Sorry, but salting is not the answer. Unix has had salted passwords since 70’s and it never stopped anyone from cracking them. Salting the password doesn’t do much good when you consider how brute-force attack works – it is only useful against dictionary / tables. Today, when relatively simple CUDA implementation can try hundreds of millions of passwords a second no salt will ever be good enough.

    The real answer is stop using hashing algorithms such as md5 and sha1 (or any other of the sha family – sha256, sha512, etc) which are designed to be fast and, instead, use an adaptive algorithm such as bcrypt that introduces a work factor.

  • http://www.facebook.com/scibuff Tomas Vorobjov

    Sorry, but salting is not the answer. Unix has had salted passwords since 70’s and it never stopped anyone from cracking them. Salting the password doesn’t do much good when you consider how brute-force attack works – it is only useful against dictionary / tables. Today, when relatively simple CUDA implementation can try hundreds of millions of passwords a second no salt will ever be good enough.

    The real answer is stop using hashing algorithms such as md5 and sha1 (or any other of the sha family – sha256, sha512, etc) which are designed to be fast and, instead, use an adaptive algorithm such as bcrypt that introduces a work factor.

  • rgablog

    Hi Tomas,

     

    A post on Coding Horror from 2006 covering an email from John Callas (the
    CTO of PGP Corporation) argues almost exactly the opposite (http://www.codinghorror.com/blog/2006/07/brute-force-key-attacks-are-for-dummies.html ).
     

    There may be nuances here that I’m missing, or things may have changed in
    the interim, but that’s exactly the point – I’m not a security expert and I
    shouldn’t need to be.  As an application developer I’m bombarded with contradictory and difficult to follow advice from people who all claim to be experts.  Try reading any of the relevant threads on reddit and imagine what the average application developer can possibly take away from it.

    You can draw a line directly from that lack of clarity to the recent leaks of Gawker, BitCoin, LinkedIn, and eHarmony passwords.  Clearly I’m not the only developer who struggles with these issues.

    The same way that no reasonable person would suggest re-implementing
    jQuery, no one should consider rolling their own security measures.  But
    where are the standard, open-source libraries that relieve me, as an
    application developer, from making these kinds of critical mistakes?  Why,
    in 2012, do web sites still allow users to select “11111” as a password?  

    Is salting “the solution”.  No.  But is is part of a solution?  Yes.  These are the kinds of issues that I’m hoping to highlight with my posts.

  • rgablog

    Hi Tomas,

     

    A post on Coding Horror from 2006 covering an email from John Callas (the
    CTO of PGP Corporation) argues almost exactly the opposite (http://www.codinghorror.com/blog/2006/07/brute-force-key-attacks-are-for-dummies.html).
     

    There may be nuances here that I’m missing, or things may have changed in
    the interim, but that’s exactly the point – I’m not a security expert and I
    shouldn’t need to be.  As an application developer I’m bombarded with contradictory and difficult to follow advice from people who all claim to be experts.  Try reading any of the relevant threads on reddit and imagine what the average application developer can possibly take away from it.

    You can draw a line directly from that lack of clarity to the recent leaks of Gawker, BitCoin, LinkedIn, and eHarmony
    passwords.  Clearly I’m not the only developer who struggles with these
    issues.

     

    The same way that no reasonable person would suggest re-implementing
    jQuery, no one should consider rolling their own security measures.  But
    where are the standard, open-source libraries that relieve me, as an
    application developer, from making these kinds of critical mistakes?  Why,
    in 2012, do web sites still allow users to select “11111” as a password?  

    Is salting “the solution”.  No.  But is is part of a solution?  Yes.  These are the kinds of issues that I’m hoping to highlight with my posts.