Password Policy

Has anyone implemented Password Policy in E10?

Do you have an some generic log ins that you don’t want the policy to apply too? If yes, Did you create a BPM or code for the policy not to apply to those log ins?

We do, but that will change when we get to 10.2.300 and Single-Sign on… We set length(8)/complexity options and 90 day expirations, 3 attempts and locked out for 10 min - all pretty basic. We learned that it doesn’t take effect UNTIL you expire a user’s password (don’t use the Action Menu - Expire All Passwords). So for the group of generic/admin users we don’t want the password to expire - we just have NOT expired their passwords yet. We change them manually. Been working just fine.

Thanks Mike. I was reviewing more and missed the expired password setting on the user file.

Glad to help!

BTW, the guy at NIST who came up with the idea of expiring passwords without reason (number of days for example) said it was the worst idea he ever had. It makes users post passwords on their screen, etc.

Nice write-up on password policies…

Mark W.

1 Like

Very true, but when the man says ‘make them expire’, we say ‘Ok’ and make everyone else’s passwords expire - but not the admin ones. Those are our ‘precious’, and are super secret :slight_smile:

1 Like

You need to educate “the man”! He’s going against NIST recommended practices! :laughing:

I did not see any commentary on if this instance is exposed externally or not so I’ll trend to the conservative side on this with a couple of items…

First, you may want to setup some monitoring on the SysLog table where login failures are captured. If someone externally starts pummeling the server trying to hack in, that table will get filled pretty quickly. It’s a good table to stick whatever monitoring tools you use on to get an alert that 100, a 1000, a million records just appeared in the table with someone trying to brute force attack the site.

Second, take a look at the incremental policy. That was added to prevent brute force attacks with minimal user interference. The understanding is a bit mixed but I’ll try to explain. Each logon failure will lock out the user for an increasing amount of time.
1 failure - 1 second lockout
2 failures - 2 seconds
3 failure - 4 seconds
4 failures - 8 seconds
5 - 16 secs
6 - 32 secs
etc…

Not too bad of a user experience but for a computer program trying to brute force a server attack, good luck. It’s going to get pretty frustrated pretty quickly.

3 Likes