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 ----- Original Message ----- From: "Jones, Barry" <BEJones@semprautilities.com> To: <Nanog@nanog.org> Sent: Monday, January 02, 2012 3:27 PM Subject: AD and enforced password policies 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.
On Mon, Jan 2, 2012 at 2:27 PM, Jones, Barry <BEJones@semprautilities.com>wrote:
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...
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 -- http://technet.microsoft.com/en-us/library/cc875814.aspx#ECAA http://technet.microsoft.com/en-us/library/cc786468%28WS.10%29.aspx 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. -- -JH
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 -----Original Message----- From: Jimmy Hess [mailto:mysidia@gmail.com] Sent: Monday, January 02, 2012 3:33 PM To: Jones, Barry Cc: Nanog@nanog.org Subject: Re: AD and enforced password policies On Mon, Jan 2, 2012 at 2:27 PM, Jones, Barry <BEJones@semprautilities.com>wrote:
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...
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 -- http://technet.microsoft.com/en-us/library/cc875814.aspx#ECAA http://technet.microsoft.com/en-us/library/cc786468%28WS.10%29.aspx 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. -- -JH
Subject: RE: AD and enforced password policies Date: Mon, Jan 02, 2012 at 11:15:08PM +0000 Quoting Blake T. Pfankuch (blake@pfankuch.me):
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. (http://en.wikipedia.org/wiki/File:Kw-26.jpg) -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Life is a POPULARITY CONTEST! I'm REFRESHINGLY CANDID!!
On Jan 3, 2012, at 4:14 AM, Måns Nilsson wrote:
Subject: RE: AD and enforced password policies Date: Mon, Jan 02, 2012 at 11:15:08PM +0000 Quoting Blake T. Pfankuch (blake@pfankuch.me):
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. (http://en.wikipedia.org/wiki/File:Kw-26.jpg)
-- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Life is a POPULARITY CONTEST! I'm REFRESHINGLY CANDID!!
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
http://www.diceware.com/ 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 On Tue, Jan 3, 2012 at 8:09 AM, Greg Ihnen <os10rules@gmail.com> wrote:
On Jan 3, 2012, at 4:14 AM, Måns Nilsson wrote:
Subject: RE: AD and enforced password policies Date: Mon, Jan 02, 2012 at 11:15:08PM +0000 Quoting Blake T. Pfankuch (blake@pfankuch.me):
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. (http://en.wikipedia.org/wiki/File:Kw-26.jpg)
-- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Life is a POPULARITY CONTEST! I'm REFRESHINGLY CANDID!!
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
On 01/03/2012 05:09 AM, Greg Ihnen wrote:
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
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
Subject: Re: AD and enforced password policies Date: Tue, Jan 03, 2012 at 05:31:12AM -0800 Quoting Michael Thomas (mike@mtcc.com):
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. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Hello? Enema Bondage? I'm calling because I want to be happy, I guess ...
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.
Subject: Re: AD and enforced password policies Date: Tue, Jan 03, 2012 at 02:16:38PM -0000 Quoting Tim Franklin (tim@pelican.org):
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.
If it only was one token for all. Public services usually use most of the several national ID card "standards" that we have so for things like doing tax returns, applying for public health insurance payments, etc, one solution "works" -- but all the others have one each. Identity federations are probably the way to go.
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.
It sometimes works. Sometimes not. I have chip-and-pin with cert on and reader. If I use it as a standalone authenticator I can even use elinks, but to use it as national ID card I need to run a bunch of apps, and must stay on Firefox3. This is for OSX. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 UH-OH!! I think KEN is OVER-DUE on his R.V. PAYMENTS and HE'S having a NERVOUS BREAKDOWN too!! Ha ha.
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
additionally, etrade in the states has had 2-factor authentication (RSA token) for over 8 or 9 years now. it's one reasonable reason to stay with them. t On Tue, Jan 3, 2012 at 10:52 PM, Randy Bush <randy@psg.com> wrote:
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
On Jan 3, 2012, at 8:09 19AM, Greg Ihnen wrote:
On Jan 3, 2012, at 4:14 AM, Måns Nilsson wrote:
Subject: RE: AD and enforced password policies Date: Mon, Jan 02, 2012 at 11:15:08PM +0000 Quoting Blake T. Pfankuch (blake@pfankuch.me):
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. (http://en.wikipedia.org/wiki/File:Kw-26.jpg)
-- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Life is a POPULARITY CONTEST! I'm REFRESHINGLY CANDID!!
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.
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
'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 you want to make them really, really unhappy, implement a rotating user ID coupled with an often expiring password policy. For example, User ID jjones1, jjones2, jjones3, jjones4 (for winter, summer, fall, spring). Works with clothing choices, but angers user communities... :-) -----Original Message----- From: Steven Bellovin [mailto:smb@cs.columbia.edu] Sent: Tuesday, January 03, 2012 5:41 AM To: Greg Ihnen Cc: Nanog@nanog.org Subject: Re: AD and enforced password policies On Jan 3, 2012, at 8:09 19AM, Greg Ihnen wrote:
On Jan 3, 2012, at 4:14 AM, Måns Nilsson wrote:
Subject: RE: AD and enforced password policies Date: Mon, Jan 02, 2012 at 11:15:08PM +0000 Quoting Blake T. Pfankuch (blake@pfankuch.me):
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. (http://en.wikipedia.org/wiki/File:Kw-26.jpg)
-- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Life is a POPULARITY CONTEST! I'm REFRESHINGLY CANDID!!
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.
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
On Tue, Jan 3, 2012 at 05:09, Greg Ihnen <os10rules@gmail.com> wrote: ....
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): http://xkcd.com/792/
On Tue, Jan 3, 2012 at 2:44 AM, Måns Nilsson <mansaxel@besserwisser.org>wrote:
Subject: RE: AD and enforced password policies Date: Mon, Jan 02, 2012 at 11:15:08PM +0000 Quoting Blake T. Pfankuch (blake@pfankuch.me):
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.
[snip] A good use for expiration is to mitigate the risk that a password was guessed or accidentally leaked but not used yet to launch a detected attack / abuse the account -- expiration of the password doesn't destroy leaked data or uninstall malware, so it is not any sort of replacement for proper intrusion detection, security monitoring, and explicit incident response. It is more secure to have solid intrusion detection, alarms, or 2 factor auth. For internet-connected systems; 5 day, 10 day, 30 day, 60 day password expirations are fairly useless, because the intruder guesses the password one day, and probably abuses it in less than 24 hours; 6-month and 12-month expirations accomplish very similar, but much less of a nuisance. Chances are very good that if a password is leaked, it will be abused long before it expires, and if you don't detect the compromise, this means your intrusion detection systems have failed; expiration of the password doesn't erase the results of a successful compromise, or lock out the successful intruder. So password expiration is not a good crutch. A more effective expiration measure is to use 2-factor authentication, with one time passwords that expire within 30 seconds. Manual forced immediate password expiration should be in the security admin's toolbox as a possible response to observation of questionable or potentially remotely suspicious activity on a system that user had been logged into recently. -- -JH
Subject: Re: AD and enforced password policies Date: Tue, Jan 03, 2012 at 10:58:35PM -0600 Quoting Jimmy Hess (mysidia@gmail.com):
Manual forced immediate password expiration should be in the security admin's toolbox as a possible response to observation of questionable or potentially remotely suspicious activity on a system that user had been logged into recently.
Indeed. If doubt arises, just change. Have been on the fringe of a kdc compromise. 10000 students and faculty were required to show up in person and change on approved terminals. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Wow! Look!! A stray meatball!! Let's interview it!
On Mon, Jan 2, 2012 at 22:32, Jimmy Hess <mysidia@gmail.com> wrote: ....
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: http://xkcd.com/936/ Gary
On Jan 2, 2012, at 7:05 PM, Gary Buhrmaster wrote:
On Mon, Jan 2, 2012 at 22:32, Jimmy Hess <mysidia@gmail.com> wrote: ....
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: http://xkcd.com/936/
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?
On Jan 2, 2012, at 9:10 PM, Lyndon Nerenberg wrote:
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
On Mon, Jan 2, 2012 at 8:16 PM, Steven Bellovin <smb@cs.columbia.edu> wrote:
On Jan 2, 2012, at 9:10 PM, Lyndon Nerenberg wrote: 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.
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 ! . , ' ; & + - -- -JH
On Jan 2, 2012, at 8:45 PM, Steven Bellovin wrote:
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!+={}[]\|;:/?.,<>"'`!
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
On 02/01/2012 20:27, Jones, Barry wrote:
Specifically, I need to enforce the use of length, special characters, and be able to validate the enforcement of such.
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
participants (15)
-
Blake T. Pfankuch -
Gary Buhrmaster -
Greg Ihnen -
Jared Mauch -
Jimmy Hess -
Jones, Barry -
Lyndon Nerenberg -
Michael Thomas -
Måns Nilsson -
Nick Hilliard -
Randy Bush -
Robert Luethje -
Steven Bellovin -
Tim Franklin -
Todd Underwood