2

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!!

  • 3
    What does the 'Change Password' weblink look like? – Mark Koek Feb 2 '16 at 13:10
  • 2
    How do you mean that you can guess other user's passwords from the change password link? Please could you edit and elaborate on your question a bit more. – SilverlightFox Feb 2 '16 at 14:01
  • 1
    @MarkKoek the link looks like: localhost/backend/… This "userlogin" parameter can be replaced by any valid user of the Application and you can then try 'Change Password' for that replaced user instead (yes, I know an awesome bad design to trust the end user input from the browser for the actual "userlogin" parameter instead of doing it in the backend normally - already reported that :)) – Deb Feb 2 '16 at 14:55
  • "Try" to change the password - what would stop them succeeding? I would guess you are saying you need their previous password to actually change it? As I said, please edit your question and add the extra details so it is easier for others to understand without reading all of the comments. – SilverlightFox Feb 3 '16 at 14:56
  • OK. If the response to that URL gives an error for a non-existent user I would report a (minor) security issue because anyone can enumerate valid user names. – Mark Koek Feb 4 '16 at 11:56
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.

  • @Silverfix Indeed, my thoughts actually!! A 'Change Password' page should be only accessible to logged in users, and Only for that user for whom it is intended. :) There is indeed protection against brute force attacks using captchas and lockout mechanisms. – Deb Feb 2 '16 at 15:00
0

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.

  • How are you reaching the conclusions you mention in points #3 & #4 with the information Deb provided? – PwdRsch Feb 2 '16 at 16:31
  • #3 is extrapolating from the "send a weblink" thing - it must go somewhere, and the most common transmission method is email. #4 is based on the comment at security.stackexchange.com/questions/112520/… – Matthew Feb 2 '16 at 16:33
  • I understand that it's an emailed link, but how do you get "session stealing" from that. It appears the link simply takes the user to a change password page where they have to provide their old password before choosing a new one. I would assume there isn't a session associated with the user's ID until they provide their old password. The same goes for #4 since this doesn't appear to be a reset link that includes a token. So it can be reused but its reuse doesn't provide an attacker with any advantage since the page still must prompt the user for their old password. – PwdRsch Feb 2 '16 at 16:39
  • Unless the email change prompts for the existing password (which is possible, I agree), it would be possible to obtain a valid reset link, even if the backend system was cross-checking the reason, project and userid. I'm working on the logic that you need a session in order to change the email address. It doesn't provide a method to steal sessions, but it provides a way to abuse sessions stolen in other ways. – Matthew Feb 2 '16 at 16:50
0

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.

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.