Identity lies at the centre of the biggest security issues today. Authenticating to IT services is not as straight forward as you may believe. Userids and passwords have been the staple method but as previously discussed in this magazine (OHM33, p31) password strength continues to be a major issue and over 8 out of 10 security breaches are password related (1). We know that simple 8 character passwords can be cracked in a matter of minutes.
Strong Passwords
Let’s look a little deeper into password strength. Passwords can be made up of upper (U) or lower (l) case characters, digits (d) or special (s) characters, though not all log-in services make use of all 4 classes. So a typical password may be of the form Ulllllds.
What analysts have found is that users use the exclamation mark (!) more often than any other character, and if required to use a capitalised character more often than not make it the first character of the password, and the digit(s) are placed towards the end of a string (2). Human nature? Work by Kore Logic have identified over 100 patterns (topologies) which correspond to more than 60% of passwords used (over 80% of passwords in the case of the infamous LinkedIn breach). As the majority of users are using just a small range of patterns then anyone cracking a password database can focus on these and crack the passwords even quicker.
On the system side there is continued use of compromised techniques for hashing passwords in the system. SHA-1 and DES encryption are just two of the many long-used encryption techniques still used to hash passwords. To some extent the IT industry has been its own worst enemy in not reacting to changes in the security environment.
OWASP (the Open Web Application Security Project, www.owasp.org) have championed scrypt for hashing because it requires substantially greater compute resource to crack encrypted passwords. The IT community are moving toward this standard and RFC 7914 was released in 2016 (scrypt was first developed in 2009!).
8 character passwords are no longer to be trusted. NIST (National Institute for Science and Technology) in the USA recommend a minimum of 10 but that is just delaying the inevitable. OWASP recommend that passwords must meet at least 3 out of the following complexity rules:
- at least 1 uppercase character (A-Z)
- at least 1 lowercase character (a-z)
- at least 1 digit (0-9)
- at least 1 special character (punctuation) — do not forget to treat space as a special character too
- at least 10 characters
- at most 128 characters (to allow for pass phrases)
- not more than 2 identical characters in a row (e.g., 111 not allowed)
They also recommend banning the most common password topologies (3).
Think of the user
While these additional rules make stronger passwords the process becomes more onerous for the user. Remembering longer passwords which are not easily memorable will in itself cause issues. Users will write down their passwords and store them insecurely (post-it notes stuck to the monitor?). More password resets will be another result.
Passphrases meaningful to the user are a useful option if your system supports long passwords.
“Customers expect you to take precious care of their private information but that doesn’t mean they will tolerate a cumbersome authentication and access experience, especially if a competitor is easier to do business with.” (4). There has to be a balance between usability and security.
So how to solve the authentication problem and keep users productive and corporate information secure? Traditionally the next stage is to add another step to the authentication process.
Authentication is based on something you know (e.g. a password), something you have (e.g. a token) or something you are (biometrics: fingerprints or iris scan etc). This allows you to build up two factor (2FA) or multi-factor authentication. 2FA has been around for a long time in the form of synchronised tokens (e.g. RSA Securid) and fingerprint biometrics.
Risk Based Authentication
There is another option however that is beginning to look attractive to many organisations. This is Risk Based Authentication, otherwise known as Adaptive Authentication, and it’s available with the latest releases of MF Access Manager. Basically the context of an authentication request will tell you a lot about whether it is the real user doing the login.
For example a user with a valid userid and password logging in from an unusual location (especially when they last logged in at head-office just a few hours before) on an unknown device and unusually requesting high priority files will flag up a high level of risk to the extent that the log-in is rejected. The diagram below illustrates the principle. This is the basis of risk based authentication and it can be used as part of a multi-factor authentication solution or on its own.
A solution such as NetIQ Access Manager has to accumulate all the metrics relevant to the user, and these are stored in a central database (secure the database as it’s a critical component!). Access Manager requires an Oracle, MySql or MS-Sql database outside of the main Access Manager configuration.
With Access Manager risk based authentication (RBA) can be configured in one of two ways by assessing the risk and mitigation options before authenticating a login attempt or after the login attempt.
If assessing the risk before authentication then there are a number of parameters you can use to develop the risk score:
- IP address
- Cookie
- HTTP header
- Geolocation
- External parameters
- Time of login
- Device fingerprint (without user attributes)
- Custom rule (without user attributes)
The next step is for the risk score to be compared to defined risk levels. You can define the risk levels based on the sensitivity of the information. After the risk level is identified, the authentication mechanism is selected and the user is authenticated. In cases of high risk, the user is either denied access or is required to go through additional authentication methods.
For example you may require users logging in from outside the corporate network to authenticate via 2FA while a simple userid and password combination is sufficient when on the network.
If you choose the post login authentication method then you can use more user attributes to build up the risk score.
Custom rules are a powerful addition to the process. Scripts (using a custom Java authentication class) can be added to the risk assessment engine that enable organisations to specify specific authentication rules; for example prevent user login from India, say, if the user was logged in the USA in the previous 12 hours.
RBA provides organisations with many fine-tuned options. Consider the following scenario5 where a company wants to protect its payroll application. Risk-based authentication enables the company to achieve the following actions:
- Restrict access to its contractual employees.
- Grant access to permanent employees during the company business hours between 9 a.m. to 5 p.m. After business hours, all employees must specify a one-time password in addition to login credentials.
- Grant special privileges to employees who work in the Finance department. For example, the company does not ask employees of the Finance department to specify a one-time password even if they log in after business hours.
- Grant access to the Self-Service tool along with the payroll application when contractual employees use Intranet to log in.
- Determine actions based on the priority of rule conditions. For example, type of employment is the most important criterion to grant access followed by the location of the user, and then the time of the login attempt.
- Grant access without any additional authentication if the user has successfully logged in within one month.
- Restrict access when an employee tries to log in from a specific geographical location.
- Grant or deny access based on the version of the web browser used for the login attempt.
- Deny access to any login attempt that originates from a handheld device.
While it is a good idea to strengthen password policies, security can be greatly improved (and actions made much more specific) by using rule based authentication and assessing the context when requests for applications and files are made. RBA is a gaining in importance and NetIQ Access Manager has the capabilities that are required to implement it.
References
- The Right level of Authentication – NetIQ FlashPoint Paper, 2016, available from www.microfocus.com
- PathWell: Password Topology Histogram Wear-Leveling, Kore Logic presentation at Bsides, Asheville, 2014. Available from www.korelogic.com/resources.html.
- Authentication Cheat Sheet, OWASP (last modified 21/04.2017), www.owasp.org/index.php/Authentication_Cheat_Sheet
- Matching Speed of Business to the Right Level of Risk, published by NetIQ, 2017. Available from www.microfocus.com
- Risk Based Authentication (Access Manager 4.3), www.netiq.com/documentation/access-manager-43/admin/data/b1dg0omz.html.
This article was first published in OHM Issue 37 (2017/2), p32-34.