The worst offender I can recall was Wordpress.com. Not only do they email you your password back, but show it to both you and whoever might be sitting within a few metres in LARGE LETTERS in the webpage immediately after activating your account.
After I emailed to complain about this, they said:
"Security and usability is often a trade-off. We make two main ones:
* When you register at WordPress.com, we show you your password and email it to you.
* When you log in we tell you whether the username or password was incorrect.
The accessibility and increased convenience for users in both cases has been deemed to be worth it."
Edit: I just checked, and it seems that they've changed this element of their policy. The situation above was March 2009.
At least it's some consolation that they don't store the password in plain text, unlike plentyoffish.com. Do they also email you your new password if you change it?
A secure website should be mathematically incapable of ever displaying your plaintext password in any form whatsoever, at any time, even during the registration process.
True, but this would imply that the plaintext password would be passed around the application's internal infrastructure. Instead of just going into the frontend server, being hashed and then discarded, it would have to be passed to the email server, probably via some sort of message queue. This means the plaintext passwords would have to reside in some kind of datastore temporarily, possibly for quite some time if there is a backlog of registration emails.
This means you have to encrypt that store, which means you have to decide if you want to force EVERY email sent through the queue to adhere to the same security standards or just registration emails. Then you have to manage the keys for that encryption, and you have to audit it, blah blah blah blah, it quickly adds up to many many man hours of work.
All this just makes the whole thing more insecure, it increases the attack surface, and increases the work needed to secure the system and keep it secure. As it is not really necessary, IMO it shouldn't be done.
This also includes displaying the password back to the user in the browser, the plaintext password should be gone from memory before the templating engine is even invoked. The best way to solve problems is to simply avoid them.
Maybe I'm being unnecessarily paranoid, I like to think of it as a "security mindset" :)
If you have a public key associated with your email address on a public keyserver, they could encrypt your password—using said key—when you set it, and then store only the encrypted copy. Then, even though they were holding it, the only person who could do anything with it is you :)
The standard, minimal approach is to keep secure hash of each password and throw away the password itself. This has the same effect but doesn't require the average, unsophisticated user to have a public keep.
But that's just the bare minimum approach - from there, you add a "salt" and other things. Done well enough, you should have a system where downloading your entire system shouldn't compromise your users passwords. But that's only if this is done really well - the write-up for how hbgarey got hacked actually is a great intro to this kind of thing.
My point was that you can retain the ability to email the user their own password with no loss of security (provided the user has a public key—like, say, Github or Heroku require, as they use passwordless ssh for repository synchronization.) My point was not that keeping someone's password around, is any better an idea than just allowing them to reset it :)
There's one big win here I can see: your passwords don't exist in a vacuum. Many users, whether you like it or not, are going to be using the same password for a number of other websites.
By sending the hash and never letting the plaintext password hit the air, the worst that can happen is breach of your login system, you will not be responsible for someone in a coffee shop with wireshark sniffing out people's passwords, which can be applied to multiple websites.
Indeed, a scheme like hashing-in-the-browser to keep a plaintext password "off the air" is essentially a homebrewed effort to replicate a secure connection.
IE, doing this is a mistake because you may be smart but you probably haven't put your secure connection through everything that SSL has been put through.
Not necessarily, if I understand the situation correctly. In this notation, -> represents communication between components, and | represents the boundary between local and remote communication, which we assume is encrypted/decrypted appropriately.
On account creation,
password -> hash -> | -> stored
Upon account creation, I provide my password, which is hashed locally. The hashed version of my password is passed over the network and stored on the other end.
Logging in,
password -> | -> hash -> compare
Upon logging in, I provide my password and send it to the remote server. The remove server hashes my password and compares it to what it stored previously.
Hence, if someone intercepted my hash, it's the same situation as if they looked in /etc/passwd on a multi-user Unix system. That is, it's more information than nothing, but it's non-trivial to use that information to figure out my password.
That's an interesting idea, but I don't know what you're protecting against. You're still providing the plaintext to the remote end eventually, so I assume you trust them. You're assuming the communication is encrypted.
What does this scheme protect you against, compared to the normal technique (part #2 in your example)?
If your password is never stored in plaintext, it's less likely to be leaked, either maliciously or inadvertently. It's the same rational for not storing plaintext passwords on a Unix system.
Like on a Unix login, I have to provide the actual password to the service. But measures can be taken to ensure not only is the password itself never stored, but even that the memory that contains the password is appropriately zeroed after use. It's not a matter of the user trusting the service, it's a matter of the service being cautious with itself.
There's no need for a new protocol; lots of websites manage to never store passwords today. I guess your protocol does provide some assurance that the other end isn't going to store anything but the hash. Unfortunately, anyone competent enough to implement it is already probably doing the right thing, and the people doing the wrong thing frequently have business reasons for doing it wrong.
That only protects you at account creation time. How about this:
Password hash function is h. Client creates password p, hashes it 1000 times.
Account creation: Client sends h^1000(p) to server in the clear. Server stores h^1000(p) in plain text. Attacker eavesdrops h^1000(p), which is useless.
Log in: Client either looks up h^999(p), or calculates it from scratch starting at p. Client sends h^999(p) to server in the clear. Server hashes this to get h^1000(p), which matches what it has stored. Server replaces stored value of h^1000(p) with h^999(p). Client is permitted to log in. Attacker eavesdrops h^999(p), which is now also useless.
Log in 2: Client either looks up h^998(p), or calculates it from scratch starting at p. Client sends h^998(p) to the server in the clear. Server hashes this to get h^999(p), which matches what it has stored. Server replaces stored value of h^999(p) with h^998(p). Client is permitted to log in. Attacker eavesdrops h^998(p), which, again, has become useless.
...
Once the client gets down to around h^100(p), server (which has also been keeping count) starts prompting client to create a new password before the hashes run out.
(If you run out of hashes, you're screwed. You can log in one last time by sending p in the clear and having it stored in plain text. Attacker eavesdrops p, which is useless here but may be extremely useful elsewhere for obvious reasons. After this, you can never log in again.)
NOTE: obviously this assumes the hash function is irreversible, mostly free from collisions and quick to execute. Also, the user should ideally NOT log in like 1000 times in a week. Both achievable goals, though.
The purpose of this is not to protect against eavesdropping - note I said that the communication with the server was encrypted and decrypted as appropriate. Really, I was just presenting an existence counter-example to the claim that if the browser performs the hash, the hash itself becomes the plaintext password. This is a scheme where the browser performs the initial hash, and the user still uses the same password.
That aside, the only thing it gets for you are less code-paths you have to worry about that handle the password in plaintext. It's an application of the principle to only communicate what is strictly necessary to function.
The only problem I see with this is in cases where you sign in from multiple devices. How would each device know which x (for h^x(p)) you are on? Is that something the server sends to each device at login time? Would that be a security risk? I don't know a lot about this so these may be stupid questions.
Geez, you're right. I went all the way through the Wikipedia article on cryptographic hash functions looking for something similar to what I'd just described, but there was no link to THIS:
"Hence, if someone intercepted my hash, it's the same situation as if they looked in /etc/passwd on a multi-user Unix system."
Except that now the hash is your password, as far as the system is concerned. If someone intercepted your hash they could just pass the hash off to the site and they have full access. This isn't quite as bad as accessing the plain-text password (which potentially is shared across multiple sites) but it's still bad.
Also, there's an easy workaround for this problem, using SSL for login.
This increases the password space (assuming a cryptographically strong hash), but if the datastore is compromised, an attacker can just bypass the client hashing (by changing JavaScript, etc) and just pass in the hash itself.
Yes, if someone breaks into the server, and changes the code for the login process, they can get around this. But that's always true. The server is a higher priority target than a single account. If your scenario requires breaking a higher priority target than the one in question, it's not really a security hole.
Similarly, someone can compromise my account on a Linux box if they get root access. They won't know my password, but they can change my password or just replace the login program with their own. But we consider getting root access a higher target that compromising a single account.
In other words, this is begging the question.
edit: I must have responded to a different understanding.
Whoops. The protocol you described is actually secure against that, since your login passes the preimage to the server for hashing and then comparison.
I think this actually does protect you from exposing your password to an attacker, but only at account creation time. If the attacker waits around for you to log in conventionally at some later time, then it's over.
You clearly didn't read the link I directed you at. If you had you'd have seen that you only need MD5(username:realm:password), and would have been pointed at JBoss's DIGESTAuth implementation as an example of an implementation that does this.
"You clearly didn't read the link I directed you at." I do believe your tone is rather counterproductive to the purpose of this forum.
I did in fact read the article, and I do now agree that you only need to send MD5(username:realm:password) to the remote server to do the authentication.
The problem that I do see is that it is trivial for a MITM to either intercept the transaction and force the client into a less secure mode (ie. basic auth), and then read in the password, or else just reuse the auth credentials for another transaction.
The normal way is to capture that information in a sign-up page that is served over https. The point of digest authentication is not to replace https for what it is necessary for. It is to allow http and authentication to be used more securely than plain text authentication can be.
Incidentally your snideness is not appreciated. Generally something doesn't get to be a widely implemented RFC without the obvious questions having been asked and answered.
Capturing that information in a sign-up page that is served over https sounds an awful lot like the plaintext password is going to reach the server at which point the server will be mathematically capable of displaying it. That happens to defeat the entire purpose of this little subthread.
Your understanding of this subthread is very different from mine. I'm talking about practical security options for practical websites. In that case you don't care about information that was transiently present in the server for a fraction of a second once, you care about information that has been persistently stored.
But if you want such a ridiculous requirement, you can have JavaScript on the signup form that computes the hash on the client and sends it to the server. That form still needs to go over a secure channel (eg https) because the information sent, while not including the plain text password, is sufficient information for a sufficiently motivated attacker to get access.
Your reply, coming where it did in the thread, gave the impression you thought digest auth somehow avoided ever sending a plaintext password to the server.
Yes, but if we have hash(plaintext + site_specific_salt), then even if I use the same password for different sites and the hash from one of them is intercepted, it still takes a while until the others will also be compromised. I didn't say the system was perfect, but still better than sending the password in plain text.
I believe a similar idea (use hmac(url, password) as a password for websites) is used to great effect by a firefox plugin.
Also, please do not use hash(x + y), use hmacs. String concatenation in hashing breaks some of the complexity guarantees and will lead to your hashes getting cracked faster then you'd expect.
You need to assign a password to a specific user account (they aren't registered, but are seeded into your system). I work on 3 different projects right now with this requirement. In this case, we create accounts for people based on a data pull from another agency, then contact those folks.
I generally agree with you (and plenty of fish is scary how they mail your pass every week or so!), but there are use cases where displaying cleartext passwords is acceptable.
> but there are use cases where displaying cleartext passwords is acceptable.
The only use case where sending and displaying cleartext passwords is acceptable is when the password is auto-generated and very long.
In all other cases, especially if the password has been entered by the user, this behavior is not only unacceptable, but also unexpected and thus the exact opposite of user-friendliness.
While much is made about passwords being sent across the open net, almost every site short of banks allow you to reset a password with an email, which is a close to identical problem.
If they use the same codebase that is on opensource wordpress they store the password as an md5 hash which isn't much better. Take a look at the wordpress source code one day, you'll be horrified.
I spent around two years working on some of the highest traffic Wordpress sites out there and I came to the Winston Churchill-like conclusion that Wordpress is the worst blogging platform out there, except for all of the others that have been tried.
I totally disagree, Habari's code base is far superior to wordpress in every regard it simply needs a larger user base. Try it if you are looking for a new blogging platform you'll be pleasantly surprised. http://habariproject.org
I wouldn't argue that Habari is probably better code than WordPress, but it doesn't seem fair to compare a 0.7 product to something as functional and battle-tested as WordPress.
After I emailed to complain about this, they said:
"Security and usability is often a trade-off. We make two main ones:
* When you register at WordPress.com, we show you your password and email it to you. * When you log in we tell you whether the username or password was incorrect.
The accessibility and increased convenience for users in both cases has been deemed to be worth it."
Edit: I just checked, and it seems that they've changed this element of their policy. The situation above was March 2009.