Contributed by pitrh on from the You make me go -.!kz&Y_a! dept.
Book of PF author and Undeadly editor Peter Hansteen asks the following question:
Does enforced password change at set intervals actually enhance security?
Given the increasing sophistication of password cracking techniques, and potentially insecure methods for two-factor authentication, what can administrators do to strike the balance between utility and security?
(Comments are closed)
By Scott Brickey (207.250.204.185) me@sbrickey.net on www.sbrickey.com
I'd implemented a much more effective answer almost 15 years ago:
- passwords have to be at least 5 or 6 chars long (I don't recall how picky I was back when I'd set it up).
- password lockout after (around) 10 attempts per minute.
I *may* have had them change the password once or twice per year, just to cycle it around in case it WAS shared... but certainly nothing obnoxious. (again, I don't recall offhand... this was after all 15 years ago)
But that's it.
Few PEOPLE will actually type their password wrong 10 times in a row, at a rate of 1 attempt every 6 seconds. After the second or third time, too much thought goes into it, and people slow down. As a result, PEOPLE rarely trigger the lockout password.
COMPUTERS on the other hand, will submit 10 attempts in 1 second, and will trigger the lockout almost immediately. EVEN if they KNOW the policy, and limit their attempts... it'd take them years before they guess correctly (obviously guessing is just that, so it's POSSIBLE for some dipshit to have the password 'aaaaaa', which might be the first attempted password... but from a big-O perspective, it's impractical).
The policy worked great.
It did occasionally trigger lockouts on common accounts (Admin, root)... we dealt with them specifically (rename accounts, block perimeter login, etc)... but no one ever complained about it... and certainly wouldn't in light of TODAY'S requirements.
(I've also written about this : http://www.sbrickey.com/Tech/Blog/Post/Password_Account_Lockout_policies)
By Jeff Clement (204.101.226.66) on
My suspicions (not backed by numbers) are that, for normal users, requiring frequent password changes and requiring various password attributes (length, characters, etc) is actually detrimental to the security of a system.
I think that forcing users to routinely generate new secure passwords (which are hard to generate and hard to remember) seems likely to encourage users to pick bad passwords that are easily memorize-able and that only just pass these minimum password sanity checks rather than spend the time coming up with something decent. I have a single anecdotal case of me to back that up. :)
Two-factor systems like Google Auth & Duo Security are nice and certainly raise the bar but for anything important I'm uncomfortable with the secret being stored on my phone where it's, potentially, accessible by Apple/Google and other apps on the device. I'm also uncomfortable with how easy it is for anyone who acquires these secrets (which doesn't seem a huge hurdle) to then make an identical functioning two-factor token.
My current favorite solution is the Yubikey because it's a physical token and can't easily be copied (assuming you protect the secrets when programming the device). Normally, Yubikey tokens are verified against a central server and machines authenticating a user would trust that central server to handle the authentication. I don't like this because I don't want a 3rd party in my authentication loop for stuff I really care about. Fortunately, OpenBSD's login_yubikey.c is standalone and authenticates the Yubikey without relying on a 3rd party service/server. This means that you do need to use a separate Yubikey for each user and system you log into (a central server is needed when using the same Yubikey token on multiple machines to prevent replay attacks).
My only complaint with the current login_yubikey.c implementation is that it's currently one-factor authentication. When you choose to use login_yubikey for authentication it becomes authoritative. Losing a Yubikey means that whomever finds that Yubikey can potentially compromise any accounts associated with that Yubikey.
I have the following patch which adds an additional (optional) PIN to login_yubikey which turns it into true two-factor authentication.
http://marc.info/?l=openbsd-tech&m=139932262131349&w=2
Rather than enforcing passwords changes I would lean toward a two-factor device like a Yubikey combined with a short memorable password/PIN. It's easy for the users and is more resilient to poorly selected user passwords, keystroke loggers, etc.
Comments
By Anonymous Coward (38.99.63.178) on
Comments
By Jeff Clement (184.70.101.146) on
Agreed. I like smartcards in theory and I like where the NEO is going. The thing that keeps me using the HOTP Yubikey is that they just work on EVERYTHING (Windows, Mac, *nix and even my iPad) without additional software or drivers. They even work through multiple SSH hops if I need it to.
Thanks for the tutorial though! I'll take another stab and getting my Neo to do some useful work for me!