
The Dirty Truth About Web Passwords - phsr
http://www.codinghorror.com/blog/2010/12/the-dirty-truth-about-web-passwords.html
======
tptacek
_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).

~~~
mrcharles
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?

~~~
tptacek
DES crypt(3) isn't a block cipher. It's a (crappy) hash that uses the guts of
the DES algorithm. Don't think of it like AES or Blowfish or whatever. It
doesn't "encrypt" passwords. What it specific does is encrypt a single all-
zeroes block using a key derived from your password. There are, for what it's
worth, a lot of hashes that are --- in the heart of hearts --- block ciphers.
Some of the SHA3 finalists fit that mold.

People are very confused by this whole "Gawker is using DES" narrative. But
Gawker isn't "using DES"; they're using DES crypt(3), which is a construction
derived from DES internals. That's not at all the same thing.

In this specific case, because DES crypt(3) is in fact a crappy hash,
passphrases are irrelevant; crypt(3) truncates them to fit a DES key. The rest
of the data for your passphrase is never even hitting the hash, so a stolen
hash can't possibly disclose the whole passphrase.

~~~
mrcharles
Thank you for your answer, I understand now.

------
ComputerGuru
_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.

~~~
tptacek
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. =)

~~~
ComputerGuru
Thanks. Wrote that out in a hurry before leaving, and it's now too late to
edit it though :(

------
DanielBMarkham
_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.

~~~
algorias
> 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.

~~~
jonhohle
I read it as if he's proposing a unique "key" to every "door", kind of like
the real world, except you get to create your own "keys" (passwords).

------
dholowiski
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.

~~~
andreyf
_What happens to all the Facebook connect accounts when Facebook goes
bankrupt?_

Government bailout. Too big to fail.

------
w1ntermute
> 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.

~~~
ZoFreX
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>

~~~
thalur
I've been looking at switching to a password manager like that, but I've been
having trouble knowing how to pick one that a) I can trust and b) is good. I
was thinking of giving up and just using a plain text file inside a truecrypt
file.

~~~
stcredzero
KeePass. Using KeePass 1 format means I can run my password crypt on Windows,
OS X, and Linux. I just keep the database file on Dropbox.

~~~
ZoFreX
A lot of people seem to do this, so I'm curious - what are the advantages
compared to e.g. LastPass? Also, how well does it hold up if you used two
devices simultaneously?

~~~
stcredzero
KeePass writes out a lock file, so the other instances will warn you and you
can tell them to open the database as read-only.

Advantages? I guess I should try out LastPass. Free or $1/month premium is a
good price.

~~~
ZoFreX
Cool. I always saw this as a limitation but honestly it's very, very rare that
I need simultaneous write - just simultaneous read. I will start recommending
KeePass + Dropbox to those who don't trust LastPass. What's KeePass's browser
integration like?

------
tomjen3
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.

~~~
city41
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.

~~~
pietrofmaggi
I've 1Password since the beginning of this year and it's definitely the best
utility I've ever used for this problem.

Currently I'm using it on chrome, safari and iOS 4.2 using dropbox sync.

It works like a charme!

~~~
kenjackson
Just downloaded KeePass. Going to try it out. If it works, I'm going to start
getting my non-tech savvy friends and family members moved over.

------
antirez
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...

~~~
sjs
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_

~~~
run4yourlives
And that site will more than likely be your bank to boot.

~~~
sjs
I have a feeling that some old bank software has fixed size fields and that's
we get ridiculous maximum lengths on bank passwords.

------
bcl
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.

------
jmg
Thanks, Jeff. Could you also please lecture us on properly backing up a site?

------
alanh
He's still calling it an "Internet driver's license"?

 _Gretchen: That is so fetch!_

 _Regina: Gretchen, stop trying to make fetch happen! It's not going to
happen!_

~~~
irons
The label is a small problem. The concept is a big problem.

<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."

~~~
jrockway
That's insightful.

You're right, most people don't have a problem with passwords. They use
"password" everywhere and it's never a problem!

------
Xk
> 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.

~~~
starting_over
Are you sure it was salted? john the ripper took all of 24 minutes to crack my
password.

~~~
Xk
Yeah, I am. I'm looking at the database right now.

I would assume they had more, faster computers. And the passwords they broke
were only the simple ones -- I would assume your password is not password1.

------
swombat
I thought they had them hashed and salted, but the crackers are using rainbow
tables and brute force to crack them?

~~~
Xk
Brute force? Yes.

Rainbow tables? No. That's the purpose of a salt. The table needs to be
several orders of magnitude bigger.

------
yock
Could this please be the warning shot fired across the Internet's bow to get
Hacker News to fix the OpenID login?

------
quicksilver03
What's sad is that he's proposing to stop password reuse and replace it with a
more complicated password reuse, with the involvement of a third party.

------
ihumanable
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.

~~~
izak30
I think that they were called clickpass, a YC company, who was acquired by
synthasite.

------
gchucky
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
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
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
> 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
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
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
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
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.

------
anonymous246
"At that point, unless you picked a strong, unique password on every single
site you've ever visited, the situation gets ugly."

PSA: PwdHash FTW. It solves exactly this problem.

Firefox: <https://www.pwdhash.com/> Chrome:
[https://chrome.google.com/extensions/search?itemlang=&hl...](https://chrome.google.com/extensions/search?itemlang=&hl=en&q=pwdhash)
iPhone has several apps that do this (I use Keygrinder).

