Adding more Security to JIRA


I made a post a few years ago about monitoring JIRA for suspicious user activity.

In this post I want to give some ideas for how to increase security of your JIRA.

Addition Security Measure Ideas

1) Force the user to input a ‘strong password’

There is a post on JIRA support that contains an user-uploaded changepassword.jsp that has been amended to do a javascript check of the users desired password.  The javascript ensures that the user has input more than 8 characters, used a combination of lower/upper case and has added a number etc.  This prevents people from using stupid passwords like “cat1”.

2) Suggest users to make their password memorable

If the password can be easily remembered, the user will be able to access from an alien PC (hotel, business trip etc) without bothering you to reset it for them.  Also, it reduces the chance of them writing it down on a postit note and sticking it on their monitor or in their top desk drawer.

To do this, on the changepassword.jsp I added some HTML to suggest to the user that they make the password memorable for the reasons above.  I also suggested they use [location] + [year] as their password.  e.g.  london1969.

3) Do not send out username and password in the same email

By default, JIRA will send out an email like this to the new user upon creation:

A JIRA account has been created for you at:

Here are the details of your account:
Username: bobsmith
Full Name: Bobby Dong Smith
Password: coolpassword

There is some chance of this email being intercepted on the way, so it may be better not to show the password in this email.  Instead, you can send it to them in a separate email.

To do this, you need to change the password line in userdetails.vm as follows:

$stringUtils.leftPad($i18n.getText(“template.user.details.password”), $padSize): $i18n.getText(“PASSWORD WILL BE PROVIDED SEPARATELY”)

This will replace “coolpassword” in the above example with “PASSWORD WILL BE PROVIDED SEPARATELY”

The userdetails.vm file can be found in this path:


There is some discussion about this on JIRA support.

4) Prevent automated hacking by banning an IP if it repeatedly fails to login

You do this with fail2ban, as suggested by Atlassian.

This works great, however you have to be careful.  Some offices will share one IP among all their users. If one user forgets his password and tries to guess it, he will ban the whole office from JIRA.  Therefore, be sensible with the fail2ban settings.  I would imagine something like a 2 minute ban when the user fails to login 8 times in a minute would be a reasonable balance of user friendliness and protection from a brute force attempt.

5) Delegate responsibility!

Hopefully the ‘project leads’ of your JIRA projects are familiar with the system and can competently manage users/security schemes etc.  I would suggest to make them as responsible as possible for the users in their project (or Space in Confluence), by teaching them how to use the system, the need of security, and even giving them an annual online test!

You can also use the Watch and Follow functions of Confluence to make sure that Line Managers and Space Admins are being informed of what is going on in their space.

6) Confidentiality Agreement

If you have anything tasty on your JIRA/Confluence, you may wish to draw up a confidentiality agreement and get all users to sign it before they can access.  You could do this online using surveymonkey or similar service.  You may wish to do an annual review and get all users to re-sign.

You will have to judge how you want to use the agreement:

  • just to influence users to be careful –> make a document plain English with reasonable guidelines
  • to hold them accountable in court should they abuse the system –> get a lawyer to make a huge document of legalese

Good Luck

I hope these ideas are useful to you.

If you have any good ideas, I would love to hear them – please comment!


2 thoughts on “Adding more Security to JIRA

  1. Another nice post – thanks !

    Regarding #5, I’d dearly like to give project admins as much responsibility as possible to manage things that affect their own projects, such as custom fields, screens, issue security schemes and workflows. However, most of these seem to require that the user be a full-blown JIRA administrator to be able to make changes, and our auditors don’t like it if we have too many JIRA admins. Do you have any good ways around this ?

Comments are closed.