 |
 |
Password idiocy
[reply]
|
10/26/06 08:42 AM EST
posted by JER email web |
|
When Doceus made me change my password every 30 days, I was annoyed and starting using month names. That lasted about 3 months until Harry used a password cracker and told me that "november" was not an appropriately complex password. I changed it to november01 and was not hassled again.
In the years since, I've been fighting a losing battle against stringent password policies. I've come across policies that make me long for the simple Doceus rule of "just don't use a dictionary word."
DOD has just mandated that all admin account passwords must be at least FIFTEEN characters. This is on top of the use at least 2 numbers, 2 special characters, 2 caps and 2 lowercase rule (and the can't be one of your previous 30 passwords rule). Homeland Security goes even farther by saying that you MUST start and end with a letter (why??) and that no two characters can be repeated consecutively. Also, they limit you to an 8-16 character range (again, why only 16??).
The most brilliant password policy ever is documented here:
http://support.microsoft.com/kb/276304/en-us/
Now you might be asking yourself WHY I'm such an anti-stringency advocate... Aren't secure passwords a good thing? Of course they are -- I think using "november" was pretty naive of me. But the new wave of "secure" password policies has brought us to a point where most users have no choice but to write down their password somewhere. When your password changes every 30 days and follows 80 different rules, it's nearly impossible for many people to remember.
Furthermore, while it's nice that the password can include numbers, special characters and uppercase, forcing it to contain a specific number of them, limiting the start & end characters or specifying consecutive character rules REDUCES security. The number of permutations required to crack the DHS password is actually fewer if you know that it must start with a certain character or that "a" can never follow "a."
What silly password policy are you following? |
|
|
|
| I agree... Can't say much else. We have a complex password rule as well, but fairly easy to follow and standard. And it changes every 60 days, so not too bad. |
|
|
|
I heard that Bloceus is a bit more lenient now.
I go crazy when websites restrict passwords to just letters and numbers and don't allow special characters. What kind of monkey technology wouldn't allow the use of special characters?
Oddly I am using a Jerry Negrelli scheme currently for my work passwords, and it's been working out great. I won't say which one though, or I'd have to find something new.
Try this for your next password:
ThisFreakin'PasswordPolicyBlows10Monkeys!
And then change the number each month... |
|
[reply]
|
10/26/06 07:33 PM EST
posted by Doug1 web |
|
Alex, so does the policy change every 60 days or your password? :-)
So when you code web apps, you like have to store password history for users? Or is this all handled by LDAP/Active Directory integration?
As long as the password != '', it's fine with me! I'm actually writing up a module or CFC to handle multiple levels of password checking as well.
15 character-long passwords is absurd. I hope there is not a 3-strikes and you're locked out rule with that.
|
|
|
|
Yep, 3 strikes and you're locked out for 15 minutes. I'm thinking my new password will be Dum8+R3quir3m3nt!
Now that you know my password, all you have to do to abuse it is can sneak onto the post, obtain my CAC card and PIN, locate this building, gain physical access to the server room, guess our server's location in the server room and guess the root admin account name. It's almost TOO easy... |
|
|
|
The stuff we developed here that all systems use actually works pretty well. You can turn all of the features on or off in the config file. This includes things like the need for "complex" passwords, defined by 3 of 4, numbers, letters, mixed case, special characters, the need for automatically expiring passwords set in number of days, the max failures before lockout, unique password history (stored in DB but is one way encrypted) etc. I am working on the lock for 20 minutes thing right now. As is, if a user is locked and they attempt to login with a correct u/p, they get a screen telling them they are locked and can request an unlock. The admin receives a note, goes to the user's screen, unlocks the account and generates an unlocked account email notification with a new temporary password or auth link that must be followed within 2 hours, and then they must change their password at first login. Again, all of this stuff is configurable, such as the template of the email that is sent (you can add to it or change it though), the need for a reset after first login, etc.
I think we have a 6 strikes and your out. The best is that we track failed logins and the reason for the failure. So when a users says "I never got the email and it is just locked" we can say, "Um, no, you tried to log in 35 times with the wrong password."
And yes, both password and policy tend to change every 60 days. |
|
[reply]
|
10/27/06 01:36 PM EST
posted by Doug1 web |
|
Thanks Alex, now I've got my specs for a login system!
I've always logged an "Access log" as well. I used to log what the user actually typed. It was useful for finguring out why they are getting it wrong (when I had to take calls/emails on it for that app). But I stopped that since it's also easier to get people's passwords and possibly other ones they use as they try all of their "other" passwords trying to get something to work... Damn security.
If you one-way encrypt the passwords and store that, the password retreival part sucks. I hate sites that send me a temp password even though I know it probably means it's because they don't store my actual password. Again, damn security.
|
|
Note: Only registered ShinyDonkey.com users
can post images. Only administrators can delete images.
|
|
|