1

Is it really a problem if you send back the password when the validation fail on a registration form?

I understand that the html that is sent back could be cached on the computer of the person registering and then if a malicious person later access that computer he could see the password that user entered by looking into his cached files.

BUT... Aren't you already screwed when someone get physical access to your computer? If he can look at the cached files of your browser chances are that he could install any program he wants on the machine. Also, many people store their password directly in their browser without a master password. If he has access to the computer he could just check all the passwords that the user saved.

EDIT : This is a similar question : https://ux.stackexchange.com/questions/20418/when-form-submission-fails-password-field-gets-blanked-why-is-that-the-case

Community
  • 1
Gudradain
  • 6,941
  • 2
  • 26
  • 44
  • What about when you try to log for a public place. Or if you use someone else's username. How can you assume the person trying to log in is who she says she is without a validated password? – M'vy Feb 18 '16 at 16:24
  • 1
    @M'vy doesn't look like you understood the question. When you fill a form to register a new account, sometimes an error happen in this form, the account is not created and the webpage send back an error message like "This is not a valid email address". My question is : Is it a problem to send back the password the user just typed on this page. – Gudradain Feb 18 '16 at 16:28
  • 1
    Yes it is. It serves no purpose and makes things even worse where people could be looking at your screen. People do reuse passwords all the time, despite it being bad practice, so please don't ever display a password when the user did not asked for it. – M'vy Feb 18 '16 at 16:31
  • 1
    @M'vy Like I said you didn't understand the question. The password is never displayed because it is in a password field so the only thing someone see is ****** and please read the other thread to understand it properly. http://ux.stackexchange.com/questions/20418/when-form-submission-fails-password-field-gets-blanked-why-is-that-the-case – Gudradain Feb 18 '16 at 16:35
  • @ꓨꓵꓷꓤꓯꓷꓯꓲꓠ If another thread is needed to explain the question, then the question here is incomplete. – Iszi Feb 18 '16 at 16:35
  • 1
    Yeah well, it's not easy to track live edits while commenting. By the way "send back the password" is a bit ambiguous at first. – M'vy Feb 18 '16 at 16:36
  • 1
    @M'vy good point. I changed the title :) – Gudradain Feb 18 '16 at 16:44

1 Answers1

3

If you're ever able to "send back" the password, through any channel, then you're not handling passwords correctly. Period.

If the password can be retained in the form via client-side caching, that's perfectly fine. Arguably still riskier than not, but certainly much safer than: (a.) sending the password over the wire (in any form) more times than necessary, and (b.) giving the server more access and time with the plaintext password than necessary.

Once a server receives a password, it should be put through whatever hashing process is required for comparison against (or insertion to) the database and then the plaintext should be immediately discarded. There's very few - close to zero - cases where any additional server-side handling of the plaintext is appropriate, and all of them increase its risk of compromise (even if only by increasing the time it's retained by the server).

Iszi
  • 27,027
  • 18
  • 99
  • 163
  • 1
    I understand the risk in "sending the password over the wire (in any form) more times than necessary" but here it's literally sending it back over the same secure channel it was just sent like .1 seconds later. If there was any risk for this channel to be compromised, the user should not have send his password in the first place. I get that there is more risks and I know about security in depth but is there a point where you could just say "it's good enough?" Like here, I really don't see what we gain except a bad user experience or more work for the programmers to implement client validation. – Gudradain Feb 18 '16 at 16:53
  • 1
    @ꓨꓵꓷꓤꓯꓷꓯꓲꓠ For this to work the server needs to remember the password (even if it's only for a short time). This means the password is temporarily stored unhashed! Also it would not work with client-side hashing. – John Feb 18 '16 at 17:41
  • 1
    @John First, the password usually reach the server which means the server "store" it even if it's just for a very short time so that argument hold no weight. In both case they are store on the server for a short time. The only difference here is that it is sent back to the user via the same secure channel it was transmitted. If you want to say that it is insecure, your argument needs to be based on the fact that it is sent back. Why is sending it back a security risk? – Gudradain Feb 18 '16 at 18:21
  • 1
    @John Second, client-side hashing is not that useful. Refer to that answer for further explanation. http://security.stackexchange.com/a/53606/50051 – Gudradain Feb 18 '16 at 18:22