|
If our organization do this, could you add this to next releases and begin to maintain it?
-JP Well.. it was not possible to do this at all.. legal issues. JP,
Currently, we are quite busy working through a list of issues that are very popular: In the past, when dealing with user contributed code, we found that it still takes quite a while to get the code (and test coverage for it) up to the standard where we can distribute it and support it. Therefore, as a company policy we cannot commit to bundling the code. If you are happy to share the code with us, we would be very thankful and will take it into consideration when actually implementing this feature. However, unfortunately we cannot commit to a time line. Cheers, It's interesting that this particular issue only received a few votes..
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 — I love your work and all your tools.. do not fall on security issues. Plz! Cheers, 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.
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, 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, 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.
Can I give you a question for answer? I think following improvements might be do what is enough at this point: ... then admin can take rights from user, if (s)he wants to lockdown the user. Is that simple enough Cheers, 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, |
||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Improvement
Open
Major
Implement user lockout mechanism to stop bruteforce login attacks
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!
http://opensource.atlassian.com/seraph/
by implementing a custom Authenticator which in its login() method will implement the required login: e.g. by simply remebering which user to lock out and returning "false" for a period of time, or by sleeping for a while before returning false.
Unfortunately, I am not sure when we will be able to implement this in JIRA. However, Seraoh is an open source project, so you may wish to look into it.
Cheers,
Anton