Username and password based login is often seen as the weakest link in authentication – too often people choose weak passwords, write them down or reuse them. So on their own they are an easy target for hackers. But it need not be this way, if you have the ability to implement a few additional features into the login process, you can make it that much harder for a hacker, even to the extent that they will give up and go elsewhere.

It should also be remembered that certain classes of users (the elderly and the disabled for instance) may not be able to use or afford modern smartphones or other devices to implement MFA (Multi Factor Authentication) – so we need to do our best to ensure username/password based login is secure and useable in such situations.

In this article we will cover a some simple techniques, along with a few advance techniques, on how you can strengthen username/password based security. You can also use this article as a checklist for when you have to integrate with a 3rd party who only offers username/password based login.

1. Defeating password guessing

Before we do anything with the core username/password authentication process, there are a few simple things that need to be done to dent or completely stop scripted dictionary password attempts. Such an attack is where the hacker either doesn’t know the username and password, or they just don’t know the password (say you allow an employee email address as a username instead). There are four key approaches to denting this attack.

The first is to log failed attempts to login, and record in that log the source IP and User Agent (more later) at least. Now with the source IP you can use tools like fail2ban to implement max failed attempts per source IP, so if the hacker exceeds the limit in a given timeframe, they get banned from accessing the login service for a period of time. Using tools like fail2ban is great as usually you don’t have to modify you code and you can configure fail2ban to pick up on other failures, say mismatches on the password reset form and feed it into the same ruleset for analysis.

The second technique is to have a form crumb tied to the session cookie, this forces the script to be complex enough to load the whole page and cookie, then submit the username/password guess, with the crumb and cookie, in order to have a valid attempt. In essence, when you create the form, you generate a random number, store that random number in the session record and put in an additional field in the form (say called crumb). Then when you process the form, check for the submitted crumb matching what was stored in the session record, and immediately afterwards blank the entry in the session record. You can also use the same crumb technique on the password reset form.

The third technique is displaying a captcha immediately on a wrong password being entered. This avoids the need to trigger the captcha off some failed attempts counting metric, you just need to have a flag in the user record indicating ‘showedCaptcha’, so successful login needs both a correct password and successful captcha challenge.

The fourth technique involves ensuring people choose sufficiently complex passwords, avoid the old ways of wanting a mix of uppercase/lowercase with some digits and special symbols – it just encourages people to reuse passwords. Instead lean towards longer phrase based passwords, they are much more memorable and much harder to guess. Say mix up: significant places, people and objects not known to an external observer. Also, with sufficiently long unique phrases, the need to force periodic passwords changes on people can be relaxed in certain situations, again this can cause excessive password reuse and formulaic passwords.

2. Closing the barn door

The biggest problem with most username/password login systems is they are just open to everyone. Anyone on the planet can typically access a login page and be considered valid to try to login. This is just wrong, 99.9% of logins are from machines that logged in previously and we should make good use of that to improve security. Below are a few techniques which can make use of this.

First off is making use of the source IP (IPv4 the /24, IPv6 typically the first half) as a location tracker in effect. This way if a user keeps logging in from the same place, on additional security controls come into effect. If they try to login from a previously unseen IP, you should not allow them to login and send them an email to confirm the IP is indeed them. If they do confirm, you will then allow the login to proceed. In effect the email contains a signed link that encodes the IP and directs to the login form. The session then contains that IP as an ‘approved IP’, and once they login successfully, the IP is added to the allowed list. Note: The allowed IP list should expire unused IP’s after a month.

Secondly, make use of the browser by planting a long lived cookie on it, the cookie contains a signature created from the username and the browser User Agent at least. This way a hacker can’t just take the cookie and replay without setting up the whole browser environment as well. If a user tries to login without a valid long lived cookie, they fail to login and a similar email is sent to the one above to give them a path to verify their browser.

Thirdly, login form pages should not be pulling in all sorts of 3rd party dependencies. The risk here is that the 3rd party behaviour tracking or analytics code could get compromised by a hacker or it could be ‘noisy’ and record authentication information by accident. Ideally keep 3rd party dependencies on login pages to an absolute minimum.

Fourthly, if you know employees should only login from a well known set of IP’s (say the corporate IP block) ensure this can be supported as a login restriction. In a SAAS context this should be able to be set up at the customer record, so all login accounts for that customer are automatically restricted.

3. Limit Impact

This goes for all methods of authentication (MFA or not), once a hacker obtains access into a system, the only thing reducing impact is what they are able to do with that login. Therefore you need to ensure that the permission system in the product is sufficiently fine grain and scoped that the impact is contained. Below are some techniques that can be applied.

First off, ensure actions mimic real world processes in terms of their permission structure. In effect , if an action required a two person sign-off in the real-world, the same MUST apply in the product. This way a hacker cannot short circuit safeguards. Its not good to enough to simply notify a manager that something is being done, approval must be required before and be blocked until approval is gained. Too many systems fall back on the sensitive operation notification model and when a hack occurs out of hours, you will find out too late to do anything. Also the notification will often not contain an ability to block the action, making it even more useless, the manager will have to track down someone in IT to look into it and stop whatever is going on. This just doesn’t work, so don’t even do it; approvals are hard gates, no other way.

Second, implement user behaviour tracking. This could be as simple as providing a user access log of activity, all the way through to behaviour analysis to find ‘out of band’ actions that should be notified to management. In this way unusual out of hours access could be flagged as soon as it happens. You could also use this to implement authentication scoring, i.e. analysis the when, where and what of a login attempt and have a validity threshold to permit the login.

---

We hope the above article has been informative and provides you with some pointers on improving the security of your username/password login service without inconveniencing the users. If you would like to know more, please contact us or buy our book .