4

Let say that we have a registration page on a website, why shouldn't we return passwords like username, names or any other information on form submitting failure?

For example:

  • User goes to example.com/signup.php and enter his/her desired username, name, email and password. User must enter a captcha input too.

  • He/she enters everything right except captcha.

  • Website warns user that he/she entered captcha's value wrongly and refills username, name and email inputs automatically according to already submitted values but it leaves password's input blank!

At this step when they need to refill password, a valuable percentage of users (just like me, sometimes) will stop registration and leave the website.

What is the security benefit using this method?

  • That's a good question. I may of course be wrong but assuming the site is served over HTTPS and the correct cache-control headers are set (to tell the browser not to cache the page with the password) it should be safe. – André Borie Aug 25 '16 at 22:21
  • 3
    A solution if after all you do not wish to resend the page with the password would be to hash the password anyway, store it in the user's session and resend the page without the password field at all. On the next successful form submission you use the password from the session and create your user model as usual. – André Borie Aug 25 '16 at 22:25
  • @AndréBorie But on a non-HTTPS commutation, passwords could be exposed in the first request! In my opinion this kind of prevention is "Security Through Obscurity" (or whatever has been called). – Amirreza Nasiri Aug 25 '16 at 22:26
  • 2
    Of course you should make it user-friendly by replacing the password field with an explaination like Your previous password has been saved but is not displayed for security reasons. Click here if you want to enter a new password. – André Borie Aug 25 '16 at 22:48
  • 2
    use ajax to submit the form or validate the CAPTHA so that the inputs never clear – dandavis Aug 26 '16 at 22:19
2

Annoying, isn't it? Security and usability are often at odds.

In this case, the risk is pretty small, but it's there. Imagine the following:

  1. You enter all your info, including password, and submit
  2. You temporarily lose your wifi connection, or something happens on the 'net to cause the response to be incredibly slow
  3. Losing patience, you walk away from the computer
  4. A minute later, the page finally renders, including your password
  5. A malicious user walks by, clicks Inspect Element, and learns the password

Of course, it's not a password that will work (your registration failed, after all), but maybe you use the same password for everything. Who knows? Anyway, the risk is pretty small here.

There is also a usability issue. The password may have been overwritten by one of your password manager addons or iCloud keyring or something like that. Since you can't see the password value, you can't be 100% sure that it is set to the intended value when you resubmit the form. If it's wrong, you will end up encountering all kinds of grief and confusion. So perhaps it is safer just to make you type it in again.

Personally, if I were designing the web site, I would put the password data entry fields on its own page, after you have successfully filled out all the other fields, including CAPTCHA.

  • Hmm, I haven't thought about it, so I'm gonna leave it blank or ask it on other page. Thank you. – Amirreza Nasiri Aug 26 '16 at 0:36
1

Another attack vector to consider is Session Hijacking. Assuming you're using Post-Redirect-Get (which you should be in general), you'd have to save the password in the session in order to resend it via GET. While the session itself is in a relatively secure, trusted place (on your server), storing plain text or reversably encrypted passwords there makes your session store an even bigger target. But let's say that's what you do.

Say an attacker obtains or engineers the user's session variable. The user enters the password but fails the form. Whoever issues a GET request with that session variable (which could be the attacker) is handed the password in the clear. This is worse than a standard session hijacking, because a standard hijacking would only allow the attacker to impersonate the user, not obtain passwords that might be valid for other sites.

Of course, you can mitigate this by any standard session hijacking defenses -- regenerating the token on load, or simply rendering on post instead to avoid the session entirely. (Please don't do that. Having the browser bug me when I reopen or reload a page is frustrating, especially since I do it a lot thanks to no-script.)

The fewer places the password exists, the fewer targets for attack. If you must do this feature, either go with Andre's comment suggestion to remove the password field entirely with a button to change it, or fill the password field with a standard, but invalid password (ie, less than your minimum length) that you can check for when you've stored a password. Just don't send real passwords, even over HTTPS.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.