Bad Security at Evite(fnord1.blog.ca) |
Bad Security at Evite(fnord1.blog.ca) |
If someone's snooping on your email, I think you've got bigger problems than a lost password, tbh.
As for hashing, again, if someone can get on the server and download the whole database, you've got bigger problems than password hashing.
I'm not saying this is a good practice, but I just don't think it's as big a problem as this guy is making it out.
Also, there's a balance between security and usability. For some kinds of users, not being able to tell them their password is actually a problem. Sites that are able to do that will have a competitive edge in getting those users. So the question is one of balance between usability and security, not just one of security.
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.
I know techies who don't use GMail who don't bother to explicitly using https://mail.google.com - I don't know why.
If you lose your whole database to an attacker, you have a big problem.
If you lose your whole database to an attacker, and you stored recoverable passwords in it, everyone has a big problem.
There'd be something to debate here if fixing this problem wasn't 5-10 lines of code. But that's what it is. 5-10 lines of code to keep yourself from compromising tens of thousands of (email, password) pairs. There is no debate to have here.
But, the onus here should really be on the user. If they are careless enough to use the same password for everything, they are indicating that they are willing to trade some security for convenience. In my opinion, emailing users their password is just another security/convenience trade-off. I'd be upset to get my password sent in plantext from my bank, but not an invite website.
I think some health insurance sites do the same thing.
Edit: by "two way hashing" I meant encryption, not hashing. not sure where my brain was on that one...
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.
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.