Start talking with users about security and pretty quickly you end up on the topic of passwords.
Passwords are probably the security measure that everyone runs into on a daily basis. We have passwords for our IT systems at work, we have passwords for the services we use at home, we have passwords for the devices we use. There are passwords everywhere!
However, the conversation we've had with people all around the public sector hasn't been a happy one when it comes to passwords. When every system needs a different password, the complexity settings for each system are set high, and password changes are enforced frequently, the outcome is not better security. Through research, in collaboration with the Research Institute in the Science of Cyber Security, we've learnt about how trying to make passwords "more secure" means systems end up less secure. When we're overloaded with passwords, we all end up "breaking the rules": we use the same passwords across different systems; we use coping strategies to make passwords more memorable (and thus more easily guessed), and we store passwords insecurely. Jokes about passwords on sticky notes underneath keyboards aren't jokes.
When we overload users with passwords, we also add cost. There's the cost of dealing with increased password resets and account lockouts, and by putting up barriers in the name of security, we reduce the functionality of systems, and make it harder for people to do their jobs.
Worst of all, making all password policies "complex" doesn't stop attacks; see Microsoft's research paper on this subject. Attackers who have stolen a password database - even if hashed and salted - can generally brute force the majority of the passwords in a reasonable length of time, unless the passwords are so long as to be impossible to remember. Attackers who only get a few tries at guessing passwords (such as with a well-designed online service, or enterprise IT network with throttling and lockout) will be stopped by a fairly short password. The vast majority of password policies are in the middle of this - they give us passwords that are far too short to prevent brute force attacks, but that are much more complicated than they need to be to prevent others. The result is that we're asking users to put in more work remembering complicated passwords, for no actual extra security benefit.
Today we've published our new guidance on passwords. Unlike previous guidance, this doesn't focus on trying to get ever more entropy into passwords. Instead we're encouraging system designers and security architects to think more about where they're requiring passwords, and what they're trying to achieve with them. We also recommend simple approaches to improve security, whilst improving the usability of systems. In a future blog we'll describe how you might implement some of these concepts in different scenarios - such as on End User Devices.
As ever, we're always grateful for feedback on our guidance. Please email enquiries@cesg.gsi.gov.uk or leave a comment on this blog post with your thoughts.
13 comments
Comment by Simon posted on
I always suggest splitting web passwords into two chunks. The first part you make a complex string that can be remembered, the second part is generated by random keyboard bashing and can be stored in clear text on your computer.
The end result is that if anyone compromises one web service, the password cannot be reused for other services as all your passwords are unique. And if anyone gets hold of your clear text password file, they are useless without the one complex string you have remembered, and never written down.
One password to remember. No password manager required.
e.g.
I remember a complex password like this, which is never written down: y727H;st)
For website A, I create this random junk and copy into a text file: 8u89UI9i0)J()Y&tg
For website B, I create this random junk and copy into a text file: 0ol[p0-KjLiou8*uy*
For website C, I create this random junk and copy into a text file: 4599(FGRz|6iogR
When I want to log on to one of these websites first I manually type my remembered complex string, then the remainder of the password can be copy\pasted from my plain text file.
So my true password for system A is:
y727H;st)8u89UI9i0)J()Y&tg
So you get the benefits of a password manager with the ease of use of a text file.
Comment by Jon L posted on
Hi Simon. This is a great example of why we need to recognise that expecting people to remember (without writing down or storing!) really complex passwords doesn't work as a rule. If you were trying to remember each of these passwords without a coping strategy such as the one you've described then it'd be pretty tough, if not impossible! When we're designing our systems, and giving our users advice and guidance on passwords, we have to remember this.
Many thanks for commenting,
Jon.
Comment by hunternet7 posted on
Penguin
Comment by Pete posted on
> I remember a complex password like this, which is never written down: y727H;st)
Most users are incapable of doing this, which is why they resort to 'Password1' or '123456' in the first place. This strategy might work for you, but for most users the advice to use some form of password management software is more pragmatic.
Well done to CESG for producing this paper, it has a lot of good advice. Now the work of overturning 20 years worth of bad recommendations can begin in earnest!
Comment by Alec Muffett posted on
Hi Jon,
Regards this:
* Account lockout and ‘throttling’ are effective methods of defending brute-force attacks.
* Allow users around 10 login attempts before locking out accounts.
- so if a malicious individual can determine the usernames of all the systems administators (or, other/all legitimate users) then he/she can lock them all out of the machine (or possibly service, if single-sign-on is deployed) by trying to log in as them repeatedly with intentionally bad passwords, and then can DoS or otherwise hack the machine, the administrators and users of which will not be able to get back into it to address the ongoing attack?
Also, there's the perennial problem of network services such as IMAP; if a password guesser is attached to use an IMAP service as a password oracle, then 10 bad logins on IMAP should invalidate Web and interactive logins; but then 10 "legitimate" bad logins are a common occurrence on IMAP when someone changes their password and yet fails to update their mail client...
In my experience, account lockout does much more harm than good.
Comment by Jon L posted on
Hi Alec. These are some excellent points and ones which we spent a lot of time discussing when we were drafting this guidance.
I absolutely agree that if you set up your system such that an attacker can use automated account lockouts to deny a substantial number (or all!) of the users access, then that's not a good design. At the same time, a system which doesn't have mechanisms in-place to spot potential password guessing as it is happening is also problematic. Account lockout is one approach which can be used, but it's not the only one - the options vary depending on the technology stack in use. Throttling login attempts temporarily, blocking IPs, raising alerts to a monitoring solution, etc., can all also play a role in spotting potential attacks and reducing their impact.
The important thing to me is that system designers think about the impact of password policies (including automated lockout if used), both in terms of the risks these technical controls mitigate, but also any wider system or user implications there might be from introducing them.
Thanks again for your comments,
Jon.
Comment by Robin Melville posted on
Firstly... At last!!! Finally, some sense on the password issue. Routine password changes (required by virtually everyone) are a nightmare. As are unduly complex requirements and not allowing autocomplete (although there might be some additional risks with that).
Modern GPU-intensive cracking techniques can iterate through a database of hashed and salted passwords in a usefully short time (given that vulnerability begins with p0). The only thing I'd add to the guidance is that, as the Microsoft paper highlights, the crucial time period is how quickly system managers become aware that the password files have been compromised and issue a generalised reset.
Many systems don't have the kind of tripwires in place to detect this. Although intrusion protection is commonplace to varying degrees, intrusion detection is less well developed -- especially active detection (as opposed to checking file signatures passively). There needs to be more work on this.
Comment by Steven Murdoch posted on
Thanks for publishing this report. Of course there are more advanced security measures than are described in this document (e.g. machine-learning based anomaly detection, risk-based authentication, and transaction authentication) but in terms of what companies should do right now through the configuration of off-the-shelf authentication products, I think this guidance is a great start.
Comment by Roger Pearse posted on
This is a really valuable return to sanity. "Security" policies that don't engage with what people are really doing - and must do, in order to do their jobs - are simply pointless bureaucracy. I think everybody knows that the current password regime is broken; the problem is the way forward. This is a good attempt to start addressing a very real problem.
Comment by Liz Holmes posted on
This is a good document with some very useful guidance which makes sense however there are a couple of points I would be grateful of some clarity. In particular only changing passwords if they are suspected to have or have been compromised and locking out after 10 incorrect attempts. Whilst this would help improve user experience and reduce burden on ICT support, how does this approach meet with security penetration tests which look at password policy and password aging? How does this approach meet with PSN compliance regimes and how has this been interpreted by the security companies that carry out such penetration tests?
Many thanks
Comment by Jon L posted on
Hi Liz,
Apologies for the delay in responding to you - I wanted to check a point in my response.
Via our colleagues here who handle our relationship with penetration testing companies, for schemes like CESG's CHECK scheme (ITHC), we are raising awareness of this new guidance amongst penetration testers. We have already had some good feedback from some of the security companies involved in this work, so I'm optimistic that this won't be too problematic.
I've discussed this guidance with members of the PSN team at Cabinet Office and they've reassured me that a sensible password policy - such as one you might derive from this guidance - won't cause problems in terms of their compliance regime.
Many thanks,
Jon.
Comment by Adrian Owen posted on
You need a product to fix this: https://youtu.be/GRHUzKtwV6M
1. Make extremely long passwords
2. Remove your support staff from Domain Administrators
3. Grant them audited controlled 'Elevated' privilege to Windows Domain RDP
4. Grant them audited password free access to workgroup/Unix etc.
Many thanks
Comment by Toby posted on
Why not introduce a biometrics system for all users everywhere