Should it be possible in a good software, using a “Change Password” link for a single user, to try to guess passwords for every user of a Application?

Question

I am having a fight with the "Security Expert" of my team about this very basic question and I need help in getting a good valid argument(s).

The pretext is as follows: Should it be possible/valid to try to guess/brute-force passwords for every known User of the Application, using "Change Password" link for a single User??

I asked him this very simple question: We get a 'Change Password' weblink for each account when someone asks for change password, and it seems that using that 'Change Password' link you can try to guess password each and every user of the application. Is this valid for a 'Change Password' functionality?? He said: "Yes, that's fine"

So, basically when someone asks for a "Change Password" option from our software, they get a weblink. Now it seems that using that link it is possible to try to make brute-force requests for "Change Password" for All the users of the application. My Security Expert's point is the same is also possible from the main "Login Page" as there also one can try to brute-force the password change for every user hence he is oblivious (against any need for changes!!) to the "Change Password" feature against this issue. The same brute-force detection logic seats beneath both the "Change Password" page as well as the "Login Portal" page.

Please help!!

Answer 1

One good design is to make the Change Password page accessible to logged in users in such a way that only he can change his own password. (users' identity should be bound to something out of their control(e.g sessionid) and shouldn't be sent as a parameter which is guessable and can be tampered by the user to access change password page for others)

Your application should protect against brute force attacks using solutions like captchas and/or lockout mechanisms. If there's such logic behind both of these pages then you're most likely ok, unless this kind of design is used in other parts of the application where one user can impersonate another user and make changes on behalf of others.

Answer 2

No, it should not be possible to do that!

There are several issues raised here:

1. The change password link contains the userid. I'm assuming this is for logged in users to change their passwords - so I'm a bit unsure as to why you're sending out links in that case. You know that they are authorised (or, at least have the ability to log in), so you can safely change password in this case by prompting for the old password (to prevent session theft) and the new password on a screen which requires a user to be logged in. No need for a link, and users can only change their own password if they know their old password.

2. The expert says you can brute force from the login screen. That shouldn't be possible. It could be prevented by requiring a CAPTCHA to log in, or through other brute force protection methods, such as IP rate limiting.

3. There is no protection against session stealing - upon stealing a session cookie, it would be possible to change the email address, request a password change, then change it to whatever I wanted. If this requires the old password, that is good, but it would allow for that brute force attack - if I can change the password, I guessed the old one correctly.

4. If this is a Forgotten Password system (i.e. for people who don't know their old password), it doesn't have protection against replay. Upon receiving a link, I can reset my password as many times as I want. Forgotten password links should include a one use token, so that each reset can only happen once, and, ideally, within a relatively short time of the original request.

Answer 3

Generally, you should never include leading information in your public URLs. "Leading information" here means anything that can hint the user (or anyone else) what the next or previous entry of your table look like. If you have to include the user_id in your url, at least use something like an email address to identify the user. That way, no one will really be able to guess what could be the next email address. If you think someone would still use some wicked regex and send a password reset link for every email, you could go an extra step to use some two way encryption to for any identifying info so that your link looks something like ...&userlogin=bNmaddaA_ad8... where the value could be something like a base64 encoded string that was already encoded in some other way. Of course you'd have the secret key on your backend so really trying to decrypt such arbitrary information would take some effort before the person is able to brute force anything on your server.