Recently I worked on a feature allowing users to change their password once logged into an application. During this there was a very interesting discussion about what security should surround such a feature. This lead me to write this post sharing my thoughts on security once a user is logged into your app.

The main security feature under discussion was whether to limit the number of times a user can attempt to change their password with an incorrect ‘current password’. My first thought was, why bother, they are already logged in right? After some discussion and consideration it was clear to me that this is not acceptable, for the following reasons:

• What if the users session has been high-jacked?
• It is never a good idea to implement a API that allows you to try a password over and over, even if this is ‘currently’ only accessible once authenticated.
• This feature is not going to decrease the UX, so why not implement it? (belts and a braces, as the saying goes).

Out of curiosity I tweeted the scenario to Troy Hunt to get his opinion. In short he agreed but acknowledged that there is a reduced risk due to being behind an authenticated session. He also posed another scenario for consideration that got me thinking:

Although I can see this is absolutely a valid security risk, I do not believe it is as important as the previous. The reason for this is that the change password security flaw may allow a malicious user to identify the users current password, thus being able to maintain access to the users account without their knowledge, and heaven forbid that you have used the password elsewhere. The ability to reset a users password gives you access to the account, but the user will know it has been breached as soon as they attempt to log in again, and very importantly the current password was never breached.

This distinction is important to me, but frankly if security is important to you then implement both.