OpenBSD Journal

Poll: Are Frequent Password Changes Actually Useful?

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)


Comments
  1. By Scott Brickey (207.250.204.185) me@sbrickey.net on www.sbrickey.com

    I hate password complexity requirements AND password change policies.

    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)

  2. By Jeff Clement (204.101.226.66) on

    Tl;Dr; I don't like passwords. I don't like two-factor auth that relies on a 3rd party. I like Yubikey + Password/PIN.

    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
    1. By Anonymous Coward (38.99.63.178) on

      > 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.
      
      The Yubikey NEO supports the OpenPGP smartcard standard. GnuPG supports such
      cards natively (without ripping your hair out dealing with OpenSC). You get
      true two-factor if you want that sort of thing (IMO you're already way ahead
      of the game with a one-factor token), and also you can use the same
      smartcard to log into multiple machines. I too refuse to rely on third-parties,
      and am too busy to run my own centralized auth system (a single point of failure).
      
      I put together a HOWTO, because all the information about setting up the
      Yubikey NEO for OpenSSH authentication was randomly strewn across the net.
      
      http://25thandclement.com/~william/YubiKey_NEO.html
      
      Being able to reliably use hardware-secured public key auth from multiple
      client machines to any of the servers I worked on was like a god-send. I'd
      been waiting 10+ years, and had accumulated a stack of smartcards which
      never worked well with open source software. Solutions using OpenSC were too
      convoluted, and difficult to reproduce on different machines (desktop,
      laptop, work computer, etc).
      
      I also have 10+ HOTP Yubikeys, but stopped using them once I setup my
      Yubikey NEO. It's soooooo nice. I can even sign my Git commits.
      

      Comments
      1. By Jeff Clement (184.70.101.146) on

        > The Yubikey NEO supports the OpenPGP smartcard standard.

        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!

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]