You send it from the server. Again, this is a bad idea - but that's because email is unencrypted, not because the password is persistently stored unencrypted.
Should cease to exist the moment the user advances to the next page ... It's either being stored locally
A typical application server pipeline goes something like this:
At any point during app code execution, you can write to the response stream. It's trivial to write the password to the response without having to store it (again, a bad idea, but it in no way implies any form of persistent storage).
The action of "advanc[ing] to the next page" involves sending the request - containing the password - and receiving a response as part of the same bidirectional stream. You don't store the password from the request then retrieve it for the response. You can send it directly back out the response (making a copy in the very much temporary response stream, that does not last significantly longer than the original in-memory copy). Of course, this is a bad idea because you expose the password on-screen, but it's not significantly less safe than the act of sending the password in the request in the first place.
Basically, the "moment the user advances" actually encompasses the entire request and response. It's not like the password disappears from memory the moment they click submit.
My point is people seem to jump to the conclusion of "password is send in response/email" = "they're storing the password as plain text or reversible encryption". This is not true. It's perfectly possible to send the password while only persisting a properly hashed copy of it. At that point the only copy kept by the server is the hashed copy - there might also be a plain text copy floating around email servers and in the page response, but that's a separate issue (and is transient - so would have to be intercepted real-time as opposed to a database leak months/years later).
Also, there are only two dangers to sending the password in the response. The first is that someone can see the password on-screen. That's obviously bad. The second is that the password exists in memory for longer than just the request would require. That's ... not good, but the security impact is pretty minimal. And as long as the request is secure, the response on the same stream is just as secure.
At the end of the day, doing either of those things is bad practice. But it does not necessarily mean the password storage itself is poorly implemented. It does kinda suggest that is happening, since bad security is usually not in isolation, but this is not definite.
Yeah for me it's the email component that makes it annoying, I don't my password for a website anywhere I won't be using it. Seeing my password chilling in the inbox is irritating.
Yes, I've deleted my original response. I had a moment of complete brain-deadedness and forgot how websites work. I haven't done it in a long time, I had it in my head that hashing is done on the client side.
My point is people seem to jump to the conclusion of "password is send in response/email" = "they're storing the password as plain text or reversible encryption". This is not true. It's perfectly possible to send the password while only persisting a properly hashed copy of it.
How is this done? I thought the point of a hash was that it was a one-way function, so even knowing the hashing algorithm wouldn't help to determine the original text from the hashed output.
When the server receives a request from the browser, it has to store all the details about the request in memory. This is typically temporary, and only lasts as long as it takes to generate and send the response back (in the other direction over the same stream that's kept open until the response is done).
When a user submits a sign up request, that request will contain a plain text password (preferably encrypted in transit by HTTPS).
The server will have access to the plain text password. That's just business as normal.
Now, the server can decide to send the password back in the response. It can decide to send the password in an email. It can also decide to save the password to a database to be compared against later.
All these actions are more or less independent. It can send the password in plain text email before also sending it through a hash function and only storing the hash output in the database. And that's the important part: the password should not be stored in plain text in the database.
For some reason, people think plain text passwords in sign up emails automatically mean they were stored plain text and then retrieved later for sending the email. From a programming perspective, it's easily possible to send the email off before storing the password. Or even storing the password and then sending the email based off the temporary plain text copy that still exists in memory until the response is finished.
I did mention that there are many reasons it's a bad idea to send plain text passwords by email, but the point here is plain text emails and hashed password storage are not mutually exclusive. Of course, if you get sent your password at a later time (e.g. for recovery) when the only way that would have been possible is if they did not use a one-way hash.
BTW, "hashing" with algorithms like MD5, SHA1, SHA256, etc. are considered bad practice for password storage. Use something like bcrypt, scrypt or PBKDF2 designed to take a long time, and always adjust the cost factor to the maximum you can tolerate for a user login - that makes brute forcing much harder.
...Even though I misread and missed that your earlier post was about sending the email at signup and not from a password recovery request, so I shouldn't have had to even ask the question in the first place >.>
Firing off an email from the browser (without opening an external client or taking advantage of some special feature) is no mean feat, and unless this was very recent, would involve sending the plaintext somewhere else to have it emailed back to you.
Actually its trivial and has been done for a very very long time. The server will always be able to see whatever you send it unencrypted / plaintext. The encrypting is done server side.
Hey no worries, many people don't understand that the server can see everything and how they save/share that information is up to them. Why is so, so, so important to not re-use passwords. They could take the email & password you gave them for that site and turn around and try to login to your email, facebook, whatever else with it.
24
u/space_keeper Mar 08 '16 edited Mar 08 '16
[Snip]
I forgot how websites work, and I should be ashamed of myself.