3

I want to ask if there are any security risks for the login authentication and change password on the same page?

Normally the user needs to authenticate first in order to see the password change form. I have seen the login authentication and password change on the same form with 4 fields (User ID, Password, New Password to Change, Confirm the New Password) that combines both authentication and change password functionality. This https://myaccess.ucsf.edu/myaccount/changePassword is an example page. You can see it allows the user to authenticate and change the password on the same page. I just wonder if there are any security risks? This is my first time to see that approach. Normally the user needs to authenticate first in order to see the password change form.

Improve this question

5 Answers 5

Reset to default
1

Normally the user needs to authenticate first in order to see the password change form.

By entering the user name and password, the system should first authenticate the user and once authentication is successful, the password should be changed. This is something that can't be verified using the example URL you gave.

However, in this case I would recommend to have an anti Cross Site Request Forgery mechanism implemented in this specific form in order to validate the origin of the request.

In addition, it is recommended to implement some sort of anti scripting mechanism to prevent bots from guessing credentials and then change them upon a successful login. E.g.: rate limiting or captcha after x amount of failed requests.

As far as your question if there are any security risks, my answer would be: There might be, but it highly depends on the implementation. Unfortunately this is not something that we can determine without having an account on one of these applications.

From what I can see on the example page you gave us, there is no anti CSRF mechanism in place, which in theory could start a brute force attack on your behalf if you would visit a malicious website that contains this type of code.

Improve this answer
2
  • Does anti-csrf even matter on a form like this? In order for a CSRF attack on this form to succeed, wouldn't the attacker need to know the user's password? Also, AFAIK the same-origin policy would make a brute force attack conducted from the user's PC in this way pretty useless, since the attacker would have no way of knowing if the attack succeeded.
    – Ajedi32
    Jul 16, 2015 at 15:55
  • Though of course, IMO it's probably a good idea to include protection against CSRF on every form whether it supposedly matters or not. Better safe than sorry, and since most development frameworks have this sort of protection built-in it likely won't require much additional effort on your part.
    – Ajedi32
    Jul 16, 2015 at 16:06
0

One of possible risks is that such form doesn't require cookies or session support to login using stolen password and immediately change it.

From the perspective of rogue software authors, there are many possible languages and frameworks, that can be used to create their software. Each of these require some knowledge to start. Eg. creating a bot that is able to automatically login to the webpage and steal some information, required at least basic knowledge, how http session works, how cookies work etc. So for most such pages it's rather easy but not trivial to create such bot.

But when you create a form that allows 2 things using 1 request, you're making it easy to write a bot that will immediately change the stolen password to prevent the user from logging in and thus giving the attacker some time (before password reset by notified administrator) to look around for more interesting information.

Improve this answer
7
  • 1
    In fact there is a JSESSIONID cookie when first visiting the example website. If you are able to write a bot that performs one request, it really doesn't matter how many requests are required to perform such actions.
    – Jeroen
    Jul 16, 2015 at 7:57
  • Are you sure? Then try to create such bot in eg. Visual Basic 6, or VBScript. The number of requests using common data (like session cookie) matters for some languages and frameworks.
    – Tomasz Klim
    Jul 16, 2015 at 8:02
  • I actually created something like that in Python before, it also read the anti CSRF token in order to perform other requests.
    – Jeroen
    Jul 16, 2015 at 8:05
  • It's easy in Python, since you have very powerful libraries that support cookies. Once again, there are languages that have required functionalities, and languages that don't. By requiring multiple requests in a session, you reduce the number of languages and frameworks, in which someone can create a malicious bot.
    – Tomasz Klim
    Jul 16, 2015 at 8:08
  • Why would I, as an attacker, use a more difficult language to create a bot if I can do it all in Python? :)
    – Jeroen
    Jul 16, 2015 at 8:13
0

In general, no. There are no significant additional security risks associated with this approach.

Any attacker who can successfully change the user's password using a form like this could just as easily log in to the user's account and then change their password. Either way, the same information (username, current password, new password) is required.

Change password forms are usually placed behind a login form for reasons of convenience, not security. If a user is already signed in, it's inconvenient to force them to enter their username again before changing their password.

That said, there are the usual security risks to be aware of with a form like this. Basically, any protections that you'd normally put on a login form you'd also have to also put here. This includes rate-limiting password change attempts, and protecting the form against CSRF (particularly if the application automatically signs users in when they change their password).

Improve this answer
0

I think there are pro/cons for both approaches. Remember that generally you need to think about a layered approach.

First off, is this more useable, is it confusing the user, etc. More fields at one time may lead to more use confusion, typo frustration, etc. Perhaps the user gets frustrated and that results in them using a less complex password (theoretical in this case, but UX is very important for getting people to play along well with security). There is a UX benefit to having to go through less pages. Keeping to well understood flows and uniform design is also important to assist users in identifying phishing - if things are constantly changing or are different the user may be confused.

I would be more concerned about what is happening up and down the rest of my stack in this case. What else besides username is being used to identify the user? Are there browser cookies, browser fingerprints, etc. If all of these things only come into account for an authenticated user, you may wish to prohibit a high risk action until after authentication. If you have reasonable assurance of the user's identity then it may not as much of a risk in balance with the UX side.

My guess would be that in general when developers make this choice its not necessarily with security goals or security reasons in mind. It may be easier for their user flow or help desk to provide these links rather then give instructions that include login and then navigating somewhere. It may also make sense from the developers point of view to segment out each function like this.

I would generally like to see a successful authentication and then request re-authentication for a password change. I think this also provides more compartmentalization (removes identity from the picture) which probably would lead to less security related bugs; you are also restricting the privilege only to already authenticated users. I agree with some other responses that there is a risk oflockout/DoS with putting this function before an initial authentication.

Improve this answer
0

From a security point of view, this should be fine provided the page protects against user enumeration and password guessing.

It should validate the old user ID and password combination as a whole, and not specifically inform the user if the user ID does not exist - it should just output a generic error message:

Your current user ID and password combination was incorrect. Your password was not changed.

After an small number of incorrect user ID and password combinations against a username it should throttle the responses to slow any password guessing attack, making the attack infeasible. It must also do this for invalid user IDs, as to not leak timing information as to whether the user ID related to a valid account or not.

One advantage of a form asking for the existing password is that this inherently protects against CSRF. Any external domain attempting such an attack would not be able to provide a valid current password. This is mentioned in the OWASP Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet as Challenge-Response reauthentication.

The only drawbacks may be at a UI level. As the browser will blank the password fields in the case of any server-side validation failing, the user will have to enter their current and new password twice again.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .