Why is it unsafe to send a user their password via SSL encrypted communication rather than always sending a reset link?

Question

I can understand why you wouldn't want to email someone their password, but on an SSL encrypted web page, I dont understand why websites always require you to reset the password when you'd probably prefer to keep it the same, you just forgot it.

SSL is completely secure right? So from a security standpoint, the only reason I can imagine someone would be vulnerable to having their password stolen would be if their PC were compromised, in which case creating a password would also render the new password compromised.

Answer 1

Three huge problems with this:

• The server must be able to send the password, meaning the server knows the password, meaning the server admin/owner can read it too. This should never be possible (see many many topics about hashes, salts, and multiple-round derivation functions). While an admin with all server access already can impersonate users etc. as wanted, many users use their password for multiple things. The admin shouldn't be able to access these.
• If the server is hacked, the same is valid for the attacker: They should not be able to read passwords, because they shouldn't be able to reuse them in other places.
• And no, SSL is not "completely secure". Especially, TLS exists because SSL is pretty insecure (but TLS isn't perfect either).

Answer 2

One important issue has not been mentioned, yet:
The (missing) authentication of the Client in SSL/TLS.

While @deviantfan has a few valid points, I would like to add this basic issue, why your proposal is not feasible.

TLS without Client authentication:

Typically SSL/TLS are carried out with the Server authenticating itself to the Client, but not the other way around. This means any client can setup a secure TLS connection with the server and be sure that the server is legitimate. However, if there is no client authentication, the server cannot be sure, if the person connecting to it is the person it claims to be. Therefore, it would not make sense for the server to send a password to any client in this setup.

TLS with Client authentication:

In case client authentication is actually performed to setup the TLS session, the server can be sure that the client is who he claims to be. However, in order to enable client authentication, on the client side a certificate (+ private key) needs to be installed. If this kind of mutual authentication is already established, there would not be a need to have a password to log-in in the first place.

Answer 3

Generally the servers do not store the password, instead store hash of the password along with a 'salt'. The salt is random data that is used as an additional input to the one-way function that hashes the password.

Adding the salt and hashing the password will prevent it from dictionary attacks or pre computed rainbow table attacks.

Answer 4

The answers given are quite on point. However, from a logical point of view, I must point out that saying:

" when you'd probably prefer to keep it the same, you just forgot it."

is not possible. Since sites that are considered secure do not even know your password, and only the user that knows it, if the user completely forgets the password, it means it's lost... forever.

Secondly, if you've forgotten your password, it's a good indication that you chose a password to satisfy the password entry algorithm rather than a password that is good for you the user. Much of the fault is usually on the site designers' side as they should not attempt to protect the user from himself (by forcefully making them choose a 'strong' password) and instead should up their game and work on better password protection techniques. In that regard, the site is subtly telling you that "hey, you chose a bad password; here is your chance to get a better, easier to remember one."