Gawker used encryption incorrectly. The odd choice of archaic DES encryption meant that the passwords they saved were all truncated to 8 characters. No matter how long your password actually was, you only had to enter the first 8 characters for it to work. So much for choosing a secure pass phrase.
This analysis is roughly 165 degrees misguided. Yes, the archaic password hash Gawker used prevented Gawker users from taking advantage of long passphrases on Gawker properties. But Gawker's properties were completely compromised anyways, so even an uncrackable passphrase wouldn't have helped you.
Meanwhile, that same archaic hash mitigated the compromise of all their password hashes, such that if you actually used a passphrase, it can't definitively be cracked from those hashes (there are obviously infinitely many passphrases that could hash to a given crypt(3) hash, only one of which would be your phrase).
Can you please elaborate on this? Exactly how did it prevent you from using a longer password? The best I can google are problems with DES ECB which encrypts in 64bit blocks but this would still allow for longer passwords, would it not? What am I missing?
Gawker saved passwords. You should never, ever store user passwords. If you do, you're storing passwords incorrectly. Always store the salted hash of the password -- never the password itself!
What? No... Gawker stored hashes.
EDIT
It really galls me that Jeff can make an entire post around such an easily verified and debunked lie. Was he too lazy to check? Does he know what DES3 crypt is/does? Or did he think it would simply look good as the first of his three points in order to make a sensational story?
Gawker really doesn't deserve the trash talk they're getting, their db architecture was far more sound than a lot of others out there... and, as Thomas points out, their use of "archaic" hashing techniques is in some ways a blessing. Their db designers definitely get a "PASS" even if they didn't use something like bcrypt which would have given them an A++ on this assignment.
Careful; DES3 is one shorthand for Triple DES, and DES crypt(3) (what they used) is the DES-based hash documented in section 3 of the Unix man pages. =)
Does the need to post a comment on Gizmodo really justify polluting the world with yet another username and password?
Let me see if I understand this logic correctly: password reuse is a critical internet problem because it puts all of your sensitive stuff into one key, your re-used password.
And the way to address this problem is to put all of your sensitive stuff into one third party whom we trust more, for purposes of our conversation we can just call them "the monopolist".
I don't think so. How about a distributed password system where I personally own the code and it kicks off a unique key for me for every web site I sign up to? After all, I've gotten pretty good about carrying around important things in my life. I use something called a wallet. The concept has been working fine for thousands of years. Whereas the idea of having somebody else keep secrets for folks really doesn't have that great of a sterling track record, as the Gawker situation shows.
This was a great article in that it's starting to show people how screwed up things are. But the conclusions (to me) seem all out of whack.
> And the way to address this problem is to put all of your sensitive stuff into one third party whom we trust more, for purposes of our conversation we can just call them "the monopolist".
You're missing the point. Giving out your password to a number of sites is as secure as the least secure of those sites. Giving it to a single third party still poses its problems, but is a much safer bet statistically.
> […] all of your sensitive stuff into one third party […]
You can designate any OpenID provider, including yourself. In such case DNS and optionally Certificate Authorities are only 3rd parties that have to be trusted (and if you can't trust these, you shouldn't be using the Web).
While I do agree with the sentiment of the article, as a developer I see it as a risk to hand over user authentication to a third party. Once I do that, I'm subject to their terms of service (which usually say 'we can do anything we feel like, any time we want'), their outages, and their bad business decision (What happens to all the Facebook connect accounts when Facebook goes bankrupt?).
Would I even trust Google to handle Authentication? Maybe, but remind me again how I contact Google Tech Support when my authentication mysteriously stops working?
On the other hand, I had left comments on Gizmodo using Facebook Connect, so from a user perspective it worked out well for me.
OpenID delegation is useful for this purpose. If you have any domain you can use it as your OpenID and specify it to delegate the actual authentication to another service provider, that you can change at any point. I used to use MyOpenID, now I use Google, but it's the same login.
> Let's say you have good old traditional username and passwords on 50 different websites. That's 50 different programmers who all have different ideas of how your password should be stored. I hope for your sake you used a different (and extremely secure) password on every single one of those websites. Because statistically speaking, you're screwed.
A great reason to use a password manager, like LastPass. I started using it ~1 year ago, and now each of my web logins has a different password. It's just one key combo to generate a new random password and insert it into the password field when signing up at a new site.
Of course, you do now have to trust LastPass! I do, and it's fantastic the difference it makes in these situations. No sick feeling in your stomach, no rush to change passwords everywhere, a few clicks and the problem is solved. Extra credit: use their security challenge to verify you're not using the same password on more than one website: https://lastpass.com/?securitychallenge
- I have a text file encrypted with GPG that contains my list of passwords.
- I open it in Emacs like any normal file.
- GPG is integrated to Gnome so I get a nice askpass dialog even from inside Emacs.
- I've configured Gnome to store the decrypted key for a few hours (or until suspend) and ask me anytime the cached passphrase will be reused, to avoid typing my long passphrase everytime I need to look up a password.
- Emacs also knows how to encrypt the file transparently when I've made changes and just save the buffer in Emacs.
- My swap partition is encrypted via TrueCrypt and so is my /home.
Personally I am going to use a super weak password on most sites from now on with the understanding that anybody may hack it. 90% of sites it doesnt matter anyway. Then I can focus on the rest,which actually matter to me.
I've been doing this for years. I have two categories of passwords, and for any site I don't care about it gets one of my weak passwords. But even still, I believe I am going to switch to 1Password or something similar.
I did almost exactly that and I've still been bitten by this.
I had a weak password like 99beers that I've used for many years for the 90% of sites that don't matter. I started to transition to something like adding the first letter of the site name plus one to the beginning, so ycombinator.com would be z99beers. Still not strong, but I thought it reduced the risk if one site was compromised.
But since this compromise has been so large and well-publicized, I've gotten locked out of several sites that do matter, apparently just based on being in the Gawker dump. Since my email has never been compromised, this isn't a big deal, but it's a hassle.
Now I'm making a serious effort to apply LastPass and random passwords to everything.
poor man's password manager: select one strong password that you are able to keep in mind. Then for every site you use, set the password to what is the output of:
echo "strong_pass:sitename:strong_pass" | sha1sum
Note: if you are using mac os x use "shasum" instead of "sha1sum".
Make sure to don't expose your secure password of course.
It's also a good idea to use a completely different strong password just for email.
p.s. it's worth to note that since there are tons fo SHA implementations for Javascript it's possible to build all this as a web application where all the business happens in the client.
The web app will just allow you to add a number of site names so that you don't have to type the site name by hand all the times.
Btw the world would be a better place with all the auth cookies set to expire on 2036...
Unfortunately some crappy site is going to thwart such an effort. "bzzz! you can only use 12 chars in your password" or "you have to use a symbol/uppercase letter" or some other lunacy. le sigh
This is not a great password manager function; the reason is, losing your sha1sum password gives the attacker enough information to mount a very, very fast brute force attack against "strong_pass" as long as they know the "sitename".
A basic property of a password manager system should be that the loss of any password doesn't give attackers any information about other passwords; yours potentially concedes the "master secret" that animates all of them.
SuperGenPass (http://supergenpass.com/) does that in a way that is more likely to generate strong passwords honored by sites (e.g., multiple cases, punctuation, etc.). It comes both as a bookmarklet, and, if you don't want to use that, a mobile version (http://supergenpass.com/mobile/) that you can store somewhere safe so it doesn't even hit the internet (e.g., I store it on my Dropbox account so I can use it on my phone). Works great.
this is already available for the major browsers as an extension; try googling for "pwd hash" (from stanford) and "password hasher". also, as was noted in another comment, this is currently being discussed in another thread
I'd much rather depend on 50 strong passwords than 1 strong password to protect my online presence. Depend on Google, FB, etc. and when that 1 site or auth protocol is cracked ALL your logins are compromised. By spreading the risk around you are better protected from these kinds of issues.
"The short answer is that OpenID is the worst possible 'solution' I have ever seen in my entire life to a problem that most people don't really have. That's what's 'wrong' with it."
> Gawker saved passwords. You should never, ever store user passwords. If you do, you're storing passwords incorrectly. Always store the salted hash of the password -- never the password itself!
Uh, no? They did save the hashed+salted version. The only problem is that they used crypt, from 20 years ago, instead of something like bcrypt.
Is there a space for some startup to just offer an internet driver license. That would be all they do, no ulterior motive, just identity service.
Rock Solid Security + Developer Friendly API = Win?
There are probably adoption issues and centralized authority fear. It seems though that other things have consolidated nicely (a ton of comments use Disqus now), maybe its time for someone to create a startup that solves this very real problem.
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.
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.)
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
[+] [-] tptacek|15 years ago|reply
This analysis is roughly 165 degrees misguided. Yes, the archaic password hash Gawker used prevented Gawker users from taking advantage of long passphrases on Gawker properties. But Gawker's properties were completely compromised anyways, so even an uncrackable passphrase wouldn't have helped you.
Meanwhile, that same archaic hash mitigated the compromise of all their password hashes, such that if you actually used a passphrase, it can't definitively be cracked from those hashes (there are obviously infinitely many passphrases that could hash to a given crypt(3) hash, only one of which would be your phrase).
[+] [-] mrcharles|15 years ago|reply
[+] [-] ComputerGuru|15 years ago|reply
What? No... Gawker stored hashes.
EDIT
It really galls me that Jeff can make an entire post around such an easily verified and debunked lie. Was he too lazy to check? Does he know what DES3 crypt is/does? Or did he think it would simply look good as the first of his three points in order to make a sensational story?
Gawker really doesn't deserve the trash talk they're getting, their db architecture was far more sound than a lot of others out there... and, as Thomas points out, their use of "archaic" hashing techniques is in some ways a blessing. Their db designers definitely get a "PASS" even if they didn't use something like bcrypt which would have given them an A++ on this assignment.
[+] [-] tptacek|15 years ago|reply
[+] [-] ZoFreX|15 years ago|reply
[+] [-] algorias|15 years ago|reply
[+] [-] DanielBMarkham|15 years ago|reply
Let me see if I understand this logic correctly: password reuse is a critical internet problem because it puts all of your sensitive stuff into one key, your re-used password.
And the way to address this problem is to put all of your sensitive stuff into one third party whom we trust more, for purposes of our conversation we can just call them "the monopolist".
I don't think so. How about a distributed password system where I personally own the code and it kicks off a unique key for me for every web site I sign up to? After all, I've gotten pretty good about carrying around important things in my life. I use something called a wallet. The concept has been working fine for thousands of years. Whereas the idea of having somebody else keep secrets for folks really doesn't have that great of a sterling track record, as the Gawker situation shows.
This was a great article in that it's starting to show people how screwed up things are. But the conclusions (to me) seem all out of whack.
[+] [-] algorias|15 years ago|reply
You're missing the point. Giving out your password to a number of sites is as secure as the least secure of those sites. Giving it to a single third party still poses its problems, but is a much safer bet statistically.
[+] [-] unknown|15 years ago|reply
[deleted]
[+] [-] pornel|15 years ago|reply
You can designate any OpenID provider, including yourself. In such case DNS and optionally Certificate Authorities are only 3rd parties that have to be trusted (and if you can't trust these, you shouldn't be using the Web).
[+] [-] hammock|15 years ago|reply
Isn't that the way it's already supposed to work? The sites only store the salted hash (unique key)
[+] [-] dholowiski|15 years ago|reply
Would I even trust Google to handle Authentication? Maybe, but remind me again how I contact Google Tech Support when my authentication mysteriously stops working?
On the other hand, I had left comments on Gizmodo using Facebook Connect, so from a user perspective it worked out well for me.
[+] [-] andreyf|15 years ago|reply
Government bailout. Too big to fail.
[+] [-] JeremyBanks|15 years ago|reply
[+] [-] w1ntermute|15 years ago|reply
A great reason to use a password manager, like LastPass. I started using it ~1 year ago, and now each of my web logins has a different password. It's just one key combo to generate a new random password and insert it into the password field when signing up at a new site.
[+] [-] ZoFreX|15 years ago|reply
[+] [-] yason|15 years ago|reply
- I have a text file encrypted with GPG that contains my list of passwords.
- I open it in Emacs like any normal file.
- GPG is integrated to Gnome so I get a nice askpass dialog even from inside Emacs.
- I've configured Gnome to store the decrypted key for a few hours (or until suspend) and ask me anytime the cached passphrase will be reused, to avoid typing my long passphrase everytime I need to look up a password.
- Emacs also knows how to encrypt the file transparently when I've made changes and just save the buffer in Emacs.
- My swap partition is encrypted via TrueCrypt and so is my /home.
[+] [-] tomjen3|15 years ago|reply
[+] [-] city41|15 years ago|reply
[+] [-] ja27|15 years ago|reply
I had a weak password like 99beers that I've used for many years for the 90% of sites that don't matter. I started to transition to something like adding the first letter of the site name plus one to the beginning, so ycombinator.com would be z99beers. Still not strong, but I thought it reduced the risk if one site was compromised.
But since this compromise has been so large and well-publicized, I've gotten locked out of several sites that do matter, apparently just based on being in the Gawker dump. Since my email has never been compromised, this isn't a big deal, but it's a hassle.
Now I'm making a serious effort to apply LastPass and random passwords to everything.
[+] [-] antirez|15 years ago|reply
Make sure to don't expose your secure password of course. It's also a good idea to use a completely different strong password just for email.
p.s. it's worth to note that since there are tons fo SHA implementations for Javascript it's possible to build all this as a web application where all the business happens in the client.
The web app will just allow you to add a number of site names so that you don't have to type the site name by hand all the times.
Btw the world would be a better place with all the auth cookies set to expire on 2036...
[+] [-] sjs|15 years ago|reply
[+] [-] tptacek|15 years ago|reply
A basic property of a password manager system should be that the loss of any password doesn't give attackers any information about other passwords; yours potentially concedes the "master secret" that animates all of them.
[+] [-] gecko|15 years ago|reply
[+] [-] jules|15 years ago|reply
[+] [-] hieronymusN|15 years ago|reply
[+] [-] joh6nn|15 years ago|reply
[+] [-] hammock|15 years ago|reply
[+] [-] bcl|15 years ago|reply
[+] [-] jmg|15 years ago|reply
[+] [-] alanh|15 years ago|reply
Gretchen: That is so fetch!
Regina: Gretchen, stop trying to make fetch happen! It's not going to happen!
[+] [-] irons|15 years ago|reply
http://www.quora.com/What-s-wrong-with-OpenID
"The short answer is that OpenID is the worst possible 'solution' I have ever seen in my entire life to a problem that most people don't really have. That's what's 'wrong' with it."
[+] [-] Xk|15 years ago|reply
Uh, no? They did save the hashed+salted version. The only problem is that they used crypt, from 20 years ago, instead of something like bcrypt.
[+] [-] starting_over|15 years ago|reply
[+] [-] swombat|15 years ago|reply
[+] [-] unknown|15 years ago|reply
[deleted]
[+] [-] Xk|15 years ago|reply
Rainbow tables? No. That's the purpose of a salt. The table needs to be several orders of magnitude bigger.
[+] [-] yock|15 years ago|reply
[+] [-] quicksilver03|15 years ago|reply
[+] [-] ihumanable|15 years ago|reply
Rock Solid Security + Developer Friendly API = Win?
There are probably adoption issues and centralized authority fear. It seems though that other things have consolidated nicely (a ton of comments use Disqus now), maybe its time for someone to create a startup that solves this very real problem.
[+] [-] izak30|15 years ago|reply
[+] [-] gchucky|15 years ago|reply
[+] [-] wccrawford|15 years ago|reply
[+] [-] bl4k|15 years ago|reply
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
[+] [-] gthank|15 years ago|reply
[+] [-] anonymous246|15 years ago|reply
PSA: PwdHash FTW. It solves exactly this problem.
Firefox: https://www.pwdhash.com/ Chrome: https://chrome.google.com/extensions/search?itemlang=&hl... iPhone has several apps that do this (I use Keygrinder).