Doesn't mean it is a good idea though.
Doesn't mean it is a good idea though.
Correct me if I'm wrong but wouldn't this mean that only the email stored on the recipient's email provider's server was then unencrypted.
HN does this too, by the way. If you request a new password for an account, it's being sent in plaintext. No problem here, what comes to storing it.
At least it's better than asking for your mother's maiden name.
Actually it changes a lot. Password reset links are one time only, and they get sent before you change your password. Mailing your password in plaintext after you've just changed it means it's good even if someone gets a hold of it months or years later. That's significantly worse.
HN passwords are not high security. If we lose an HN account, not only can it be easily restored by an admin, it's really not a huge loss - start again. There doesn't need to be extreme practices.
Oh, you use the same password across sites? (which is the source of 99% of password security concerns). That is crazy, and you shouldn't do that. That's on you. (You being the conceptual person up in arms)
If you are changing the password/registering, the password is in plaintext in the memory on the server anyway; it just has to be. So they can just mail it to you.
Say a user forgot their password and they click some link to reset their password:
Generate the password text, then create an email with that password, send the email, and then store the password, connected to the User object, in the default Django way, which is SHA'd.
You should create a token, and mark the account with it, send the token to the user, and if the user sends the token back to you (at the URL, normally), you let him replace his password. The password itself is never communicated back to the user.
Otherwise the email could be found later and used to gain access.
email = input.email
plainPassword = input.password
hashed = hash(plainPassword)
saveToDb(email, hashed)
sendGreetingEmail(email, plainPassword)
Emailing a plain text password during registration is not the same as storing it forever in a database.But then you can start listing non-HTTPS sites, too. You disclose your password in plaintext to many servers every time you login on those.
"But what if someone hacks your email, they know all your passwords!"
What if someone hacks your 1password account? It's the same exact scenario. Having a single point of failure that one can be extra vigilant with guarding is much better than the alternative of having a hundred unique passwords one must remember.
OR, we should just accept that there's a whole magnitude of difference between sending a password by email on a single occasion, and storing it in plain-text, and focus on the latter problem first.
Who does that? That's even worse than storing it in plain text on the backend.
[1] http://www.assosfactoryoutlet.com/customer/account/create/