An extra layer of security for business-critical tools
A user-friendly but solid extra layer of security to protect our business-critical tools: that's the challenge we took upon ourselves. Here's how we did it.
Two-factor authentication ftw
Due to security regulations, we've added an extra layer of authentication to our business-critical tools using two-factor authentication (2FA). This is the most widespread and user-friendly solution, combining something that you know (your password) with something that you own (eg. your smartphone) to be able to log in.
This extra layer was implemented as an Apache2 module straight at the web-server level, and functions as a proxy. The module checks if you are authenticated and if not, will redirect you to a separate page for authentication.
Extra protection kept user-friendly
The goal we want to reach by adding this extra layer of authentication is to protect our business-critical tools from exposure to hackers and people with bad intentions.
It is very easy to search for JIRA instances, ERP systems, VCS hosting and whatnot on search engines like Shodan which makes those tools vulnerable for exploits.
But while maximizing our security, we also wanted to keep it user-friendly. We don't want to come between people and their tools, so no VPN clients and complicated setups. We wanted to make the process as seamless as possible. We use our existing JIRA accounts and communicate with our JIRA instance using its REST API, no new accounts needed.
Single sign-on and fast implementation
If you look at the amount of passwords that are leaked by third parties on the internet (LinkedIn, MySpace, Netflix, Last.FM, Minecraft, Runescape ...) and take into account that most people do reuse the same password on multiple sites, we consider relying on only a password for authentication as insufficient, and require the use of two-factor authentication (2FA) where possible.
Benefits we get from this approach is that we can now enable a strict password policy and force two-factor authentication on all tools at once. We now have the possibility to implement single-sign-on (SSO) and can deliver this fast. The implementation times are very low for each tool we tackle, because it's a one line config in the webserver.
Setup for users
For the users, the setup is also just one step. The login screen will first ask for your JIRA credentials:
After successful login, the authentication-platform forces you to set up two-factor authentication (2FA). For reliability reasons (email delivery) we encourage the use of Google Authenticator.
For people who cannot use Google Authenticator, we allow the use of email. The password reset flow also uses you email. So, for obvious reasons, make sure the email account you use for JIRA is protected with 2FA by itself. The 2FA itself can only be reset by our authorized personnel.
The configuration screen for 2FA looks like this:
This setup needs to be performed only once. After that, authenticated sessions will expire every week. Next time you login, only a code will be requested:
After the authentication is complete, you will be redirected to the tool that was protected and you will not be bothered with authentication for the rest of the week.
Extra layer of security
If you authenticate once, the Apache2 proxy will setup new authenticated sessions for all other protected tools. It is an extra layer and does not replace the login procedure on the tool it protects.
If you lose access to your account, you should always be able to restore your access by using the reset procedure. In case of problems, don't hesitate to contact firstname.lastname@example.org for assistance.