New York Times article on password security

rwmidl

This was in Saturday's NYT. A Strong Password Isn't the Stongest Security

dynamik

A lot of that is pretty common-sense and well-known. If someone can run code on your box, it's not yours anymore. Passwords are obviously going to be no help to you at that point.

I disagree with the no lockouts because of concerns over denial-of-service. People bring that up all the time, but I never see it or even hear of it happening. You also don't need to lock out an account for 24 hours. If you lock out an account for 5 minutes after 3 invalid attempts, you're still reducing the rate of guesses to 36 per hour, instead of hundreds or thousands per minute. Depending on what type of service this is, you could use something like Fail2ban to block IPs doing the guessing, so someone can't just load a tool up and have it perpetually lock out the account. I think the benefits outweigh the potential problems. However, you should always have a way to except accounts or disable the policy altogether in the unlikely event that something like that should occur.

I do like limiting the sequence of letters from previous passwords. People too often just increment the last number by one whenever their password expires. i.e. Password1, Password2, Password3, etc.

It really comes down to user education and awareness. Users can make stupid passwords that still satisfy complexity requirements. Password1 is a perfect example of this. That's an acceptable password for systems that require three of the four: lowercase, uppercase, numbers, and symbols, and it meets the common length requirement of 8 characters.

rwmidl

I'm not against no lockouts, but (my opinion) it should be a high number - like 100 - not 3/4 failed attempts. My curiosity would be much higher if the logs showed a high number of failed attempts in a row. If a user has forgotten their password or can't get it right, they are going to put a call in vs trying 50 or so times in a row.

Recently I've become a fan of using sentences for a password. Using something like "I like 5 different kinds of cheese." meets/exceeds most complexity requirements and more often than not can be easily remembered by the end user.

tiersten

rwmidl wrote: »

I'm not against no lockouts, but (my opinion) it should be a high number - like 100 - not 3/4 failed attempts.

Why 100? It is a bit extreme. You could do 90 attempts a day if you knew that the user is guaranteed to log in every day. If the user only gets 3 attempts then has to call then I'd be fairly obvious if somebody is trying to break in.

I might know the person so would have a much better idea of what sort of password they'll use.

rwmidl

If someone is trying to brute force an account it will quickly hit that 100 attempt threshold (or it could be indicative of a service account with an expired password?) I've fat fingered my account multiple times where I've locked myself out after 3 attempts.

tiersten

rwmidl wrote: »

If someone is trying to brute force an account it will quickly hit that 100 attempt threshold (or it could be indicative of a service account with an expired password?) I've fat fingered my account multiple times where I've locked myself out after 3 attempts.

What is the benefit of increasing the limit to 100 apart from the administrator not needing to reset the password as often? All I can see are downsides.

dynamik

tiersten wrote: »

I might know the person so would have a much better idea of what sort of password they'll use.

Right. I forget the name of the tool we were playing with, but you basically entered all the information you knew about a person, such as relatives' names, hobbies, birthdays, phone numbers, etc., and it generates thousands of different combinations and variations with all the information you entered.

Also, if you have a shorter lockout instead of 24 hours, or requiring an account to be manually unlocked, just wait it out if you fat-finger it. You can set the threshold higher, but I agree, if someone can't get their password in 3-5 attempts, they've probably forgotten in.

The sentences you're referring to are known as "pass phrases," and I'm a proponent of those as well.

Edit: here's an interesting site with some password statistics: http://www.skullsecurity.org/wiki/index.php/Passwords He did an analysis of the compromised Rock You passwords (see the coverage section), and only 13 passwords got into 5% of the accounts. *SCARY*

rwmidl

If the user has fat fingered/forgotten their password they will call for a reset. What is the added purpose of locking the account if the user has honestly forgotten what their password is? In the end they (the sys admin/help desk) is still going to have to reset the password.

rwmidl

dynamik wrote: »

Right. I forget the name of the tool we were playing with, but you basically entered all the information you knew about a person, such as relatives' names, hobbies, birthdays, phone numbers, etc., and it generates thousands of different combinations and variations with all the information you entered.

Also, if you have a shorter lockout instead of 24 hours, or requiring an account to be manually unlocked, just wait it out if you fat-finger it. You can set the threshold higher, but I agree, if someone can't get their password in 3-5 attempts, they've probably forgotten in.

The sentences you're referring to are known as "pass phrases," and I'm a proponent of those as well.

Edit: here's an interesting site with some password statistics: Passwords - Skull Security He did an analysis of the compromised Rock You passwords (see the coverage section), and only 13 passwords got into 5% of the accounts. *SCARY*

Passphrases are the way to go. There was something I heard where for men they more often than not use sports teams/mascots in their password and for women it's kids names/birthdays/anniversaries.

tiersten

rwmidl wrote: »

If the user has fat fingered/forgotten their password they will call for a reset. What is the added purpose of locking the account if the user has honestly forgotten what their password is? In the end they (the sys admin/help desk) is still going to have to reset the password.

It just sounds like the adminstrator doesn't want to be bothered with resetting accounts to me.

I've had users tell me what their password scheme is. Like name of a sports team and a number. If I know what their favourite teams are then I could do quite a few guesses if I had 100 attempts before anything locks out.

I know users who would use up all 100 attempts before calling anyway.

Mojo_666

I also agree with the article and it is just widley practiced common sense. I have never implimented overly strong password policy, strong yes, but not so strong users have issues remembering their passwords or cauing issues with lockouts. Locking down users and their usage is far more important, as is virus protection just in case your desktop security did not go to plan.

DevilWAH

Why would you possible want 100 attempts before a lock out.

some one running a brute force attack may on average need 100,000 of attempts before getting it right. But then again they may get it right on the 10th attempt..

And if you say your curiosity would be engaged if you say say 30 attempts then if you are saying this would get you attention. then surely that is the point you want to lock the account down. Why let it carry on if you are saying at x number of attempts you would look in to it.

One thing I would say is allowing help desk engineers to unlock the accounts! many times with out any more security checks than. "can you tell me your user name?". I think password prompts if set-up correctly can put an extra block against social engineering and allow users to sort them selves out with out bothering the IT unit. You lock you account out after 5 attempts, you are directed to a reset password page with 2 or 3 prompt questions.

we use strong passwords, (upper lower numeric and special has to contain one of each) 8 in length and can't contain user name or repeat from last password. It does anoy a lot of people, but we suggest the first letter of each word in a phrase, with a date in between + a special caricature some where.

so like

"I like to visit techexams 21 of august " may become 21Iltvt8*!

easy to remember but very hard to brute force.

rwmidl

DevilWAH wrote: »

Why would you possible want 100 attempts before a lock out.

some one running a brute force attack may on average need 100,000 of attempts before getting it right. But then again they may get it right on the 10th attempt..

And if you say your curiosity would be engaged if you say say 30 attempts then if you are saying this would get you attention. then surely that is the point you want to lock the account down. Why let it carry on if you are saying at x number of attempts you would look in to it.

One thing I would say is allowing help desk engineers to unlock the accounts! many times with out any more security checks than. "can you tell me your user name?". I think password prompts if set-up correctly can put an extra block against social engineering and allow users to sort them selves out with out bothering the IT unit. You lock you account out after 5 attempts, you are directed to a reset password page with 2 or 3 prompt questions.

we use strong passwords, (upper lower numeric and special has to contain one of each) 8 in length and can't contain user name or repeat from last password. It does anoy a lot of people, but we suggest the first letter of each word in a phrase, with a date in between + a special caricature some where.

so like

"I like to visit techexams 21 of august " may become 21Iltvt8*!

easy to remember but very hard to brute force.

Using your same argument, someone trying brute force could in theory crack the password in 1-2 tries with a lockout policy of three failed attempts. Obviously the longer/more complex the password is the more difficult it is to break.

I'm not saying that 100 failed attempts should be the standard. I'm just trying to throw in a different thought process since the "standard" seems to be 3 failed attempts (at least at the places I've worked).

tiersten

rwmidl wrote: »

Using your same argument, someone trying brute force could in theory crack the password in 1-2 tries with a lockout policy of three failed attempts. Obviously the longer/more complex the password is the more difficult it is to break.

I'm not saying that 100 failed attempts should be the standard. I'm just trying to throw in a different thought process since the "standard" seems to be 3 failed attempts (at least at the places I've worked).

A value of 3 to 5 is generally considered the industry standard value or best practices value. It is a compromise between instantly locking somebody out and allowing so many attempts that it would be possible to bruteforce the password. It is still high enough that if somebody does a typo or forgets to turn off caps lock that they're not locked out.

There isn't anything stopping you from changing it but I don't see any useful advantage of changing it. A change from say 3 to 10 isn't going to be completely destroy your security but there is little to justify doing it. Setting it a high number like 100 just makes it more likely that a coworker will be able to guess what the password is and masquerade as that user.

All you'll end up with is not finding out that users or service accounts have been locked out until many more attempts have been made. If you really don't like resetting passwords for users then delegate the job to somebody else.

Paul Boz

I recently read a whitepaper called “Popularity is everything – a new approach to protecting passwords from statistical-guessing attacks.” URL: Popularity is Everything: A new approach to protecting passwords from statistical-guessing attacks - Microsoft Research

Basically the gist of the paper is that using a matrix of password hashes (assuming no salting is going on), larger password repositories (like those maintained by ISPs and large e-commerce sites) can block statistically common passwords. Many web services such as Yahoo already tell you if a password is too common for use. There are several drawbacks to this sampling method. First, it assumes that no salting of the password hashes is occurring. If salting was occurring it would be impossible to determine the frequency of a password based on the hash alone. Second, it only hampers statistical-based password attacks. It does nothing for brute-forcing or dictionary attacks.

Password policies are one of the hardest things for companies to adequately implement. Either the requirements are not harsh enough or they’re too harsh. Either the lockout is too harsh or it does nothing. CIS provides system benchmarks for SSLF (secured configuration) and Enterprise (standard configuration). According to the CIS Windows 7 benchmark, a timeout period of 15 minutes for secure and non-secure devices should be enforced. However, the account lockout threshold is as follows: For secure configured devices the recommended value is 10 attempts. For standard devices the threshold is 50 attempts. If you do the math that is only 40-200 attempts per hour (assuming no one detects the brute force attempts). In my experience grinding on passwords that is far too few attempts to be useful. Perhaps if the users were using standard dictionary words with no complexity requirements it would be sufficient to brute the passwords, but it would still take forever. The design of those thresholds is two-fold. One, it gives a user a sufficient number of attempts to remember the password without locking out and having to receive support. Two, if someone actually locks their account after 100 password guesses you either have an attack on your hands or a reaaaaaaaaaaally stupid user. Either scenario serves to tune out junk alerts (events triggered because of dumb users) and provide only the situations which should be looked in to.

veritas_libertas

I was afraid this conversation would turn boring. I'm glad it got deeper than, "Use 8 characters, Upper Case/Lower Case, numerals, and symbols."

@PaulBoz: Thank for introducing me to Microsoft Research!

Paul Boz

veritas_libertas wrote: »

I was afraid this conversation would turn boring. I'm glad it got deeper than, "Use 8 characters, Upper Case/Lower Case, numerals, and symbols."

@PaulBoz: Thank for introducing me to Microsoft Research!

There's always more to the story than basic details.

veritas_libertas

Paul Boz wrote: »

There's always more to the story than basic details.

Oh I agree, but it often doesn't get beyond the basics.

rwmidl

Paul Boz wrote: »

I recently read a whitepaper called “Popularity is everything – a new approach to protecting passwords from statistical-guessing attacks.” URL: Popularity is Everything: A new approach to protecting passwords from statistical-guessing attacks - Microsoft Research

Basically the gist of the paper is that using a matrix of password hashes (assuming no salting is going on), larger password repositories (like those maintained by ISPs and large e-commerce sites) can block statistically common passwords. Many web services such as Yahoo already tell you if a password is too common for use. There are several drawbacks to this sampling method. First, it assumes that no salting of the password hashes is occurring. If salting was occurring it would be impossible to determine the frequency of a password based on the hash alone. Second, it only hampers statistical-based password attacks. It does nothing for brute-forcing or dictionary attacks.

Password policies are one of the hardest things for companies to adequately implement. Either the requirements are not harsh enough or they’re too harsh. Either the lockout is too harsh or it does nothing. CIS provides system benchmarks for SSLF (secured configuration) and Enterprise (standard configuration). According to the CIS Windows 7 benchmark, a timeout period of 15 minutes for secure and non-secure devices should be enforced. However, the account lockout threshold is as follows: For secure configured devices the recommended value is 10 attempts. For standard devices the threshold is 50 attempts. If you do the math that is only 40-200 attempts per hour (assuming no one detects the brute force attempts). In my experience grinding on passwords that is far too few attempts to be useful. Perhaps if the users were using standard dictionary words with no complexity requirements it would be sufficient to brute the passwords, but it would still take forever. The design of those thresholds is two-fold. One, it gives a user a sufficient number of attempts to remember the password without locking out and having to receive support. Two, if someone actually locks their account after 100 password guesses you either have an attack on your hands or a reaaaaaaaaaaally stupid user. Either scenario serves to tune out junk alerts (events triggered because of dumb users) and provide only the situations which should be looked in to.

Paul - thanks for your insight. I guess I should have clarified my stance on the 100 attempts as I was meaning that towards a desktop (ie standard device). Servers or other secured devices should have a lower threshold.

dynamik

Paul Boz wrote: »

First, it assumes that no salting of the password hashes is occurring. If salting was occurring it would be impossible to determine the frequency of a password based on the hash alone.

It does not allow per entry salting. If all the passwords were using the same salt, you could just as easily do the same statistical analysis if no salt were being used.

rwmidl wrote: »

Paul - thanks for your insight. I guess I should have clarified my stance on the 100 attempts as I was meaning that towards a desktop (ie standard device). Servers or other secured devices should have a lower threshold.

A desktop is just a stepping stone to a server...

undomiel

dynamik wrote: »

I disagree with the no lockouts because of concerns over denial-of-service. People bring that up all the time, but I never see it or even hear of it happening.

I've seen it happen twice. One client we picked up was completely locked out of his server for 48 hours due to all administrative accounts being locked out by a brute force attempt. I've also seen a case where someone was running services under the administrator account and changed the admin password. The services were set to automatically restart immediately so the account was locked out until we found the improperly configured services.

rwmidl

dynamik wrote: »

A desktop is just a stepping stone to a server...

true, that is why you would have the threshold for servers be a lot lower and more strict than you would say a desktop.

dynamik

undomiel wrote: »

I've seen it happen twice. One client we picked up was completely locked out of his server for 48 hours due to all administrative accounts being locked out by a brute force attempt. I've also seen a case where someone was running services under the administrator account and changed the admin password. The services were set to automatically restart immediately so the account was locked out until we found the improperly configured services.

Oh, forgetting to update service passwords is pretty common. I meant an actual attack, not a self-inflicted oversight (overlooking the fact that the service should not have been running with the administrator account in the first place)

I'm not saying it never happens, but the way the issue is discussed, you'd think it's common occurrence. There's obviously going to be inconveniences either way, but I'd personally go with the lockout policy.

An account lockout also serves as an alert that an attack is taking place. Would they have noticed that attack if the account wasn't locked out, or would the attacker have been allowed to continue to grind away until he (or she) got in?

rwmidl wrote: »

true, that is why you would have the threshold for servers be a lot lower and more strict than you would say a desktop.

But once you get a desktop, there are so many other things you could do. Crack the local system hashes and see if they're being re-used on servers, MitM, pass-the-hash, key-logging, etc. I wouldn't just start brute-forcing other systems/services at that point.

chuckles

Pass phrases rock and are the only way to go! I get upset when I can't (because a space is not allowed). You can even substitute a number and special characters and meet most requirements. For example, "Techexams Rules" could become "T3chexams Ru7es!" Try to guess that one!

dynamik

chuckles wrote: »

For example, "Techexams Rules" could become "T3chexams Ru7es!" Try to guess that one!

Don't become too reliant on l33t-speak. Most password guessing tools perform transformations that iterate through various combinations of case and do common replacements with symbols and numbers. Here's a sample of what JTR gave me with some transformations I put in for "techexams":

techex4ms
Techex4ms
t3ch3xams
T3ch3xams
techexam$
Techexam$
t3ch3x4ms
T3ch3x4ms
techex4m$
Techex4m$
t3ch3xam$
T3ch3xam$
t3ch3x4m$
T3ch3x4m$
--snip--