Several high profile Twitter accounts were recently hijacked:
This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2009/01/dictionary-attacks-101.html
This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2009/01/dictionary-attacks-101.html
All of you hip surfers out there, there’s a common p455w0rd list out there too, which can be made by simply substituting the leet alphabets with the corresponding l33t digits.
It’s done wayyyyy back in those days of the Pentium, so ‘p455w0rd1’ isn’t really much safer than ‘password1’.
Use a book and keep a paper. One folded paper where all your web passwords - NOT BANK PASSWORDS - are written neatly.
And keep that password paper behind your spouse’s photograph in your wallet/purse. Treat it like your Passport - priority item.
Here’s the table template:
(Ctrl+P for print)
|
I think delaying response is a bad approach. Why not just use an expirable lock-out with growing expiration intervals instead? If a user genuinely tries 4 passwords (i do that often when i don’t remember) he’ll have a response time of 8 seconds? Why not just tell the user he’ll only be able to attempt another login in 8 seconds instead?
oh, that’s wicked - I typed it into the addressbar directly to make sure it wasn’t a JS trick or something; just wow…
OpenId is a great solution, however it’s only supported by a handful of the (probably) thousands of sites I’ve registered at throughout the years.
By registering at a site we place some trust in them (kind of like can you hold on to my wallet while I tie my shoelaces.) Unfortunately they keep our wallet forever.
I know it would be smart to create a 32 character completely random password for every login, but how the hell would I be able to remember 32*1000 passwords? I would probably have to write it down. I could use a piece of paper for that, but that’s obviously unsafe. I could store them on a keychain, but then I will have ONE password protecting all my information.
Gosh, that’s not a good solution.
Or a hacker could stand behind the highest ranking google officer when he types in the password for the ace account.
The point I’m trying to make is that whatever protection one human comes up with, a hacker human can get around.
It’s of course no excuse for weak passwords and servers with weak protection.
Delay a login attempt response means use more server resources
No, you just return immediately and let the user know (via javascript countdown) how long until they can try again. This is all tracked on the server, obviously.
If you think well I’ll just get multiple openid accounts then you’re back to the same problem of having a bunch of name/password combos to have to remember
So the answer is either one or infinity? I smell a logical fallacy. How many forms of ID do you have in your wallet right now? If it’s more than one, the world has failed you! Reality: multiple forms of ID is fine, as long as it’s a smallish number. They really do serve different purposes, exactly like what’s in your wallet (or purse) right now.
This is part of the reason I’ve switch to fingerprint readers on my computers.
http://www.dansdata.com/uareu.htm
many sites I visit specifically tell me that my password MUST be alphanumeric.
This is the great advantage of OpenID: you outsource your username/password to a company that ISN’T retarded. There are providers which offer two-factor auth, even!
I have used delays in the response period, but it was always geometric, not exponential. Just delay=attempts*seconds. And because I was using the ASP sessions to track attempts, they had to time out their session to reset the count. If they weren’t handing me back the unique session cookie I set on the login page then I wouldn’t validate it at all.
I agree that delays breed DoS attacks and using up resources. It also assumes that the user is using the same session to track the attempts.
One method that I have used in the past is to have the script that builds the login page randomize the input variable names for the login and password and store them in the session info. Then I use that to pick them up again. It’s much harder to make the password guessing program if it has to get the login page, parse it for two variable fields, then apply the guesses against the randomized variable names when resubmitting.
Another idea is to use the users own login id as the salt to the hash for the password. That eliminates rainbow attacks, even ones customized to your site.
I also don’t limit the length or characters used in a password. The only thing that goes in the database is the hash, so I don’t have to worry about length or character limits.
I concur with not giving admin access through the main website. We have used a separate url with additional firewall source requirements. That’s key.
But, keep in mind that no matter how tightly you lock the front door, one of two things can still happen: Someone will ultimately break it down or someone will sneak in the back door. Most data losses either happen outside the system (unsecured ftp transmission of database backups?) or from someone internal to the system. We can’t prevent it 100%. It’s more like The Club. Not perfect, but good enough to make someone keep moving to the next target.
For my bank, it always warns me that my account gets blocked etc. if I get the password wrong 3 times. This made me chuckle, because I always use the wrong user name with the right password.
And because I was using the ASP sessions to track attempts, they had to time out their session to reset the count. If they weren’t handing me back the unique session cookie I set on the login page then I wouldn’t validate it at all.
This just requires a call to load the cookies from the login page, then pass that to the form; minor inconvenience.
Then I use that to pick them up again. It’s much harder to make the password guessing program if it has to get the login page, parse it for two variable fields, then apply the guesses against the randomized variable names when resubmitting.
Look for the login form, then assume that the first input that’s displayable is username and the second one the password (or template it based on the adjacent html). Minor inconvenience.
Now consider ip-blocking after 3 login attempts - sucks for AOL, but you only get to spam the login 3 times per box you control. The refinement here is to use a botnet and spam slowly and across a large set of usernames. Best defense there (I think) is to track auth failure percentages by IP and when they hit 20% over some time period, put them on the always fail list.
Oh yeah, and just today we saw a teacher at school type her password right after her username. She tried to logon into the medical records system (I study medicine) to show some X rays of a patient.
Approximately 300 students have seen her username and password.
And yes, it ended with the number 1.
Too bad I’ve forgotten the rest already…
Yes, there’s many many problems that are possible with login throttling.
However, in the case of an administrator account, a little bit of agressive throttling is perfectly ok, because its a slightly important account. They can avoid the denial of service issue by throttling attempts from outside the office much more aggressively than they throttle attempts from inside the office.
For particularly serious attacks, there’s always SSH’ing into the actual server to do the administration stuff.
Also, the admin’s doing admin stuff account should be seprate from their doing normal user stuff account. So even if you can post ‘I’m a dumbass’ over and over using the admin’s account, you should have a higher bar to pass before getting unlimited access to the user database. Such as, for example, a properly set up SSH connection, so you need private keys as well as passwords. And, hey, a 1024 bit private key is a little bit harder to guess than a 40 character strong password.
I have heard of a couple of people having their hotmail accounts hacked, then being sent emails to their work email account asking for payment to get their hotmail email account back. This is happening all the time.
Personally I’ve been a fan of Bruce Schneier since reading his Applied Cryptography book back in 1999. It still has pride of place on my book shelf and I consider it a minimum read for anyone trying to secure anything. Even if the encryption standards have moved on, the processes, protocols, and hack methods all remain the valid.
BUT - my main reason for posting is that passwords don’t work. I don’t like them and I don’t want them - heck I can’t even remember them. Sometimes I find myself saying what was the birth date of my… no… it was the maiden name of my… uhhhh… or was it my first dogs name… no… the first street I lived on… ahh I didn’t really want to get into that site anyway.
Passwords can be cracked/hacked/gained through brute force or social engineering. Heck - most of the users in the work place seem very happy to give their user name and password to other users, even though it is the same password they use for their personal web logins. I don’t like biometrics either. If someone is able to duplicate a biometric then you are royally stuffed (what are you going to do – cut yourself a new finger print or get some plastic surgery???). Biometrics signatures can be stolen “in the pipes” and if that happens the hacker doesn’t need your biometric – they have the signature of your biometric and that’s all they need.
Why the heck aren’t we using digital card logins – the ones that have the numbers that change with time? The technology has been around for a decade and is now standard for bank web page logins. An admin login for a high profile web site should be secured to this level.
Why the heck aren’t we using digital card logins – the ones that have the numbers that change with time? The technology has been around for a decade and is now standard for bank web page logins. An admin login for a high profile web site should be secured to this level.
this might be enough to make me use an openID like thing - sign up for an account, get your RSA token, and sign into random_web_site with a username/token value. If the site steals it, so what? it’s good for a minute only, and if someone hacks my account, they don’t really have access to all my sites - i still have the key. I still need to trust the authentication agent, as they could go poof and then I’d be boned.
Why the heck aren’t we using digital card logins – the ones that have the numbers that change with time? The technology has been around for a decade and is now standard for bank web page logins. An admin login for a high profile web site should be secured to this level.
Verisign offers this feature for OpenID.
Meaning, you could sign into any OpenID supporting website with two-factor auth.
Delay a login attempt response means use more server resources
No, you just return immediately and let the user know (via javascript countdown) how long until they can try again. This is all tracked on the server, obviously.
Tracking it on the server means more server resources. Durr
The other thing to protect against is attacks where the username changes for each attempt. (For example, if you don’t care which account you get into, try several different usernames with password as the password. This is very common against SSH servers, but could also happen against a web site such as eBay or a bank.)
This is harder, because you have to limit based on source IP address, which means someone could forge the source IP and deny service to legitimate users.
Jeff -
You’ve got some sort of bug in your counting of English words in the OED. The first edition, published in 1928 defined 414285 words. The 1989 edition defined about 615000 words. There may be more.
I still need to trust the authentication agent, as they could go poof and then I’d be boned.
Good point. Bruce Schneier points out that both parties - in this case the one logging in and the web site - have to equally trust the third party authenticator more than they trust eachother.
So if you don’t trust the authenticator either… like you said, you are boned.