3 ms·

Has there been an explanation as to why they were using DES? Gawker started in 2003, a year after DES was superseded by AES, and there were plenty of more secur

by gchucky 16y ago

Has there been an explanation as to why they were using DES? Gawker started in 2003, a year after DES was superseded by AES, and there were plenty of more secure algorithms being used at the time.

wccrawford 16y ago
As I pointed out on another post yesterday, there's no central repository for security information. Everyone is left up to their own devices to determine the current best practices. And then implement them. The fact that it was 'started' a year after AES doesn't really mean much. (And 'started' or 'launched'? Those are quite different.)
- pietrofmaggi 16y ago
  Sorry but I don't agree here. If you have to develop a secure solution you make some research and choose what you think is a good solution (and if it is something outside your field you study/ask). In 2001 I've to implement a secure solution for a mobile platform, I choose Rijndael (them picked by NIST for AES). My previous knowledge of encryption algorithm was near zero. And then if you make the wrong decision, on something important as security for a public website, over the years you iterate (come on, till 2003 nobody internally thought it was a must to fix this mess?).
  - ZoFreX 16y ago
    > If you have to develop a secure solution you make some research and choose what you think is a good solution (and if it is something outside your field you study/ask) If everyone did this we wouldn't have these discussions so often. The problem is that people think they know about crypto, and think they know what they're doing, and probably won't believe otherwise until they get smashed wide open like this. This applies to almost all areas of knowledge, it's just particularly damaging in crypto as it's arcane and very sensitive to changes, often in very subtle ways.
    - rahoulb 16y ago
      It's worse than that - I admit I know very little about crypto. So when it comes to implementing a password storage system I read up a bit, get confused, ask a couple of people and get different answers back. It's the "get confused" bit that's dangerous. As you say, the differences are quite subtle and (for me at least) when they are being explained make perfect sense, but ten minutes later have become an uncrackable cipher all of their own.
      - ZoFreX 16y ago
        I'm not sure what advice to give you. You commonly see advice to outsource your security, to other libraries, the idea being these are more likely to be correct than you. However, there have been some pretty high profile mistakes in common crypto libraries too! If there's anything specific you have in mind, I'd be happy to field questions (and hopefully other HN users will correct me in the event I'm wrong!)
        rahoulb 16y ago
        Cheers (that's why I love this place). At the moment I use Authlogic in Rails, which uses SHA512 by default (SHA512 is built into the Ruby core libs). But I also notice that it's quite easy to switch to bcrypt (using the bcrypt gem). Is it worth switching? Or at least using that as my default on new apps?
        ZoFreX 16y ago
        What is it being used for, and how is it being used? I'm guessing this is password hashes. Is rails using a unique salt for each password? Bcrypt is slower than SHA512, in fact it can be made to be very slow. This is actually ideal for password hashes, it doesn't matter if it takes your server 50 milliseconds to calculate a password hash but that would severely slow down an attack. It is important however that they are being used correctly. Either would be a good solution if properly salted.
gthank 16y ago
They were using a DES-based variant of crypt (see http://en.wikipedia.org/wiki/Crypt_(Unix)#Traditional_DES-based_scheme http://en.wikipedia.org/wiki/Crypt_(Unix)#Traditional_DES-ba...), not actually encrypting the passwords.
bl4k 16y ago
The devs were not using DES, per se, they were using crypt() and the default cypher: http://www.php.net/crypt http://www.php.net/crypt At the time they implemented this (~5 years ago) most PHP tutorials just pointed to either crypt or md5. The other cyphers and functions were either added later, were not in stable PHP branches at the time, and/or most common tutorials had not picked up on them. It is also a pain to port your password storage method

by gchucky 16y ago

Has there been an explanation as to why they were using DES? Gawker started in 2003, a year after DES was superseded by AES, and there were plenty of more secure algorithms being used at the time.

wccrawford 16y ago

As I pointed out on another post yesterday, there's no central repository for security information. Everyone is left up to their own devices to determine the current best practices. And then implement them. The fact that it was 'started' a year after AES doesn't really mean much. (And 'started' or 'launched'? Those are quite different.)

pietrofmaggi 16y ago
Sorry but I don't agree here. If you have to develop a secure solution you make some research and choose what you think is a good solution (and if it is something outside your field you study/ask). In 2001 I've to implement a secure solution for a mobile platform, I choose Rijndael (them picked by NIST for AES). My previous knowledge of encryption algorithm was near zero. And then if you make the wrong decision, on something important as security for a public website, over the years you iterate (come on, till 2003 nobody internally thought it was a must to fix this mess?).
- ZoFreX 16y ago
  > If you have to develop a secure solution you make some research and choose what you think is a good solution (and if it is something outside your field you study/ask) If everyone did this we wouldn't have these discussions so often. The problem is that people think they know about crypto, and think they know what they're doing, and probably won't believe otherwise until they get smashed wide open like this. This applies to almost all areas of knowledge, it's just particularly damaging in crypto as it's arcane and very sensitive to changes, often in very subtle ways.
  - rahoulb 16y ago
    It's worse than that - I admit I know very little about crypto. So when it comes to implementing a password storage system I read up a bit, get confused, ask a couple of people and get different answers back. It's the "get confused" bit that's dangerous. As you say, the differences are quite subtle and (for me at least) when they are being explained make perfect sense, but ten minutes later have become an uncrackable cipher all of their own.
    - ZoFreX 16y ago
      I'm not sure what advice to give you. You commonly see advice to outsource your security, to other libraries, the idea being these are more likely to be correct than you. However, there have been some pretty high profile mistakes in common crypto libraries too! If there's anything specific you have in mind, I'd be happy to field questions (and hopefully other HN users will correct me in the event I'm wrong!)
      - rahoulb 16y ago
        Cheers (that's why I love this place). At the moment I use Authlogic in Rails, which uses SHA512 by default (SHA512 is built into the Ruby core libs). But I also notice that it's quite easy to switch to bcrypt (using the bcrypt gem). Is it worth switching? Or at least using that as my default on new apps?
        ZoFreX 16y ago
        What is it being used for, and how is it being used? I'm guessing this is password hashes. Is rails using a unique salt for each password? Bcrypt is slower than SHA512, in fact it can be made to be very slow. This is actually ideal for password hashes, it doesn't matter if it takes your server 50 milliseconds to calculate a password hash but that would severely slow down an attack. It is important however that they are being used correctly. Either would be a good solution if properly salted.

gthank 16y ago

They were using a DES-based variant of crypt (see http://en.wikipedia.org/wiki/Crypt_(Unix)#Traditional_DES-based_scheme http://en.wikipedia.org/wiki/Crypt_(Unix)#Traditional_DES-ba...), not actually encrypting the passwords.

bl4k 16y ago

The devs were not using DES, per se, they were using crypt() and the default cypher: http://www.php.net/crypt http://www.php.net/crypt At the time they implemented this (~5 years ago) most PHP tutorials just pointed to either crypt or md5. The other cyphers and functions were either added later, were not in stable PHP branches at the time, and/or most common tutorials had not picked up on them. It is also a pain to port your password storage method