1

When a user wants to change the password for an account most web applications present a form where the user needs to enter the new password and the old password. So far I thought that I understood the benefits of this approach. For example, the old password is an additional mitigation to CSRF and it avoids account hijacking (i.e. change the password for an account) if an attacker gets the web session.

At Google - of course ;) - it is different. When the user clicks on the link to change the password a login form is presented and the user has to re-authenticate. After re-authentication a form is shown where the user just has to enter the new password. The old password is not required again.

There are some pros and cons with the approaches:

  • Asking for the password right there where the change happens (first approach) has the advantage that the risk that weaknesses in the whole process can be exploited is greatly reduced. The new password and the old password are processed as a pair. If something goes wrong (e.g. an attacker is able to set an arbitrary user for the web session) then there’s the high probability that the old password still protects the password change.
  • For the second approach (Google) there could be weaknesses in the process after re-authentication (e.g. CSRF protection could fail, bugs in session management).
  • The second approach has the advantage that the application to change the password is not accessible before re-authentication. So weaknesses in the application are not accessible before re-authentication as well. Weaknesses which are not accessible cannot be exploited.
  • Maybe Google wants to implement just one way for doing authentication. I think Google uses some kind of risk analysis for the login and that it could be possible that Google simply wants to use those mechanisms for the password change process as well.

In my opinion the risk for weaknesses in the second approach are much higher especially because there can happen a lot of things between re-authentication and submitting the new password. Also, I think that reusing risk analysis and stuff like that should be possible without great effort for a password change process as well.

So my question is do I miss something that makes the second approach (Google) superior?

3

My guess would be that for google it allows them to handle all their various different options for TFA(two factor authentication) more easily. Off the top of my head they support 3 or 4 different methods at least. They also allow you to have multiple TFAs enabled at once so you can pick which one to use.

Not saying you couldn't also handle all that on the same change password page with the old and new password fields but it definitely is more complicated than just asking for the old password along with the new one.

1

It's because people walk away from their computer, leaving them unlocked and logged in.

The second login requirement means that the guy in the chair next to you can't steal your account when you go to get more coffee or if you have to run for your plane and forgot to log off or if someone steals your session

They do this for anything security-related.

There's really no down-side.

0

One thing to consider is that Google has spent a lot of time engineering its authentication system -with what amounts to a PHD-level think-tank of engineers. It seems as if protecting the password change form is just another implementation of that functionality -such is the purpose of portable and reusable code. IMHO, it should be leverage more often. This way developers don't have to build what is basically a second form of their authentication system (i.e. oldpw == currentPW ? changePW : returnError) when the original one works just fine.

You are correct in your assessment that weaknesses in a PW change form that is not accessible without logging-in, present as decreased risks.

Properly developed and implemented, I don't know that one version of this story is better than the other (as you've demonstrated both have pros and cons) so I think it comes down to preference, architecture, and business decisions on where to focus their developer's time and efforts.

0

It would have made sense to me if they asked for the second factor too in the re-authentication, but they don't. And the new passwords page needs re-authentication if opened again. So its very similar to the 1st case but split into 2 pages. So no opportunities for CSRF.

I GUESS it was more of an architectural choice rather than security. Plus old and new passwords in the same page is too mainstream for Google I guess XD.

Really want to see a better reason than this though.

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.