Uploaded image for project: 'Jira Data Center'
  1. Jira Data Center
  2. JRASERVER-12380

Implement user lockout mechanism to stop bruteforce login attacks

    • We collect Jira feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

      Hacker can try as many time he wants to login JIRA.

      You can build client, which sends username+password combinations as many time as you like.

      .. and if you have username, it is much easier to get in.


      Implementation ideas:
      1) Lock user after sequential X incorrect logins

      • X can be set by administrator
      • if admin's own username is locked, it should be possible to unlock from console
        2) Set IP to blacklist (unable to try login) after sequential Y incorrect logins
      • Y can be set by administrator
      • IP can be removed from Blacklist by admin and it also should be possible to do from console

      2) can be also done by using "bullet time" after sequential Z incorrect logins

      • when hacker has been tried Z times to login then login period will take time 10 times longer
      • when hacker has been tried 2*Z times to login then login period will take time 2*10 times longer
      • .. until Y is reached and IP is set to blacklist

            [JRASERVER-12380] Implement user lockout mechanism to stop bruteforce login attacks

            When shall we get the new version? We also have to allow jira access to our customers and the possibility of hacking into one of our accounts is keeping us still. We wouldn't want sensitive information to get public.
            We're very interested in the new release..

            Thank you

            Claudiu Nicoara added a comment - When shall we get the new version? We also have to allow jira access to our customers and the possibility of hacking into one of our accounts is keeping us still. We wouldn't want sensitive information to get public. We're very interested in the new release.. Thank you

            We now track the number of unsuccessful attempts and after X are exceeded the user is not able to login until they answer a CAPTCHA question. The user password is not checked until the CAPTCHA is answered.

            ɹǝʞɐq pɐɹq added a comment - We now track the number of unsuccessful attempts and after X are exceeded the user is not able to login until they answer a CAPTCHA question. The user password is not checked until the CAPTCHA is answered.

            Ashraf Eid added a comment -

            This is a basic functionality for all organizations to protect their IP. I would like to see this incorporated ASAP.

            Ashraf Eid added a comment - This is a basic functionality for all organizations to protect their IP. I would like to see this incorporated ASAP.

            Hi,

            Is CAPTCA enough? See following page:
            http://caca.zoy.org/wiki/PWNtcha

            Cheers,
            -JP

            JP Patrikainen added a comment - Hi, Is CAPTCA enough? See following page: http://caca.zoy.org/wiki/PWNtcha Cheers, -JP

            AntonA added a comment -

            Thanks for the update.

            We are currently planning to implement this for JIRA 4.0. Unfortuantely, as we are still planning the 4.0 release, I do not have a concrete date.

            Cheers,
            Anton

            AntonA added a comment - Thanks for the update. We are currently planning to implement this for JIRA 4.0. Unfortuantely, as we are still planning the 4.0 release, I do not have a concrete date. Cheers, Anton

            I splited this to two parts (see JRA-15605).

            I think that you should implement that CAPTCHA as soon as possible and the lockdown mechanism can be implemented later.
            Also that security log could be on higher priority.


            Could you provide more information on why you would like to see account locking on top of CAPTCHA?

            Can I give you a question for answer?
            Why operating systems uses lock down of user accounts for this purpose and not the CAPTCHA? I think that CAPTCHA only slows down and lock down ends it for that user.

            I think following improvements might be do what is enough at this point:
            1) CAPTCHA after N attempts .. N can be given by administrator (if not from Web UI, atleast from .property file ... CAPTCHA is already on admin pages)
            2) Security log where administrator can see datetime, IP and username for unsuccesfully login attempt

            ... then admin can take rights from user, if (s)he wants to lockdown the user.

            Is that simple enough How fast you can do it?

            Cheers,
            -JP

            JP Patrikainen added a comment - I splited this to two parts (see JRA-15605 ). I think that you should implement that CAPTCHA as soon as possible and the lockdown mechanism can be implemented later. Also that security log could be on higher priority. Could you provide more information on why you would like to see account locking on top of CAPTCHA? Can I give you a question for answer? Why operating systems uses lock down of user accounts for this purpose and not the CAPTCHA? I think that CAPTCHA only slows down and lock down ends it for that user. I think following improvements might be do what is enough at this point: 1) CAPTCHA after N attempts .. N can be given by administrator (if not from Web UI, atleast from .property file ... CAPTCHA is already on admin pages) 2) Security log where administrator can see datetime, IP and username for unsuccesfully login attempt ... then admin can take rights from user, if (s)he wants to lockdown the user. Is that simple enough How fast you can do it? Cheers, -JP

            AntonA added a comment -

            Hi,

            I can see your point about the security log. We will see what we can do when we get to implementing this.

            As adding CAPTCHA on signup will help with brute force attacks, we are hoping that locking accounts would not be needed. We would prefer to keep things as simple as possible

            Could you provide more information on why you would like to see account locking on top of CAPTCHA?

            Cheers,
            Anton

            AntonA added a comment - Hi, I can see your point about the security log. We will see what we can do when we get to implementing this. As adding CAPTCHA on signup will help with brute force attacks, we are hoping that locking accounts would not be needed. We would prefer to keep things as simple as possible Could you provide more information on why you would like to see account locking on top of CAPTCHA? Cheers, Anton

            We should investigate the use of our existing CAPTCHA after a certain number of unsuccessful login attempts.

            This might be good improvement for this!

            This would slow down the possibility to find out usernames and password. Well.. it might be almost impossible to use bruteforce after this. Basically the idea to use CAPTCHA handles this better: "2) can be also done by using "bullet time" after sequential Z incorrect logins"

            .. also adding some kind of locking system for N number of unsuccesfully login attempts is on our MUST-list. One boolean field for the username.. plz


            As a administrator, I would also like to see somewhere, that has there been unsuccessful login attempts and where those are coming from. I also would like to see, on which usernames has ben tried to attack. Would it be possible to add one security log, where admins could get information unsuccessfully attempts?


            There is also other side on this problem, which this improvement does not help. This might be more theoretical... and I think that it is not that big risk.

            If hacker would like to "shut down" the service, they can use load which blocks connection to the service. I think that my idea to make IP blacklist does not work on that, because it is too easy to fake IP addresses.

            .. and there is many IDSs(Intrusion detection systems) for this.. so I think this feature is not needed for JIRA.

            Cheers,
            -JP

            JP Patrikainen added a comment - We should investigate the use of our existing CAPTCHA after a certain number of unsuccessful login attempts. This might be good improvement for this! This would slow down the possibility to find out usernames and password. Well.. it might be almost impossible to use bruteforce after this. Basically the idea to use CAPTCHA handles this better: "2) can be also done by using "bullet time" after sequential Z incorrect logins" .. also adding some kind of locking system for N number of unsuccesfully login attempts is on our MUST-list. One boolean field for the username.. plz As a administrator, I would also like to see somewhere, that has there been unsuccessful login attempts and where those are coming from. I also would like to see, on which usernames has ben tried to attack. Would it be possible to add one security log, where admins could get information unsuccessfully attempts? There is also other side on this problem, which this improvement does not help. This might be more theoretical... and I think that it is not that big risk. If hacker would like to "shut down" the service, they can use load which blocks connection to the service. I think that my idea to make IP blacklist does not work on that, because it is too easy to fake IP addresses. .. and there is many IDSs(Intrusion detection systems) for this.. so I think this feature is not needed for JIRA. Cheers, -JP

            Brian Lane added a comment -

            Most public facing sites implement a strategy after N number of unsuccessful login attempts the user is prompted to enter username, password and answer a CAPTCHA.

            We should investigate the use of our existing CAPTCHA after a certain number of unsuccessful login attempts.

            Brian Lane added a comment - Most public facing sites implement a strategy after N number of unsuccessful login attempts the user is prompted to enter username, password and answer a CAPTCHA. We should investigate the use of our existing CAPTCHA after a certain number of unsuccessful login attempts.

            JP Patrikainen added a comment - - edited

            Maybe it was missed by many, or there is another issue that has not been linked to this yet, but I would have thoguht that this would be very high on the list, from a security point of view - Especially if a JIRA instance is public.

            I agree.. if you have a public JIRA instance this is real threat. I would not like to advertise this kind of security problem to get more "votes". I would like to have this fixed.

            Sorry already, but this is more like "MS" style to react on this kind of problems.. fix it when the hackers show that they control the world and also your JIRA instance Mayby someone could code a software, which hacks the usernames & password from here and send those to Atlassian support.. hmm.. did I already say that I am sorry!

            I love your work and all your tools.. do not fall on security issues. Plz!

            Cheers,
            -JP

            JP Patrikainen added a comment - - edited Maybe it was missed by many, or there is another issue that has not been linked to this yet, but I would have thoguht that this would be very high on the list, from a security point of view - Especially if a JIRA instance is public. I agree.. if you have a public JIRA instance this is real threat. I would not like to advertise this kind of security problem to get more "votes". I would like to have this fixed. Sorry already, but this is more like "MS" style to react on this kind of problems.. fix it when the hackers show that they control the world and also your JIRA instance Mayby someone could code a software, which hacks the usernames & password from here and send those to Atlassian support.. hmm.. did I already say that I am sorry! — I love your work and all your tools.. do not fall on security issues. Plz! Cheers, -JP

              bbaker ɹǝʞɐq pɐɹq
              7cbccd93ce2e JP Patrikainen
              Votes:
              9 Vote for this issue
              Watchers:
              8 Start watching this issue

                Created:
                Updated:
                Resolved: