From online quote & buy journeys to card payments systems or full customer and adviser policy administration portals. From back-office policy administrations systems to specialist actuarial tools or systems to streamline and automate account and asset transfers. Whatever the system we must ensure that legitimate users - and only legitimate users - are allowed in.
Getting this "front door" check right is critical - but unfortunately seems too often to be a weak spot. The Verizon 2020 Data Breach Investigations Report showed once more that stolen credentials are the leading tactic used by hackers - continuing a theme which has been consistent since 2017.
And with the 86% of breaches being financially motivated, Financial Services organisations are a key target for both internal and external attackers.
3 Key Questions
When determining whether a given user should be granted access to a website (or any other system), there are 3 key questions that need to be answered:
- Identity: "Who are you?"
- Authentication: "Can you prove it?"
- Authorisation: "Are you allowed in?"
Based on the answers to these questions, the website can determine whether to allow access to the system and the data it holds. It can also use the user's identity to, for example, provide user-specific defaults and preferences, and to maintain audit trails of the actions taken by each user.
Typically, users are identified with a username or user ID - either one they chose themselves ("johnnyboy1983"), or one assigned automatically by the website ("SMITH123").
Usernames must be unique across all users of the website - "johnnyboy" was sadly already taken so this user added their birth year to make it unique.
Fortunately, most users already have at least one identifier which is used only by them - an email address (“firstname.lastname@example.org”). Many websites allow users to use an email address as their username - avoiding the need for users to pick (and remember!) a username for each website they use.
User names are not considered secret - for example, they are normally visible as the user types them in, and they may also be visible once logged in ("Logged in as: johnnyboy1983").
It is not enough just to identify the user, we also need to authenticate them - i.e. to get them to prove that they are who they say they are. The most common authentication mechanism is to use a password alongside the username.
Unfortunately, humans are really bad a making up hard-to-guess passwords. If given the option, users regularly choose very simple passwords (e.g. "password1!", "123456", or "Summer!2018"), or their date of birth (e.g. "050778").
An attacker with access to a list of possible usernames (e.g. from a big list of email addresses) and a list of the top 100 common passwords might try to login with each username with each password -- and they would have a pretty good chance of getting lucky on at least one account. Microsoft report millions of such attempts being made every day, resulting in 100s of thousands of accounts being compromised daily.
To try to prevent users from choosing such easy-to-guess passwords, websites typically require passwords to meet certain defined complexity requirements - for example, "must be at least 8 characters", "must contain a mix of upper-case, lower-case, digits and punctuation characters". Some systems also provide a password strength indicator, to help users avoid poor passwords.
Increasing the length of normal alphanumeric passwords slows down hackers more effectively than requiring the password to include punctuation characters. Research shows that "use multiple character sets" rules lead people to choose bad passwords - for example using an initial capital and either adding "!" or "$" or using one of a few simple character substitutions (e.g. "3" for "e", "@" or "4" for "a"). For this reason, NIST no longer recommends the use of such rules.
Good systems should take this into account, for example, allowing alphanumeric passwords that are suitably long, and specifically blocking the use of commonly used and weak passwords which would otherwise be allowed (e.g. "Pa$$w0rd", "Summer!2018").
With password strength controls in place to prevent users choosing the weakest passwords, it's much harder for an attacker to guess a password -- instead of just trying the 100 (or 100,000) most common passwords, the attacker might need to make many millions of guesses before they are likely to chance upon the correct password.
Now, computers are really good at performing the same operation millions or billions of times every second, and unlike humans, they don't get bored or forget their place. So we also need some way to stop hackers from just making lots of login attempts until they find the right password. The system will typically be designed to "lock" the account if more than a small number (e.g. 3 or 5) of logins are attempted with the wrong password. This stops an attacker from trying to log in as a particular user by guessing a different password each time. The system should also be designed to alert its operators when higher numbers of failed password attempts are made, so that they can identify and block the source of the attack.
We Can Remember It For You Wholesale (if you don't have Total Recall)
Of course, passwords which follow these complexity rules tend to be harder to remember. Forgetting a password might mean losing access to an important account, leaving customers unable to pay bills or access funds. In some cases, forgetting a password may cost millions.
Password management software - either built in to the browser or operating system as in iOS and Chrome, or as a third-party product or service, makes using such passwords easier for users to manage. Password management software helps by:
- Creating random passwords which are very hard to guess
- Storing those passwords so that the user doesn't need to remember them
- Protecting the stored passwords with a single super-strong master password
In the past, it was quite common for websites to block the use of "auto-complete" features for password entry. Some websites even went to extreme lengths, blocking "copy-and-paste" functionality too in an attempt to prevent this.
It is now generally recognised that such tactics are counter-productive - better to reap the benefits of password management software in encouraging and enabling users to use good passwords - without them having to remember each one (or, more likely, write their passwords down on a sticky note!).
Of course, if you use a password manager, it becomes the "crown jewels", holding the keys to all your accounts. A strong master password must be set - for example a randomly generated mixed-case alphanumeric password with at least 13 characters (e.g. "AVg5yWdQXqGFZ"), or perhaps a "diceware" password with 6 or more words (e.g. "stowaway marsupial extent silver bullseye talisman"), which some may find easier to remember. It is also important to remember to set screen locks on the password manager app and devices, to ensure that someone who finds your device doesn't gain access to all of your passwords.
Is A "Strong" Password Enough?
Now that we've annoyed our users by requiring their password to have at least 8 characters and a mix of upper case, lower case digits (and perhaps punctuation too) - and perhaps encouraged a few of them to use a password manager - does that mean we can now rely on passwords to authenticate our users?
Sadly not, as we'll see in the next article.