On this page.... RSS 2.0 | Atom 1.0 | CDF
# Monday, 19 June 2006

Is anyone else as frustrated as I am with the multifarious password policies you run into across systems?  It seems like everyone and his brother has "the best" idea of what a strong password should be, which translates into having to keep up with N passwords and which systems they map to. 

That's bad enough, but then you have these people who think that making you change your password every N days is a good idea and that you can't use the last N passwords you've already used.  To make it worse, some brilliant minds out there think that forcing us to have "strong" usernames is a good idea too, so you end up with something like N^N permutations of usernames and passwords that you have to track. 

"So what?" you say.  "We've got a nifty 'Forgot Password' option on our site/app/etc.." 

But I have to ask, is that really ideal?  Perhaps if we didn't have to keep track of N^N passwords mapped in matrices to the N! systems we use, we wouldn't forget them so often! 

I'm not saying that having strong passwords is a bad idea, not at all.  I'm suggesting that we all work toward agreeing on what a strong password is and come up with, dare I suggest, standards based on data sensitivity.  So for instance, here are some ideas:

  1. If all you've got for a particular system is generic profile data, that would require a very low strength password, say minimum six characters, no special chars or numbers required. 
  2. Then you might have a next level for systems that keep your order history (but no financial data per se).  These kinds of systems might require eight characters with at least one number.
  3. You might then have systems that store financial data, such as credit cards, but are still a commerce system; these could require eight characters with at least one number and one special character.
  4. Then there are the actual banking, trading, etc. systems, and these might require ten characters with at least one number and special character.
  5. For systems above this level (e.g., company VPN), you would want to have some kind of dual authentication with a strong password and RSA tag, smart card, bio, etc.

Anyways, the point is not necessarily that these are the best specific guidelines; I don't consider myself a security expert, but I know enough to understand that what we have going on is not likely adding to our general security because in order to keep track of all these authentication tokens, we have to write them down somewhere, store them in some vault, file, sticky pad, etc., which in the end likely makes our security less, and it certainly adds to both individual and organizational administration overhead to manage password resets, fetches, etc.

If we had standards like I'm suggesting that were well published, then every Joe that goes to write a new system would easily be able to put in place a policy that is both secure, appropriate for the data being protected, and manageable for everyone involved.  If we only had maybe four passwords to remember, even if they're odd and funky (with special characters and numbers) or if they were pass phrases, we would have to write them down or forget them or manage getting them reset all the time.  In other words, we'd be more secure and happier.  And if we do have such standards, they need to be far more publicized and talked about when the subject comes up because I've not heard of them, and I don't think I live in the proverbial cave.

Monday, 19 June 2006 13:53:29 (Eastern Daylight Time, UTC-04:00)  #    Disclaimer  |  Comments [1]  | 
Monday, 19 June 2006 19:49:33 (Eastern Daylight Time, UTC-04:00)
Yes, passwords are a pain. But Keith Brown (from PluralSight) has a great open source tool that helps you store and create all those passwords safely, called Password Minder: http://www.pluralsight.com/tools.aspx
Comments are closed.

Disclaimer
The opinions expressed herein are solely my own personal opinions, founded or unfounded, rational or not, and you can quote me on that.

Thanks to the good folks at dasBlog!

Copyright © 2017 J. Ambrose Little