[drm237]

I disagree that not being able to tell someone their password is a usability problem. Having a password reset system is just as usable and significantly more secure than having to store passwords in plain text.

And both of your arguments about having bigger problems are fundamentally flawed. Sure, if someone does get your db, you have a big problem, but that doesn't mean you shouldn't take precautions so that if it somehow happens they can't read it like a book. It's kind of like you're saying cars shouldn't have airbags because it's harder to honk the horn and if you do get in an accident, you've got bigger problems.

And someone snooping on your email is as easy as you accessing your webmail on an unencrypted wifi connection. Do you think everyone in the world makes sure they use the ssl version of their webmail in public? Because if not, sniffing packets is trivially easy.

My point is that the situations you mentioned only become bigger problems when you make no effort to protect these things.

[wallflower]

> Do you think everyone in the world makes sure they use the ssl version of their webmail in public?

I know techies who don't use GMail who don't bother to explicitly using https://mail.google.com - I don't know why.

[paulgb]

I didn't realize until recently, but GMail now has an option to automatically use https. It is under https://mail.google.com/mail/#settings at the bottom, and is turned off by default.

[timf]

And there was an automated tool released last year to mess with those who don't do that:

http://www.google.com/search?hl=en&q=https+gmail+cookie+...

[agotterer]

I prefer 1 way hashed passwords. But why assume they are doing it in plain text? Why not a two way encryption?

[drm237]

True, two way hashing is better than nothing, but it's still less secure than one way hashing (with a per-user salt) for passwords. All you need if one rogue employee and they can decrypt everyone's password. It's just difficult to justify the added risk when there usually isn't a need to retrieve the original password.

Edit: by "two way hashing" I meant encryption, not hashing. not sure where my brain was on that one...

[tptacek]

As a practitioner in this space, I'm going to tell you that I don't know what this "two-way hashing" is that you speak of. There's a right way to store passwords and there's a wrong way. The right way is bcrypt. The wrong way is anything other than bcrypt.

[thwarted]

Are you making a distinction between storing for verification and storing for use? The right way to store passwords when you use them to verify authentication is to hash (twitter verifying a login). The right way to store passwords when you need to use them to gain access on behalf of a user is to encrypt them (any third party "twitter application"). I ask because the first google result for "bcrypt" is http://bcrypt.sourceforge.net/ which is distinctly not hashing, where as the second one is for a ruby library interface to bcrypt hashing.

[tptacek]

First, bcrypt is a one-way hash algorithm.

Second, the whole fuss about Twitter and OAuth is the degree to which people are not OK with giving their passwords to other people to use.

[thwarted]

Yes, I was able to determine that bcrypt is a one-way hash algorithm. But part of my point is that the name is ambiguous because there are multiple things using that name. Even the wikipedia entry for bcrypt is for the encryption software ( http://en.wikipedia.org/wiki/Bcrypt ), not the hashing algorithm, so I was having a hard time finding out more about the algorithm other than that there is a ruby binding for it. Thankfully, the ruby docs contain references.

Consider this codinghorror posting, http://www.codinghorror.com/blog/archives/000953.html , where Atwood confuses the reasons why third-party websites would need to obscure passwords in the first paragraph and quoted section (a third party needs the plaintext of the password in order to offer integration services (assuming things like remote keys and oauth are not provided), so storing a hash of the password is meaningless in that context).

And I only used twitter and twitter applications as an example of a ecosystem that has, up until their oauth deployment, multiple consumers of passwords for different purposes (twitter for authentication, apps for integration), as a way to point out the confusion.