August 28, 2009 at 8:47 am
Excellent analysis Gus. The only hole I see is that many systems remove a lockout after 15 or 30 minutes. However I suspect bots would be designed to "move on" after they encountered a lockout wouldn't they?
To me it all boils down to:
"Protecting" stuff that isn't worth protecting
Overkill in protecting some stuff
Creating a false sense of security (sniffing my bank account number is worth more than cracking my password.)
And hanging on to outdated concepts because "thats what everyone has always done."
Oh, and yes I do believe in good security, but the above issues result in bad security.
August 28, 2009 at 9:49 am
I have also seen 60 and 90 days limits ... but i like the idea of a multiple of 7 .....
Whet i end up doing is that I have an old beer menu from one of my favourite restaurants -- its got an amazing list of some 150 different beer names .... i pick one of them and play around with numbers/special characters substituing letters ..... and the day i change it ... i go and order that same beer for the next few times ... so I remember 🙂
that works for my AD passwords as well
-------------------------------------------------
-Amit
Give a man a fish and he'll ask for a lemon. Teach a man to fish and he wont get paged on weekends !! :w00t: - desparately trying to fish [/size]
August 28, 2009 at 11:16 am
I find the 90 day password expiratoin policy to be a nuisance as well as a completely worthless and unproven "security measure". Instead you should be educating people to use more friendly, easier to type, but at the same time more mathematically secure, "password phrases". For example, I don't know what the exact password policy is here in terms of length and character usage, but let's say you enforce that a password must have at least one lower case letter, upper case letter, number, special character, and be at least seven characters long. To keep things basic, let's say that character set size comes to a total of 72 possible characters (26 + 26 + 10 + 10) (we just use the special characters above the numbers). Now for a seven character password, the total number of password permutations is only:
72^7 = 10030613004288
Now let's say instead you focus your efforts on educating people to use a "password phrase" instead. Naturally these are going to be longer in length, come from a smaller character set size, but be faster and easier to type as well as easier to remember. As another example, let's say a "passwor phrase" comes from the character set made up of simply lower case letters and a space. For a whopping 27 possible characters. As I said, due to their nature, a "password phrase" will almost always be longer than a regular password. In this example, all it takes is a mere 10 characters and the "password phrase", even with it's significantly reduce character set, becomes 20 times harder to hack than the seven character password.
27^10 = 205891132094649
Lastly, I believe that if you got rid of the current password restriction policy and instead focused your efforts on educating people to use "password phrases", you'd reduce the tech support time that is spent on people not being able to log in or do other things simply because they forgot their password. Remember, using something like "password policy
sucks" is actually faster to type for most people, easier to remember, and more mathematically secure than something like "vj74%kdu1".
August 28, 2009 at 11:28 am
bob.willsie (8/28/2009)
Excellent analysis Gus. The only hole I see is that many systems remove a lockout after 15 or 30 minutes. However I suspect bots would be designed to "move on" after they encountered a lockout wouldn't they?To me it all boils down to:
"Protecting" stuff that isn't worth protecting
Overkill in protecting some stuff
Creating a false sense of security (sniffing my bank account number is worth more than cracking my password.)
And hanging on to outdated concepts because "thats what everyone has always done."
Oh, and yes I do believe in good security, but the above issues result in bad security.
With an automatic 15 minute lockout, the math goes something like this:
It'll take 250 seconds (theoretically) to brute force an 8 digit password. It's actually going to be less than that unless the password is the absolutely last possible combination. So let's assume 125 seconds on average. That's at 20-billion tries per second.
So, 3 tries (3/20,000,000,000ths of a second), followed by a 15-minute wait, then 3/20,000,000,000ths of a second, followed by a 15-minute wait. And so on. We're assuming that it will take an average of 2.5-trillion attempts (half the possible combinations). Divided by 3 = 833-billion iterations of this pattern = approx 12.5-trillion minutes (@15 minutes and 3/20-billionths of a second per cycle) = approx 208-billion hours = approx 8.6-billion days = approx 23.8-million years. Even botnets don't have that kind of patience!
But, just to be on the extra safe side, yes, a policy that requires people to change their 8-character password every 23-million years would improve your safety on such a system. Might want to go with every 1-million years, just to be on the paranoid side.
Edit: Corrected a misplaced decimal in the math and a typo.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
August 28, 2009 at 11:35 am
GSquared's botnet math assumes that the more bots you add, the faster the password will get hacked. While there is obviously nothing wrong with the math, and I know it's just an example, you appear to be overlooking one thing. Just because I add a million more bots doesn't mean I can crack the password any faster because those million bots will all be trying to talk to the same server that they are trying to hack. So the speed will actually be limited by the server they are trying to hack.
August 28, 2009 at 11:38 am
Did anyone consider the security risk of posting on the internet the length of time you keep a password?
I won't go into detail on length of time, at my company or at home, but I will say that if force people to update their passwords to frequently they will come up with a pattern which will make their new password transparent based on their old password.
For home use I have levels of passwords. My passwords for financial accounts (banks, investments etc) are more complex and change more frequently than passwords for sites with saved credit card information, which have more complex and frequently changing passwords than social networking and email, which are more complex and frequently changing than my password for say this site.
I'm also careful to keep my work passwords completely separate from anything "home" in case of the off chance I need to give it out.
August 28, 2009 at 11:38 am
kevin77 (8/28/2009)
GSquared's botnet math assumes that the more bots you add, the faster the password will get hacked. While there is obviously nothing wrong with the math, and I know it's just an example, you appear to be overlooking one thing. Just because I add a million more bots doesn't mean I can crack the password any faster because those million bots will all be trying to talk to the same server that they are trying to hack. So the speed will actually be limited by the server they are trying to hack.
Yeah, I'm assuming everything works on the botnet's favor. For example, they have perfect coordination so they don't try the same combinations as each other, ever. Infinite bandwidth, too.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
August 28, 2009 at 1:42 pm
Great analysis, GSquared, but it also means that we are assuming that the botnet doesn't get a hash of the password.
To me that's the bigger danger. A backup tape or some other disclosure of the encrypted password is then attacked. I don't know the parallelism, but I assume that there are people that can brute force a series of passwords at the same time.
August 30, 2009 at 12:12 am
For ID's that are powerful, like admin's, and are authenticated by Active Directory, we use a smart card, or require that the ID be checked out from an application that assigns random passwords. When the ID is checked back in, the password is changed. On SQL Server, we disallow the use of sa for any reason at all. We may assign admin rights to another ID, but I can't recall sa use being allowed in the last 7 years.
August 31, 2009 at 7:27 am
Steve Jones - Editor (8/28/2009)
Great analysis, GSquared, but it also means that we are assuming that the botnet doesn't get a hash of the password.To me that's the bigger danger. A backup tape or some other disclosure of the encrypted password is then attacked. I don't know the parallelism, but I assume that there are people that can brute force a series of passwords at the same time.
Hash-matching is still a dictionary lookup. The processing time is either shorter than 30 days (it's measured in milliseconds for most things that are based on real words), or is measured in years, decades or centuries.
It's generally easier to get a real password than it is to get a hash, anyway. That's why I think fixed-interval password policies are a sop. They make you feel like you're accomplishing something useful, without any significant result. It's like putting bars on the attic windows while leaving the front door propped open.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
August 31, 2009 at 11:25 am
That's an interesting point of view. It seems to make sense to me, but I'm not sure I understand the issue. I think I'll send this to Bruce Schneier, I'd love to see him comment on it, and maybe then I could get my password set to "infinity" at work.
September 9, 2009 at 1:21 pm
Steve Jones - Editor (8/31/2009)
That's an interesting point of view. It seems to make sense to me, but I'm not sure I understand the issue. I think I'll send this to Bruce Schneier, I'd love to see him comment on it, and maybe then I could get my password set to "infinity" at work.
Did you get a reply?
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
October 29, 2009 at 9:05 am
GSquared (8/28/2009)
I see mandatory password changes on a fixed interval as a sop to security without any actual value, and with the potential of negative value.
A great and valuable comment.
Only two things to disagree with in the whole thing. the first is in the first sentence (quoted above). It's that word "potential". If you had said "with high actual" instead of "with the potential of" I would have been in complete agreement. At the very least you are going to make people unhappy with a frequent change policy, and you are going to suffer one of reduced security (from passwords written down qand badly concealed) or frequent password resets which wastes admin time and user time.
The second is to do with the justification for frequent change: the frequent change and no reuse policy has never been justified except as a means of educing the time during which the compromised password is available to the attacker; if you change your password you are just as likely to change it to something closer to where an attacker's search pattern is going next as to something further away, so it doesn't reduce the risk of compromise and you can't justify it on grounds of reduced risk of compromise. Yes, a lot of people HAVE attempted to justify it on that ground, and your comment thoroughly debunks this - but you don't really address the reduced duration of unwanted access issue. Now that's actually a minor niggle, because there are only three ways passwords get comporomised: (i) deliberate disclosure, (ii) physical spying (key-logger, network interception, shoulder-surfing,...); and (iii) accidental disclosure (postit note stuck to frame of screen or underside of desk, badly disguised password in diary,...). Frequent change doesn't help against (i) because the inside traitor will disclose the new password straight away; it reduces the length of individual exposures for (iii), but increases their frequency by more than enoughto compensate so it doesn't help here either; and the proper approach to number (ii) is good physical security plus decent challenge response authentication instead of passing passwords around in the clear - if number (ii) is happening and not being detected you would need to change all passwords every 10 minutes for frequent change to be much use.
To answer Steve's queries about password change frequency: In my last shop I introduced a simple policy that at windows level everyone would have individual accounts; all well-known account names (eg Administrator) would be disabled; users could change their passwords as often or as rarely as they liked; accounts would be disabled for anyone who left. At SQL level I wanted to do the same, but it meant setting up interdomain trusts between our sites and customer sites and the sysadmin was still working on how best to do it when I left (it's not as extreme as it might seem at first site - we had complete control over the servers on customer sites that ran our apps and the customer had access only through GUIs we provided) - but the plan is going ahead and soon (I hope) there will be no SQL logins but there will still be remote Query Analyser, Management (EM and/or Management Studio), trusted server access, and so on using cross-domain windows accounts. So passwords will change rarely, if ever - new passwords will be introduced for new people, old passwords will be removed when people leave, and that's all the change there should be unless something is compromised.
Tom
October 29, 2009 at 9:50 am
Steve Jones - Editor (8/28/2009)
Great analysis, GSquared, but it also means that we are assuming that the botnet doesn't get a hash of the password.To me that's the bigger danger. A backup tape or some other disclosure of the encrypted password is then attacked. I don't know the parallelism, but I assume that there are people that can brute force a series of passwords at the same time.
Well, it's a good idea to make sure that the file of hashed passwords doesn't leak out. Unix systems started using shadow password files a couple of decades ago, and people understood that if you backed those up the backup had to be protected too. Physical security and encryption can go a long way towards making this a non-problem. Windows has had quite good password security for quite some time now (for example it uses kerberos so that passwords are not exposed on the network) so it would surprise me if this hasn't been adressed at least reasonably well.
You can also make it pretty impossible to use a pre-calculated hash table to do the lookup simply by pre- and post- pending random [well, sort of random - most machines don't have a good dource of random bits] seeds to each newly chosen password before hashing, and storing these seeds along with the hash. This has been standard practise for maybe 40 years now (well, 40 years ago maybe just prepending, not pre- and post-). Then you can add to the security by using a slow hash function instead of a fast one (it's OK if caculating the hash takes 0.2 secs, for an interactive login; and even 0.02 seconds makes a big difference to an offline attack, so you can make a slow hash that will be acceptably fast now and still give quiate a bit of extra security in 6 years time - but you have to be sure that people won't find a fast way of computing your slow hash).
Tom
Viewing 14 posts - 16 through 28 (of 28 total)
You must be logged in to reply to this topic. Login to reply