Login security & passwords – yesterday, today and tomorrow
The act of “logging in” – that is, gaining access to some private area in a shared space – has been with us since the early 60s with the introduction of time-sharing computers, albeit confined in those days to very limited professional circles. However, with the use of the public internet as a communication and social medium and the growth of the web as a platform for commerce in the past twenty years, remembering login names and passwords for access to all our online resources is as commonplace as remembering the birthdays of our loved ones. While we might remember at most ten birthdays (with the rest written down in calendars and diaries), the average person has accumulated, based on an anonymized survey of its enterprise accounts by the popular password manager vendor LastPass, about 191 online accounts!
Lest this seem like an absurdly large number, consider all the professional accounts as well as numerous personal ones accumulated over one’s online lifetime, many of which are quickly set up for some online purchase or commenting at an informational web site and then forgotten or rarely visited. These days it seems that even the slightest online activity requires creating an account and signing in. Thus, it is not surprising that most people reuse the same login credentials (user name and password) across multiple sites. Security experts have long warned against this obvious vulnerability, but who can blame the average user for choosing an easy path to manage this increasing burden of remembering multiple passwords. (Some recent statistics suggests that only 22% of online users in the US use different credentials for each online account.)
Early attempts at providing guidelines for password management came from NIST – the US government’s National Institute for Standards and Technology which published its first digital identity guideline in 2003. We have since lived with those guidelines, as these have been adopted for use by the IT industry and repeatedly hammered home through popular best practices articles and usage. Some of the key points from that guideline that have been in use since then (until recently) include:
- Using obfuscation to create password complexity by substituting numbers and special characters for alphabets – such as zero for O, “1” or “!” for l, etc.;
- Avoiding well known bad choices such as “password” or “administrator” even if obscured using the technique in point 1 above;
- Having a minimum size for a password, with a minimum recommended of eight characters;
- Changing passwords periodically, typically every three months;
These guidelines, as such, were not bad. The problem with these rules lies in the fact that memorizing a lot of different passwords is very difficult and password choices therefore tend to fall into certain predictable patterns. For instance, having chosen a word or phrase that one might easily remember and crafting the necessary complexity (“entropy” is the technical term) through obfuscation using the technique in point 1 above, we tend to use it everywhere. The rationale used is that it is difficult to crack, while forgetting that once cracked, a lot of online resources are now vulnerable.
Also, patterns for creating more complexity by substituting letters or special characters for alphabets are quite predictable and if the underlying phrase is a common one such as “password”, rewriting it as “p@ssw0rd” provides only a false sense of security.
Point 4 above on password “rotation” was a particular favorite of enterprises, and corporate employees have long been frustrated by the need to think of a new memorable password every three (or so) months. The easy solution, widely employed to reduce frustration while adhering to the letter of the corporate IT policy, has been to retain a core phrase but to make very small changes to it, perhaps incrementing a number or two in an easily remembered pattern such as “….123” followed by “….234”, and so on. Again, such methods do little to improve the underlying security of information systems while providing only a veneer of safety.
In June 2017, NIST released revised guidelines for login security. (While NIST standards are only mandated for use by civilian agencies of the US government, its security specifications are widely respected and have become de facto industry standards. Thus, their impact is far wider than the narrow establishment over which NIST’s mandate holds.) These new guidelines were done openly through an RFI process with private sector inputs and comments from security experts.
The latest guidelines have overturned several long-held “rules” from the 2003 guidelines, mainly for reasons we outlined in the previous section on the shortcomings of the actual usage patterns:
- It is no longer seen as fruitful to create password complexity through character substitution, especially because these are easily broken through dictionary attacks.
- Passwords need not have minimum lengths, and the best ones are long sentences or a series of seemingly random words meaningful to the user in plain alphanumeric characters (so long as these are easily memorized). At least 64 characters is recommended. Such passwords are more resilient to brute force attacks.
- There’s no need to “rotate” passwords every so often, especially with this new recommendation for long pass phrases. In fact, the new guideline on this is that passwords only need to be changed if an attack or breach is suspected.
One topic which the new guidelines addresses is the question of retrieving or resetting forgotten passwords. The idea of using “security questions” (formally called knowledge based authentication, or KBA) such a mother’s maiden name or the street where you were born and the like are now deprecated. With the rise of social media, social engineering and many searchable databases, the answers to such questions can be found, if not easily at least with a little expenditure of time and effort. One popular suggestion is that users create their own questions (and answers to these, of course). Another is to make up fake answers, but you have to remember your untruthful responses!
Of course, nowadays, with the rise of password managers such as Lastpass, 1Password or KeePass, it is easy to generate different random strings for each account one might have which are all automatically generated/remembered for you by the software. In these cases, the only password you have to remember is the master password for opening the software, and the use of a series of meaningful (to you) words or phrases following the new guidelines provides the greatest resilience to hacking.
Another small improvement, along the same lines, is avoiding storing password hints as these actually help speed up brute force attacks, when compromised.
One reason for NIST’s new approach to passwords is that they think of it as just one factor in a multi-factor authentication protocol. It is becoming increasingly commonplace nowadays for various online portals to require that you not only show proof of possession of something only you know (your password) but also a second factor – something that you have, which, in most cases, is your mobile phone or, as in most enterprise scenarios, a token generator. Even if your password is compromised, it is presumably difficult to gain possession of your mobile phone with a special-purpose App, or to which a web site sends a SMS or an email containing a code which you must enter to gain admittance. Many services use SMS or emails as a way for users to also recover forgotten login credentials.
However, as with everything else, malefactors have found ways to subvert this “something you have” principle, which is at the heart of two-factor authentication. Some white hat malware researchers have shown how it is possible to exploit a weakness in the telephone network used to convey SMSs to intercept such messages, allowing for the complete subversion of one’s accounts. Other techniques appear to involve, among other steps, setting up call forwarding from one’s phone number to the malefactor’s where a confirmation code can be read out as a part of an accessibility feature. A more direct way is to take advantage of number portability to have ones’ mobile number ported to another carrier and account under the control of the attacker. While such methods are elaborate, the complete control that attackers achieve over online accounts makes the effort worthwhile.
To avoid using an out-of-band channel such as SMS, two-factor authentication apps such as Google Authenticator, Authy and Duo exist that allow for the generation of a one-time password (OTP) directly on the mobile phone for each website which offers such an authentication method. Some websites, especially financial sites like banks, offer clients their bespoke code generating apps. There are also hardware token generators, such as YubiKey. There are several variants here:
- The mobile authenticator app or hard token generates a time-based one-time password which the user enters as on the web site’s login page;
- The web site communicates with the authenticator service, which pushes (using a secure mobile Over-the-Air PUSH protocol) a request to your mobile for your approval. When you enter a PIN (or your fingerprint), an OTP is generated and sent via the authenticator to the web page;
- The authenticator service registers as a trusted plugin for your browser on a specific device and generates an OTP which is conveyed to the web site.
LuxSci supports the following two-factor authentication options: email token to separate email address; SMS token; Google Authenticator (time-based one-time password); Duo.com (which integrates a lot of options/methods/features).
One obvious extension is to increase the number of factors in the multi-factor authentication protocol. Thus, in addition to what you know (password) and what you have (device), the additional factor could be something that you are – some physical characteristic that is unique to individuals, such as a fingerprint or one’s face, voice, or a scan of one’s iris or palm veins. It may also be necessary to include several of these factors depending on the value of the resource being protected against unauthorized access. (This is called adaptive authentication where factors such as the type of device you are using or your IP address, etc., determine the number of factors to be used.)
Of course, the use of these additional biometric factors will have to be accompanied by corresponding improvements in recognition technologies for noisy or ill-lit environments, improved processing speeds and storage, and lower costs of sensors before such methods can become mainstream. Thus, technology will need to reach the point when the number of false positives/negatives is minimal for results obtainable in a reasonable period of time.
While one of these biometric factors may give erroneous results or be spoofed, it is quite difficult to counterfeit several all at once. Thus, a time may well come when passwords (and security questions for password resets) and will be replaced entirely by biometrics-based authentication techniques. It may even be possible to create biometric certificates to replace current personal digital certificates for authentication, secure connections, electronic signatures, etc.
Other options in the future involve the use of strong cryptographic techniques to replace passwords and the trust of passwords altogether. For example, the SQRL project in the works at Gibson Research has all the hallmarks of authentication done right so that many of the deficiencies of our current password-based ecosystem (including the ability to impersonate someone if you can steal/guess their password) are removed with an actual improvement in ease of use…. or at least ease of use comparable with a password management system.
However, it will still be some time before the age of the password ends! Until then, our best bet is to craft lengthy passwords using random (but easily memorized) words following the new NIST guidelines that will take several hundred years to break.
 A mixture of length, randomness in the word/phrase choice, use of special characters which all combine to make it difficult to crack through brute force.
 Let us see if web sites will follow and alter any current size limitations. Obviously, the password length cannot be open ended, but some reasonable length should be allowed for pass phrases.
 Thus, sites need to actively monitor for these and ensure that their users are notified when there is even the slightest suspicion of unusual activity. However, the typical industry response has been to hide breaches for long periods of time or reveal these if absolutely necessary.
 This is included under “Tomorrow”, although fingerprint readers are already quite commonplace.
- Application Specific Passwords / Login Aliases at LuxSci
- Enhancements to Application-specific Passwords
- HaveIBeenPwned? Selecting passwords that are not known to Hackers
- Security Simplified: The Base+Suffix Method for Memorable Strong Passwords
- Ultimate Control: Manage Access to Your Services with Custom Firewalls