Don't E-mail me my password


All over the net, a huge number of sites offer you the option of E-mailing you your password if you have forgotten it. While this seems to make sense, it is actually a dreadful security policy, and if you see it, you should complain and point them to this article or others to get them to stop. As an alternate, they should at most offer to E-mail you a new, randomly chosen temporary password, which you can use to log in and set a more memorable password.

If a site can mail you your password, it means they are keeping a copy of it. They should not be doing that. First of all, almost everybody re-uses passwords at different sites. That means if one site has a security breach -- as Convio did this week for a wide variety of sites that are its clients -- your password will be stolen, and it can then be used on all the other sites you use it at. (This is a good reason to always use more protected, less duplicated passwords on sites where actual damage can be done or money can be spent, like banks, eBay, paypal etc.)

Instead, they should keep a "hash" of your password. A hash is a one way function. Given the plain password, they can hash it, and store the result, but you can't get the plain password back from the hash. So you can check to see if a password that was typed matches the password without storing what the password is. This is actually a very easy thing to do in most systems, and its main downside is the fact that they can no longer e-mail you your password. They can, however, set it to something random and mail you that. That's a touch more work in the rare event of a lost password, but worth the trouble.

There is, oddly, one minor downside to hashed passwords. With hashed passwords, you must provide the site your real password, and they can then test it and forget it. You must trust them to forget it. The real password, however, is sent over the internet and if you don't use an encrypted channel, like SSL/TLS/https, it could be intercepted by people tapping the line. Some password systems (included the less commonly used HTTP password system) have the browser hash the password (in a special way that is different every time) and send the hash to log in. In this case, the real password is not sent, and can't be sniffed, but must be in storage at the remote site. However, if you use an encrypted channel (https), there is no worry about the password going over the internet, and so there's no reason not to do it that way.

There is a better way to do all of this. With digital signature, you can prove that you're you using a secret private key only you know. Nobody else ever gets this key, and nobody can figure it out by watching the communications you send. While this technology has been around for some time, and is in fact implemented in most browsers (though far from perfectly) it is not a common way to authenticate to web sites at all.

However, next time a site offers to E-mail your password, point them to the Convio data theft and to this page and ask them to get their act together.


As far as I am aware, the only authentication mechanism(s) implemented in browsers that are remotely comparable to digital signatures are CRAM mechanisms, which use a "hashed message authentication code" (HMAC) algorithm. In these mechanisms, the server sends a one time "nonce" to the client which is then hashed together with the password (in a couple of slightly different ways) and sent back to the server. The server does the same and compares the two. If they are the same, the passwords matched.

To let this work, the server needs to either store the plain text of the password, or it needs to store the internal state of the hash algorithm after hashing the password. The trick here is that there exists both CRAM-MD5, and CRAM-SHA1 (and probably others), and the hashed password for one won't work for the other. So by storing only the hashed password, you either limit the site to one CRAM mechanism, or require the use of plain text passwords over the wire.

The ideal, as you point out, would be the use of true digital signatures, using either RSA, DSA, or elliptical curves, or whatever. These would require the storage on the server of only authentication data that is otherwise publicly available, and yet remain unspoofable.

Actually, while it's very rarely used, you can give your browser a certificate for you (such as a Thawte personal certificate) and it will do more than sign mail, it will authenticate *you* in SSL conversations with web sites -- as well as their own certificate authenticating them. So this could be used as a login/auth mechanism but nobody does it. If you look in your firefox preferences under "advanced/encryption" you will even see where you can set what to do if a web site asks for your certificate.

Of course, you are right. I had been forgetting the client authentication support for SSL, as I was only considering the non-SSL case.

Obviously you bring up a lot of good points. Sites should use hash, or one way encryption, to store your passwords. Sites should send you new, randomly generated passwords, sites should do a lot of things, actually, but we have little control over them (aside from letter writing).

Here are a few things YOU can do:
1) dont lose your password.
2) Dont use the same password twice.
3) if a site ever emails you your password. Change it immediately. AND, if you do use that password in more then one place, change it wherever you used it.

Add new comment