6

The Web application I'm working on is 100% SSL secured (or rather TLS as it is called today...). The application recently has been audited by a security company. I mostly agree with their results but there was one thing that led to great debates:

As part of the password change process for users, the user has to provide the old password as well as the new one two times—nothing unusual. In addition to that the new password has to conform to a password policy (minimum length, yadda yadda).

The application is realized with Vaadin which uses small AJAX messages to update the UI. The whole logic of the application lives on the server. This means that all validation of the password change form happens on the server. In order to validate the form, both the old password as well as the two new passwords (which should match of course) have to be sent to the server. If there is anything wrong (old password is wrong, new passwords don't match, new password doesn't conform to the password policy), the user gets an error. Unfortunately as part of the syncing process Vaadin sends all form data back to the client again—including old and new passwords.

Since all this happens over SSL I never thought twice about it but the security company saw this as a security risk of the highest severity. Note that the issue in the eyes of the security company was not that the data is sent to the server but that the server included the data in its response in case validation failed. So our current solution is to empty all fields if validation fails. This leads to poor user experience as the user has to fill in three text fields again and again if for example the passwords repeatedly don't match the password policy.

Am I being naïve in thinking this is way over the top? I mean, if an attacker breaks the encryption, they have access to the whole traffic anyway.


edit: Regarding shoulder surfing I want to make clear that no password is ever echoed back to the user. All input fields are proper password fields that only show placeholders but no actual characters.

  • You have to decide about your UX, but it's not unusual, in my experience, to have to re-enter all 3 passwords if I have made a mistake. – schroeder Jun 19 '14 at 15:58
  • The failure occurs because some of the submitted password data was invalid. Doesn't it make sense anyway to clear that data and then force the user to reenter it rather than requiring them to delete what's wrong and replace it? – PwdRsch Jun 19 '14 at 16:36
  • @PwdRsch If the old password is correct but there is a typo in the confirmation field, the old password at least could stay, couldn't it? – musiKk Jun 19 '14 at 16:42
  • Not usually. Whether it passes validation or not, passwords should be one way traffic, so clear any of those fields regardless. Do the validation only on submit. Or if you want to validate before submit, call an api that returns only success/error codes, then validate again upon form post, but always clear the password fields from a response. – Andrew Hoffman Jun 19 '14 at 17:01
  • @musiKk Yes, you could preserve the old password if the problem was with the new password confirmation. I agree that some users will be glad not to type it in again. You'll have to weigh that usability improvement against the security criticism. I tend to side with you that there's no real increased risk of disclosure, but maybe we're missing something. I would push back on the security consultants for a specific reason this practice increases risk. – PwdRsch Jun 19 '14 at 17:43
3

Actually, I'd argue that it's better UX to clear the fields. Assuming the password fields are full of asterisks, the user is going to delete the whole field anyway when they retype their password.

In addition, you're opening yourself up to a new security risk. There are possibilities for XSS, shoulder surfing, and also any time you send passwords anywhere you've increased your risk in general.

I've never visited a site that's kept the password fields filled had I entered something incorrect. The only field that has been filled was the email field, and possibly address/phone number.

You always have to assume the worst, and if you can plug a hole do so. I don't think the security auditor is over the top, especially since this is an easy fix for a really non-existent UX issue -- and if you're sending back their passwords and showing them without changing each character to an asterisk, then you definitely have a security issue. The only time somebody should see a password they enter is if they select an option to allow them to see it temporarily.

  • The passwords are never shown in the UI. All input fields are password fields that don't show characters. The passwords appear in AJAX messages only. You could even argue that having to enter the password multiple times increases risks of shoulder surfing because someone can observe the motions the user makes while type their password in multiple times. But I get your point. – musiKk Jun 20 '14 at 6:43
  • 1
    @musiKk One of the things that really drove home what your auditor said for me was that, with regards to UX, having a user delete a field his or herself is bad UX. If they can't see the characters, then they won't know what to delete. Most people just start over, right? I know I do, and I'm usually pretty good with remembering what characters I mess up on. So, if you remove UX from the equation, there's no reason to send the passwords back to the client at all. – Eric Lagergren Jun 20 '14 at 6:45
  • It is pretty common to have to enter the new password multiple times because of the password policy—even if it is displayed on screen. UX-wise there should be no need to enter the old password multiple times. For the time being I'll reset the values just as you all suggest and in the long term I'll look into client side validation of the confirmation password and the password policy. – musiKk Jun 20 '14 at 10:08
1

It's best to have a policy of passwords are only input, never output. This is a practical approach and a good step in the right direction for security with little cost.

Any passwords output would also be visible in plain text if "view source" is clicked meaning that any shoulder surfers around could view the passwords.

If it is simply asking the user to re-enter their original password, new password and confirmation then this is not a huge UI flaw. If it was a massive page and the validation on other fields causes the password boxes to blank, then this can be annoying to users to re-enter their three passwords each time, and can cause some users to simply enter qwerty or something. If this is the case I would move the password fields to another page so they can be entered and validated separately.

  • 1
    Passwords are only part of AJAX messages. "view source" is not enough but observing the decrypted network traffic is (which is equally easy if you have access to the browser). – musiKk Jun 20 '14 at 6:47
  • @musiKk: True, but browser dev tools can show the current source that represents the state of the page too. – SilverlightFox Jun 20 '14 at 7:40
0

Echoing input back to the client always raise cross site scripting XSS suspicion. But in your case, I think it is an over reaction since the output is transient and will never be shown to anyone else than who entered it. Have you tried <script>alert(document.cookie);</script> as a password ?

You could play game with your auditor by making the whole password change and Ajax call itself, never clearing the form nor changing the page. You would need only to respond with an error code adjust UI accordingly. Kind of like this :

  1. Ask for current, new and repated password in a form
  2. User clicks "Change password", an Ajax request is made to the server. Form stays, with some animated-gif-in-a-div to make the user wait
  3. If the change failed, the server respond with an error code (not complex enough, new and repeat don't match, etc.)
  4. If they don't match, clear both the new and repeat field

Just keep in mind that the old password is getting older with each unsuccesful attempt. The old password is there to ensure that the legitimate user is making the change. The more you "reuse" it, the weaker that certitude gets. You should clear everything after N failed attempts (or after N seconds).

0

I believe the reason it is considered insecure to send the passwords back to the client is because the client may cache the page, meaning there is a version of the password in plain text stored somewhere on the user's local drive. Hitting the back button or parsing the cache could reveal the password. This is especially bad on public machines.

Also, there are valid scenarios where you might want to do what the OP is suggesting. For example, if you have a registration screen with a captcha on it, having the user retype two passwords every time they fail the captcha might be overly annoying. But if your site is important enough to require a security audit, then you're probably better off avoiding this, and instead consider making your captcha easier.

  • The values are only part of the DOM that gets updated with AJAX. They never appear in a document that may be cached and the AJAX messages have caching disabled. – musiKk Jun 20 '14 at 7:02
  • 1
    If you're using AJAX, then you have the option of not wiping out all the password fields AND passing the audit. Modify the server code to not pass the values back to the client- this should satisfy the audit. You can then decide to leave certain fields on the client untouched, for example the old password if it makes sense to do so. – TTT Jun 20 '14 at 13:01
  • Yes, that would be my favored solution. However, as of now it's unclear whether this is at all possible with Vaadin. – musiKk Jun 26 '14 at 7:59
0

I don't think that re-entering the three passwords is a poor user experience, please prefer that and avoiding send them back!

Imagine that the user left the computer and some one else do something like console.log($('#oldpassword').val()); That is bad.

While you can only see dots at passwords fields, if you forget the last char, commonly you clear the entirely field, so you re-enter the whole password again.

Since SSL communications are hard to decrypt, what is being transferred between nodes? It gives a cold feeling on your neck, knowing that your sensitive data are running around and no one controls it.

so If you are clearing the password on server side, then keep doing that !! don't let Vaddin win. and on client side always discard the sensible data.

  • You raise a valid point but I think your attack vector is impossible to mitigate for me. If the user enters all data, never submits the form and leaves the computer, the same situation occurs. – musiKk Jun 20 '14 at 6:49

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.