By Guillaume Rousse, IT Security Engineer at GIP RENATER
These days, passwords are a universal authentication method, because they are simple to configure on the server side, easy to use from any terminal, and simple to understand for the user. Nevertheless, for an attacker, they are just as easy to steal or guess…
Faced with this risk, various recommendations are called for, eventually backed up by technical measures to ensure that they are effectively implemented. However, as with all safety constraints, they must be adapted to the context, in particular their impact on usability, otherwise they risk being neglected or circumvented. This is especially the case in the Higher Education and Research community, where the argument of authority sometimes lacks effectiveness.
As such, below are several tips to limit the security risks associated with passwords, seen from the perspective of the best compromise between enhanced security and impact on usage. More than a list of off-the-shelf recommendations, it is above all a presentation of different views on a few simple measures that can help a manager build their own security policy.
Robustness
Brute force attacks consist in listing all possible passwords. The elementary countermeasure consists in increasing the size of this set, by playing on two possible parameters:
- Password lenght
- Password complexity, corresponding to the number of symbols that can be used
For a long time, the second criterion was predominant, probably in order to minimise the number of characters a user needed to enter. The rules relating to this approach therefore require that various character types are used (lower case, upper case, numbers, punctuation marks), for a minimum length of around ten characters. As such, in 2012 the ANSSI recommended a minimum length of 12 characters, for 3 character types, which would have to be updated to take account of the evolution of the growth of computing power.
However, there is no longer a consensus on this approach today. The NIST, in its latest recommendation of 2017, allowed the use of long passwords without an associated composition rule:
Allow at least 64 characters in length to support the use of passphrases. Encourage users to make memorised secrets as lengthy as they want, using any characters they like (including spaces), thus aiding memorisation.
Do not impose other composition rules (e.g. mixtures of different character types) on memorised secrets.
This change is not due to a sudden infiltration by “hippies”, but to a simple pragmatic observation that is regularly repeated during massive leaks of compromised user accounts: humans have a limited ability to memorise complex secrets, so they tend to choose passwords that are easy to guess. This is perfectly depicted in an image by XKCD [also referenced in the article by CSC Head of Security Urpo Kaila “Keep your secrets!“]
The two approaches coexist today, and it is objectively difficult to say which of the two is the best in terms of security. The context of use is therefore probably a more objective to choose, given, for example, that mobile terminals do not lend themselves well to typing in long passwords. And in any case the robustness of a password only protects against brute force attacks, not against other types of attacks, such as password interception on the network, password extortion by deception (phishing), or even by other less subtle means, as illustrated once again by XKCD.
Regular Renewal
Renewing passwords on a regular basis has long been considered essential for any IT Security Policy worthy of this name. The above-mentioned guide by the ANSSI recommends renewing passwords every 90 days for systems containing sensitive data.
Here again, the consensus is shifting, and the NIST, which perhaps was hacked at some point, has suggested to abandon this practice, and to renew the password only in the event of alleged compromission:
Do not require memorised secrets to be changed arbitrarily (e.g., periodically) unless there is a user request or evidence of authenticator compromise.
Once again, it is difficult to form an objective opinion on the enhancement of security. However, in view of the technical difficulties in implementing this measure in a heterogeneous information system, without control of the workstation, and the organisational difficulties in getting it accepted by users, who often outdo each other in ingeniously circumventing it, it is easy to see that the cost/benefit ratio is relatively low.
Only use one
As certainties crumble away, it is reassuring to see that there is still consensus on advice, including the tip to avoid reusing the same password in different contexts. Here, the notion of context means that of a trust boundary: it would seem unnecessary to prohibit reusing the same password between two professional applications, whereas the whole issue of centralised authentication precisely involves using the same user account everywhere, but between applications implemented by different third parties. To put it simply, it is generally easier to cross the boundary between the professional and personal spheres, as for example the ANSSI guide does (translation):
Using the same password for both your professional and personal email should be avoided at all costs.
Unfortunately, this is essentially a recommendation, which is very difficult to verify operationally. You can of course check the presence of a password in a dictionary of commonly used passwords or those known to be compromised, at the time it is created or renewed. Or even to launch regular dictionary attacks on your own accounts, but this usually requires a specific technical organisation and management supervision. The best strategy is therefore to facilitate take-up of this recommendation by users, typically using applications dedicated to password storage, integrated into the most common applications (essentially the web browser). Here we highlight KeePass and its derivatives, such as KeePassXC, which is simpler to install on Linux.
Limitation of use
Finally, the most radical way to limit the risk is to eliminate it whenever possible. In the case of passwords, a typical example is SSH connections on Unix servers, or Windows servers since version 2019. It is commonplace to use key-based authentication, rather than a password-based one, through an external mechanism (LDAP directory, configuration management, manual deployment by a third party, etc.) to set up the corresponding public keys. Moreover, by using an SSH agent (SSH agent under Unix, pageant with Putty, etc.) users will gain an SSO mechanism, i.e. they will benefit from a gain in ergonomics, which is rarely the case when enhancing security. Finally, by blocking password authentication (PasswordAuthentication no in the SSHD configuration), the risk of brute-force authentication disappears, and with it the need to deploy complex solutions for log inspection and dynamic modification of network access control.
Conclusion
The evolution of technologies, on one hand, and usage, on the other, result in a joint evolution of attack methods. The shifts in the discourse of security experts only reflect the willingness to adapt to these evolutions, particularly in light of the experience of recurring security incidents, while maintaining the same ultimate objective: to reduce the risk to an acceptable level. And for those who are concerned about NIST becoming a cosy refuge, rest assured that the loosening in recommendations affecting users actually means a transfer of constraints to the service providers, who are more capable of implementing more complex and more effective measures. Such as, for example, the verification of the password chosen by a user in blacklists compiled from databases of compromised accounts that regularly leak onto the Internet.
Read more on the GÉANT Cyber Security Month 2020: https://connect.geant.org/csm2020
