Sign up ×
Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

I've recently asked a question about blanking the password fields in UX for usability purposes, but It seems all the sites use this approach for security reasons. Why is it insecure to post back the same pass that user has entered?

share|improve this question
You never send back the password. Google around about caching – Sachin Kumar Apr 24 '12 at 8:20
good point never thought about it that way. – Alireza Hos Apr 24 '12 at 17:08
@SachinKumar: How about having the server make note of the password, and send back dummy values (different values in the two fields; possibly encoding the session ID) and saying that if the form is submitted with the same dummy values, the server will simply reuse the values that were submitted before? – supercat Oct 17 '14 at 22:31

3 Answers 3

up vote 3 down vote accepted

Good question. Having the benefit of looking at some of the answers, and pondering over this myself, I actually don't see any major security benefits from clearing the password from the partial form returned to the user, but there definitely are some risks worth considering.

From a security architecture point of view (as @Roryalsop already touched on), you usually want passwords flowing only in one direction. From the user to the application, never back. This applies on all layers, and this one-way-system gives benefits from a security point of view. Having an exception to this rule might or might not be a good idea. But that's why your question is interesting. Does this scenario deserve an exception?

Lets look at some attack vectors and see if nulling the password protects against any of those:

  • sniffing the traffic - if an attacker is able to intercept communication between the user and server, it can sniff the password sent in the first place by the user. I see no benefit in emptying it on the response
  • malware on the server or client side - the same. It can intercept the initial password.
  • cached data - this was already mentioned briefly by @SachinKumar but is worth expanding. There's an increased chance that if the server returns the password with the response, it might end up cached somewhere (the server memcached, a proxy server along the path, the client's browser history etc). Client requests are never cached. Server responses are! This is probably the biggest risk I see. Proxies can be probably be eliminated from the equation by using SSL, and if the server uses correct cache-headers and sets the input field correctly, this can also mitigate browser-caching. That said, it's still possible that the value gets cached somewhere, even accidentally and that's probably not desirable.

But then, nulling the password is easy enough, shouldn't damage user-experience too much and keep things cleaner from a security standpoint. I would still suggest you keep doing so.

If you're worried about user-experience, try to follow the advice you were already given on UX - perform extra validation on the client side, just so the user gets early feedback. Don't replace the validation on the server. This is the most important validation ultimately. But for user-feedback, client-side validation can work wonders to improve user experience and you don't have to take even a slight risk of the password being cached (or change your security architecture by making an exception).

share|improve this answer
I actually emptied the pass fields, and used client side validations. Now I'm neither worried about security nor about UX. thanks for thorough explanation of the subject. – Alireza Hos Apr 30 '12 at 9:52

Why is it insecure to post back the same pass that user has entered?

Because if you then view source on the posted back page, the password will be visible in plain text. This goes against the principle that passwords should only be one way - i.e. passwords can be input but never output. For example, when storing passwords in database, these should be hashed rather than encrypted to prevent them from being extracted if an attacker manages to view the data. Following this principle everywhere will lead to a more secure system.

In this case it can prevent "shoulder surfing" and it can protect against it being cached by the browser and then later viewed.

It is possible to have a good UI and follow this principle. For example, the system could store the hashed and salted password in the server side session state, and then on the post back the form only shows the other fields. Once this have passed validation, the password from the session state is used rather than the ones that the form would have provided. Of course, care must be taken here to invalidate the session if the user does not continue with the registration process so that this password does not override the one set by the next visitor from that browser. otherwise a session fixation attack may be possible.

share|improve this answer
well it is visible to the user itself, is there something else here I'm missing? – Alireza Hos Apr 24 '12 at 17:07
I suppose it makes it more vulnerable to "shoulder surfing" attacks (in the case the user views source). None the less it's good practise never to output a password in plain text. – SilverlightFox Apr 25 '12 at 14:27
What about populating the "enter password" and "confirm password" fields with different "dummy values" of suitable length, and saying that if the fields are submitted with the proper dummy values server should use the previously-submitted values? – supercat Oct 17 '14 at 22:29
@supercat: Yes, that's what I'd do. It is really bad UX entering the password multiple times due to a validation error elsewhere and could be a security flaw itself as the user will get frustrated and type an easy to type password instead of a secure one. – SilverlightFox Oct 19 '14 at 18:15
@SilverlightFox: There may be room for argument about whether the potential confusion resulting from showing the wrong number of password dots would be more or less of an issue than having the server send something indicating the length of the password; another approach would be to superimpose "<Supplied>" on the password fields until they're modified. – supercat Oct 19 '14 at 18:29

2 key points here:

  1. If you have a mechanism to send the password back to the user, then you give an attacker a way to get that password.
  2. If you can send the password to the user it means you aren't storing it hashed, but using either clear text or reversible encryption. however as @yoav points out, in thus particular scenario IT won't yet have been encrypted, so this point is irrelevant here.

Both of these have risks.

This is why most websites have password reminder and reset mechanisms, so they don't need to send the password back to you. They may send a one-time password to you as a reset, that you must then change.

Some will send your password in an out of band route, but these are getting rarer as the risks continue to build.

(of course the security of password reset mechanisms is another matter)

share|improve this answer
Regarding point #2 : When the server gets the password from the user, it is usually in cleartext form (perhaps over SSL), it then hashes it and compares it etc. If however you do any validation prior to that and reject the form on the server, you still have the password in clear-text form regardless of the form of storage. Therefore, I think your conclusion that it means you are using clear text or reversible encryption is therefore invalid. – Yoav Aner Apr 29 '12 at 8:41
Good point - in this scenario you are right, it hasn't yet been encrypted. – Rory Alsop Apr 29 '12 at 9:34

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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