Hello all. Happy New Year.
I have a requirement to enforce password policies on AD (a tacacs and windows domain). I don't have a great deal of Windows AD knowledge - so a newbie 
this is a little off topic, but I thought I'd ask...
Specifically, I need to enforce the use of length, special characters, and be able to validate the enforcement of such.
Looking at Nfront, Quest, etc..., and wanted to see if anyone out there had thoughts?
Thank you.
You would set those in users section of AD.
AD can be very quirky when it wants to.
Robert
I have a requirement to enforce password policies on AD (a tacacs and
windows domain). I don't have a great deal of Windows AD knowledge - so a
newbiethis is a little off topic, but I thought I'd ask...
This is very basic built-in functionality of AD, that those maintaining an
AD implementation really ought to already be aware of; to implement it,
you edit or create applicable group policy to apply a Password policy in
the security section of the applicable group policy for the Computer
account configuration at the domain level, specify the minimum length and,
either check the "password must meet complexity requirements box", or
supply a custom filter --
My recommendation would be to not go too far with password policies.
Implement only the least restrictive requirements in AD to achieve the
best security benefits per unit of user annoyance; e.g. a minimum length
of 8 is a good choice; if you try and force users to pick a minimum of 15,
with complexity, and expire their password every 10 days, you'll actually
get users with simple passwords (or password sticky notes on the monitor).
The sole root cause for "easily guessable passwords" is not lack of
technical restrictions. It's also: lazy or limited memory humans who need
passwords that they can remember.
Firstname1234! is very easy to guess, and meets complexity and usual
length requirements.
There are password filters on the market that can perform a simple
dictionary check, which is a better check to perform than number of
character classes. Use the custom password filter and a 30 minute
account lockout after the 3th failed login attempt, to prevent most
password guessing attacks. An event log monitoring tool should be
used to alert a sysadmin.
Specifically, I need to enforce the use of length, special characters, and
be able to validate the enforcement of such.
You can ensure the enforcement by putting the password policy into effect;
make sure it is enforced on all domain controllers. And then at a later
date check the "must change password at next login" checkbox for all users
you need to enforce against, and utilize the GPResult command for each user
to ensure that the policy is applied.
The last password change date will verify the user has updated their
password at the time the policy was in effect
Another thing to consider is to have user passwords expiring once every 365
days, with checks to prevent reuse of previously used passwords; then
typical scripts to monitor applied policy and last password change times
can be utilized to verify compliance.
I would very much agree with this as far as the "user annoyance" side. We have had customers enforce 12 characters and complexity for all users, and you end up with sticky notes under the keyboard or other objects on the desk. I would also make sure to set a reasonable timeout to force a workstation locking as well. However I would say 365 day expiration is a little long, 3 months is about the average in a non financial oriented network.
Depending on your AD structure, you can easily enforce different policies for different types of users. Meaning you can give your average minion a 8 character password with 90 day expiration, 4 password history and 3 of 4 groups for characters. Then you can give your domain admin accounts (your normal support staff doesn't have domain admin on their day to day accounts do they??) a more restrictive policy like 12+ characters, 30 day expiration 24 history and full complexity (via third party modules).
-- Blake
....
The sole root cause for "easily guessable passwords" is not lack of
technical restrictions. It's also: lazy or limited memory humans who need
passwords that they can remember.Firstname1234! is very easy to guess, and meets complexity and usual
length requirements.
Obligatory xkcd reference: xkcd: Password Strength
Gary
I always like to look at policies like this from an analytical point of view.
Let's take a look at some numbers. Let's say that you insist on mixed
case, numbers, punctuation, 8 characters. I find anything more than 8
characters really difficult to remember; probably lots of other people too,
which is why they all write them down on post-it notes if they're longer -
and then stick them to their monitors.
This creates a pool of 26 + 26 + 10 + 10 = 72 possible characters. So in
theory you're talking about a pool of 72^8 = 7.2*10^15 possibly passwords.
Thing is, your password policy insists on punctuation, which means that
your actual password pool is now 10*72^7. i.e. one character is pulled
from the pool of 10 punctuation chars, and the rest are anything at all.
And if you insist on at least one number + one item of punctuation, it's
10*10*72^6 - same reasoning.
But really, you're also insisting that you use at least one upper case +
one lower case letter, which means that your password pool becomes
10(punctuation)*10(number)*26(upper case)*26(lower case)*72^4 = 1.8*10^13.
In other words, by enforcing a strict password policy on your users,
you've just reduced your potential password pool size by a factor of 400,
which means that your password is 400 times easier to brute-force.
The next step in this process is to take a look around at the current
capabilities of GPU based hash generators. E.g. whitepixel currently
claims to be able to handle 3.3*10^11 md5 hashes per second (unsalted) on a
computer with a very small capital outlay. If for some odd reason you were
storing your passwords as unsalted md5 hashes, your entire password set
would be cracked within about 1 minute.
But real life is different; we don't use md5, we do use salt, and we don't
choose stupid password policies. Oh but wait, we do.
So the real question you need to ask yourself is this: "what is the
intention of my password policy?" Is it to create a sequence of characters
which is effectively impossible to brute-force? Or is it to create a
sequence of hieroglyphics which your users will find difficult to remember
and will cause them to grind their teeth in anger every time they are
forced to type it in? At best, these hieroglyphics provide an elevated
sense of security. At worst, they are a mockery of actual security.
My favourite choice is "Pa$$w0rd". It scores top marks on pretty much all
password strength checkers that I've ever tried it on. And every time the
policy requires a change, I prepend a digit which apparently makes it
secure for another 6 months.
If you are more interested in creating passwords which are difficult to
brute force and easier to remember, one useful approach is to take a list
of a couple of thousand short-ish words, and to use a random list of five
or six of these words for a password. Much easier for people to remember;
gets around silly mistakes with typos; and there's no requirement for mixed
case, punctuation and all those other silly things which look great on
paper but serve only to confuse and annoy.
Nick
Thanks; you saved me the trouble.
There's a discussion of the topic going on right now on a cryptography mailing
list; check out http://lists.randombit.net/mailman/listinfo/cryptography if you want.
Also see my (mostly tongue in cheek) blog post at https://www.cs.columbia.edu/~smb/blog/2011-12/2011-12-27.html
and the very serious followup at https://www.cs.columbia.edu/~smb/blog/2011-12/2011-12-28.html
I should add that except for targeted attacks, strong passwords are greatly
overrated; neither phishing attacks nor keystroke loggers care how good your
password is.
I just went through some calculations for a (government) site that has the
following rules:
Minimum Length : 8
Maximum Length : 12
Maximum Repeated Characters : 2
Minimum Alphabetic Characters Required : 1
Minimum Numeric Characters Required : 1
Starts with a Numeric Character
No User Name
No past passwords
At least one character must be ~!@#$%^&*()-_+\verb!+={}[]\|;:/?.,<>"'`!
Under the plausible assumption that very many people will start with a string
of digits, continue with a string of lower-case letters to reach seven characters,
and then add a period, there are only ~5,000,000,000 choices. That's not many at
all -- but the rules look just fine...
--Steve Bellovin, https://www.cs.columbia.edu/~smb
I just went through some calculations for a (government) site that has the
following rules:
[...]
Under the plausible assumption that very many people will start with a string
of digits, continue with a string of lower-case letters to reach seven characters,
and then add a period, there are only ~5,000,000,000 choices. That's not many at
all -- but the rules look just fine...
1234;lkj rolls off the fingers quite nicely, don't you think?
OK -- let's let the set of punctuation be .,; and allow seven choices for where
it goes. That increases the work factor by 21 -- still not that large a space
for someone with a good botnet.
The real question is what you're trying to protect. If the attacker's goal is
to get *some* password, then I think he or she will get succeed, because
I think that very many people will follow my assumed pattern -- enough that
the attacker has a good chance of winning. Sure, some people will pick stronger
ones -- but that isn't the point of the exercise. Passwords and password rules
are the *enemy* to most people.
--Steve Bellovin, https://www.cs.columbia.edu/~smb
Should an attacker get to the point of being able to mount a brute force
attack, with only character class and length requirements, that means they
have basically already won the battle for basic user level access ---
user passwords do not have cryptographic strength,
he chance that some passwords are guessed is so high, that you can
legitimately treat the probability that no passwords are discovered by an
informed attack is a 0% chance.
Assuming you have a policy of account lockout after multiple attempts; the
fact they a brute force attack can be mounted, indicates implementation of
your account lockout policy failed, or the attacker stole the password
hashes.
If you have LANMAN hashes enabled or your passwords hashed with MD5
instead of PBKDF2 with 10000 or more rounds; the attacker has the keys to
the kingdom, they are almost certain to guess some passwords very quickly.
Not all passwords are equally likely to be chosen by a human given the
task of setting their password.
How some luser is going to respond to password complexity: pick a name or
standard dictionary word, make the first letter capital, append a single
digit or some well known number (such as the current year, a birthdate,
anniversary, address, SSN, or other known quantity), add a period or !
to the end, to meet the punctuation mark requirement.
Eminently guessable by methods other than brute force. It doesn't matter
that 10 different punctuation marks are actually available to the user
--- human chosen passwords have low entropy, you can anticipate the
average human has higher chance of picking certain punctuation marks than
others, based on where they are located on the keyboard,
and the user's level of familiarity with the punctuation mark.
~ and _ may be valid choices; but the average english speaker is more
familiar with
! . , ' ; & + -
However I would say 365 day expiration is a little long, 3 months is about the average in a non financial oriented network.
If you force me to change a password every three months, I'm going
to start doing "g0ddw/\ssPOrd-01", ..-02, etc immediately. Net result,
you lose.
Let's face it, either the bad guys have LANMAN hashes/unsalted MD5 etc,
and we're all doomed, or they will be lucky and guess. None of these
attack modes will be mitigated by the 3-month scheme; success/fail as
seen by the bad guys will be a lot quicker than three months. If they
do not get lucky with john or rainbow tables, they'll move on.
(Some scenarios still are affected by this, of course, but there is a
lot to be done to stop bad things from happening like not getting your
hashes stolen etc. On-line repeated login failures aren't going to work
because you'll detect that, right? )
Either way, expiring often is the first and most effective step at making
the lusers hate you and will only bring the Post-It(tm) makers happy.
If your password crypto is NSA KW-26 or similar, OTOH, just
don the Navy blues and start swapping punchcards at 0000 ZULU.
(File:Kw-26.jpg - Wikipedia)
A side issue is the people who use the same password at fuzzykittens.com as they do at bankofamerica.com. Of course fuzzykittens doesn't need high security for their password management and storage. After all, what's worth stealing at fuzzykittens? All those passwords. I use and recommend and use a popular password manager, so I can have unique strong passwords without making a religion out of it.
Greg
works well. has plausible analysis of the entropy of the passphrases
created. it's 100% prescriptive and deterministic so can be used for
large, unevenly skilled userbases. the passphrases are easy to
remember and type for english speakers (and there are alternative
dictionaries).
and it wouldn't pass any of these silly requirements.
what people really need to be doing is deploying:
http://en.wikipedia.org/wiki/HOTP
there are free apps for android and iphone to generate sequences as a
2nd factor.
t
I've been doing something with my site/app (phresheez) that is helpful
on that front: instead of having them use their password, the app auto-generates
a password for the user instead. I did this mainly for convenience -- users
hate typing on their phones -- but it has the nice property that you don't
have a domino effect if a password on my site is compromised. Since most
browsers auto-remember your passwords anyway, it even works in the web
world too.
For most need-to-join sites, I think this is a pretty reasonable solution. Maybe
not for, oh say, financial sites where password recovery is a little bit scarier,
but for the run of the mill app/site... it seems that this solution at least
solves the domino problem.
Mike
It's not a side issue; in my opinion it's a far more important issue in
most situations. I do the same thing that you do for all but my most
critical passwords.
--Steve Bellovin, https://www.cs.columbia.edu/~smb
For most need-to-join sites, I think this is a pretty reasonable solution. Maybe
not for, oh say, financial sites where password recovery is a little bit scarier,
but for the run of the mill app/site... it seems that this solution at least
solves the domino problem.
There is indeed a difference between Europe (or is it only .SE?) and
USA here; no bank in Sweden lets you login without at least a client
certificate and password/pin code. Most banks have a hardware token,
either challenge-response or HOTP/TOTP; some use the chip in chip-and-pin
cards as certificate carrier, and combine it with a reader device to
manage pin code entry.
....
A side issue is the people who use the same password at fuzzykittens.com as they do at bankofamerica.com. Of course fuzzykittens doesn't need high security for their password management and storage. After all, what's worth stealing at fuzzykittens? All those passwords.
Second obligatory xkcd reference (Password reuse):
There is indeed a difference between Europe (or is it only .SE?) and
USA here; no bank in Sweden lets you login without at least a client
certificate and password/pin code. Most banks have a hardware token,
either challenge-response or HOTP/TOTP; some use the chip in chip-and-pin
cards as certificate carrier, and combine it with a reader device to
manage pin code entry.
Can't speak for Europe as a whole, but certainly in the UK it's not common - and I wish it was. I do have different passwords for my banking and other finance-type sites (pensions etc), both for each site and distinct from my "fuzzykittens" passwords (which do re-use a handful of variations on a couple of themes). A hardware token would be very nice though.
Client cert worries me a bit - while it *should* be standards-based, I'm sure there's some way to implement it such that it only works on Windows. Given how long it took for banks to stop with the "Safari! Evil! Access denied!" routine, I don't hold much faith in their willingness or ability to build cross-platform solutions.
Grumble for the day: Santander, who require so many different IDs, logins, codes, reference numbers etc to access their on-line services with no indication at all of how any of them relate to the documentation previously sent or any changes made since, that there's no way to deal with it other than to write them down. Oh, and some more different codes, with more different names, to access the same account by telephone. Strongly not recommended.
Regards,
Tim.
One site I saw would break when you exceeded the maximum length but silently accept it. Making the users jump through sufficient hoops to generate a password and keep it for the sake of "security" only serve to weaken the resolve of users and complexity of passwords used.
Dare I say, if a password system is too cumbersome I may reject them as an employer at some point out of frustration, or just call the help desk daily to reset the password.
back to the OP question. I've used the Quest system as a user and found it useful. Having this outside any VPN for your remote users is very helpful.
- Jared
fwiw, citibank in the states uses normal passwording for personal
accounts. but citibank business uses two-factor with a password
and a customized vasco digipass 270.
randy
