Strong Web Passwords

Interesting paper from HotSec ’07: “Do Strong Web Passwords Accomplish Anything?” by Dinei Florêncio, Cormac Herley, and Baris Coskun.

ABSTRACT: We find that traditional password advice given to users is somewhat dated. Strong passwords do nothing to protect online users from password stealing attacks such as phishing and keylogging, and yet they place considerable burden on users. Passwords that are too weak of course invite brute-force attacks. However, we find that relatively weak passwords, about 20 bits or so, are sufficient to make brute-force attacks on a single account unrealistic so long as a “three strikes” type rule is in place. Above that minimum it appears that increasing password strength does little to address any real threat If a larger credential space is needed it appears better to increase the strength of the user ID’s rather than the passwords. For large institutions this is just as effective in deterring bulk guessing attacks and is a great deal better for users. For small institutions there appears little reason to require strong passwords for online accounts.

Tags: , , ,

Posted on July 13, 2009 at 5:38 AM • 71 Comments

Comments

JRR • July 13, 2009 6:31 AM

I actually use acronym-based passwords, which I think are pretty strong.

The thing that I think is the most inadvertently detrimental to password strength is the requirement to change passwords every X days. If I can use the same password for a long time, I pick pretty strong passwords. If I have to change it every XX days, I tend to pick very easy to remember passwords, and just change a digit at the end of it every time. As a result of this password “enhancement” system, I think I personally have much weaker passwords.

greg • July 13, 2009 6:33 AM

How can I assume that a web password is safe?

I must assume that the web site in question deals with it safely. Which I generally cannot do. (clear txt passwords in databases anyone?)

So I have a small set of quite simple passwords (not words and with numbers) that I use on the web. Assuming the stuff on the web is more secure than that is stupid anyway….

I have yet to have an account stolen…

Phuubaar • July 13, 2009 6:41 AM

It’d be nice to know how to deal with the people whom I have personally witnessed blithely trying to log in 20 times in a row with the wrong authentication token. We tried setting up network-address-based denials after 15 consecutive authentication failures and immediately got a flurry of calls.

And this after I had to convince someone to not set eir password to “asdf123!”. “It has letters, numbers, and a punctuation mark, right?” Alas.

And of course distributing keypairs or something is completely usability-impossible.

Derob • July 13, 2009 7:02 AM

Nice paper… however I am afraid that most IT administrators will still prefer a CYA strategy and follow the current trend of seemingly strong, (i.e. long, complicated and changiing) passwords.

The beauty of this paper is in how it shows that just a bit of threat analysis may help them take better design choices, and to motivate these to their bosses.

The rule seems to be a large amount of possible (but mostly empty, secret, and difficult to guess) userid’s, an intelligent lockout strategy (which avoids locking out legitimate users), and simple passwords. At least for the big institutions. Wow, my bank seems to have got it right, and even added some limited protection against keylogging

neb • July 13, 2009 7:31 AM

I agree with Phuubaar’s comment on keypairs.

Even though public key cryptography potentially has better security features, users will mismanage their private key files even worse than passwords. Since the private key file must be carried around and requires a passphrase to protect it, users are effectively double-inconvenienced. As a result, copies of unprotected private key files end up everywhere.

Installing a ubiquitous smart-card system could help protect keys, but that opens up its own security, cost, and management issues.

Jim A • July 13, 2009 7:39 AM

I think that trying to improve the “strength” of user IDs is a result of the same sort of muddled thinking that has people trying to use an SSN as authentication protocol

Anonymous • July 13, 2009 7:41 AM

Turning the user name into a password seems like a bad idea. It is going to harder to change when needed.

The three wrong guesses and your locked out, is also a bad idea. It makes denial of service too easy. You either need to make the cost of guessing more expensive than the expected benefit or you need to have some cost effective way to handle imposters correctly guessing a password. (You might be trying to detect attackers patterns and treat sessions that appear to be attackers differently or you might have an easy way to undo things done by an attacker.)

W • July 13, 2009 8:24 AM

The problem is that implementing that 3 strike rule is problematic. If the strikes are globally limited per account it is trivial to DoS the legitimate user.
If they are per IP the password still needs to have significantly more entropy than 20 bits since there are botnets with millions of computers.
And for many larger websites the attack scenario is not an attack on a single account, but on any account. So they can attack different accounts which circumvents per account login limits.

Michael • July 13, 2009 8:43 AM

@JRR, you’ll love this one. I’ve been a TA at a university for a few semesters. As such, I have access to my students’ contact info, etc. Of course, I don’t have access to anything that’s very sensitive, such as their grades in other courses, financial aid, etc. However, the Web-based IT system that our university switched to this past year had only one classification for anyone with access to any student information: “Faculty.” There was no way to make a distinction between TAs, professors, academic advisors, bursar office employees, department secretaries, etc.

Being classified as “Faculty,” meant that I had to change my password every 30 days. Each new password had to be strong (numbers, letters, upper- and lower-case, and punctuation were all required), and had to be significantly different than my previous 10 passwords. All because I could go into the system and see that Janie Smith lived at 123 Oak Street in Smalltownville.

I’ve had jobs where I’ve had access to very sensitive data, and I’ve never seen anything like this policy. I just had to laugh at the absurdity of it.

davidwr • July 13, 2009 9:23 AM

There are lots of risks and tradeoffs here.

Are you trying to protect against a front-door login-prompt attack? 3 strikes and avoid obvious passwords.

Are you trying to protect against a stolen password table? Encrypt the table and/or its entries very well and make sure it’s immune from dictionary attacks, even with a very large dictionary and months of computer time.

Are you trying to protect against a user logging in from a compromised network? Force end-to-end strong encryption.

Are you trying to protect against a user logging in from a compromised computer or keyboard, e.g. hardware or software keylogger? Validate the computer to the server before allowing a user login, and protect the physical asset from a rogue janitor or other person who would install an unauthorized physical keylogger.

Are you trying to protect against shoulder-surfing and hidden cameras? Train employees and protect your office space from unauthorized surveillance devices.

Are you trying to protect against social engineering? Train your employees and make non-gullibility a job requirement.

Richard Wang, SophosLabs • July 13, 2009 9:28 AM

The paper indicates a number of ways in which institutions can reduce the risk of successful attacks against passwords. However, unless users are fully informed of the measures that are in place and familiar with this analysis they are in no position to determine whether a ‘strong’ or ‘weak’ password is appropriate. Therefore the general advice to use strong passwords is still relevant.
The other useful advice is “don’t use the same password everywhere”, (unlike 33% of users in a Sophos survey http://www.sophos.com/pressoffice/news/articles/2009/03/password-security.html ). A strong password cannot protect you from phishing or keylogging but using a different password at each site can minimize the impact of a password loss.

Rob • July 13, 2009 9:50 AM

@Michael:

Try this on for size:
SecureID, Change the static part of the password once a month; I don’t recall what the policy was on how many passwords it remembered, I think it was 5 or 10.

Reasonable amount of protection for the data it was dealing with. But… it didn’t stop there. It was a dedicated line with a special modem so spoofing was already impossible or would take so many resources that would cost far, far more than the data was worth

Stephen Smoogen • July 13, 2009 9:55 AM

The biggest problem I see is for the defender to select a good list of users and keeping that list secret. The defender’s site has to keep that information from being communicated to anything that can grab the info (eg if the defender has a web forum and Annie logs in as u01242ab0 and it lists it.. the attacker can increase his search space by looking at all the webforums.

Another problem is that I believe it will run against people’s wanting to choose their own unique identity. Sites that institute this will have to train their users why they can selected snoogums or billybatson etc and worry about how many people they are loosing because someone can’t be that account.

The botnet attack and third party proxy is where I see the biggest threats. The 10,000 node botnet can try a completely random attack but would more likely go for a best guessing and using the fact that only connecting 2 times and failing probably won’t trigger a response. And if it does then realizing that if customers are locked out for too long they will complain.

derek • July 13, 2009 10:12 AM

The problem with expiring accounts after a few failed login attempts is that most password-reset methods aren’t very secure, because they ask you questions that aren’t very secret.

I deal with this by choosing generated passwords as answers to the password reset questions and store them in passwordsafe, but that’s probably more trouble than most users would want to go through.

SecureID tokens could be useful for this, but of course you wouldn’t want to carry one for every website you use, and I don’t know the risks of using the same SecureID token for multiple sites.

Jim • July 13, 2009 10:17 AM

Perhaps the term ‘strong’ is unfortunate.
All passwords chosen should be ‘strong’, imo, in that, they’re not simple dictionary words, common names, or simple sequences like ‘asdf’ ‘1234’.

Or a common/simple variation like ‘passw0rd’.

You can pick a stronger, easy to use password that doesn’t meet military specs. Not every password needs to be 13 characters with a good mix of upper/lower case and numbers+symbols.

Requiring a number was never a great idea, anyways, AjfXeop is more secure than gr33tings.

Users only remember so many characters, so requiring some be from the limited set 0..9, reduces the entropy of what their selections will be.

There is some level of strength that is needed. But there is also a level of strength, beyond which is useless, or counterproductive.

Yogi • July 13, 2009 10:37 AM

If you implement a 3-strike slowdown, you solve both the DOS and brute force attacks.

I love Davidwr’s comment and would like to live in his world.

Shane • July 13, 2009 10:41 AM

What really kills me, honestly, is the idiotic schemes that require mixed case and numbers but disallow all non-alphanumeric symbols.

Oh, and the lovely schemes that require lengths of X to X+2 or something ridiculous. Sure narrows the playing field for an attacker.

I can never wrap my head around the reasoning behind these things. Makes me want to slap the developer in the face with a dueling glove.

Leftfield • July 13, 2009 10:51 AM

@Jim Today i helped user with stolen FTP ‘strong’ password and html/php injections all over the site.

‘Strong’ password is the last thing you must have. Operating system, firewall, advanced protection (server or pc) are the only way to stay secure as much as it can be.

Bryan • July 13, 2009 10:55 AM

What about passphrases? The traditional advice has been to avoid dictionary words because they’re obviously vulnerable to dictionary attacks, but that’s only an issue when your password is one or two words. Use a whole phrase and it’s another story. With over 1,000,000 words in the English language alone, a 5 word phrase has 1000000^5 = 1.0 × 10^30 enumerations. Compare that to a “secure” password that’s a random mix of at least 10 upper and lower case letters, numbers and punctuation. Even with all 94 printable ASCII characters, that’s 94^10 = 5.38615114 × 10^19. Harder to type and not even close.

Passphrases are easier to remember, more natural to type and make bruteforcing much harder.

Joe Buck • July 13, 2009 11:05 AM

Phuubaar, what is your justification for talking that user out of using asdf123! as a password?

Shane • July 13, 2009 11:15 AM

@Yogi

“If you implement a 3-strike slowdown, you solve both the DOS and brute force attacks.”

Only if the stall is based on the user account, and not the client machine / network making the attempt. Botnets are everywhere.

Frankly, I would love to see less stringent password restrictions, especially since most of the systems I’ve encountered implement terrible restrictions anyhow (terrible as in not effective, as opposed to terribly strict in the name of security) and can really piss me off when my own mental password generation scheme is disallowed (especially when it’s a great one). I say leave the restrictions a bit lax, educate the user, and let them decide for themselves.

Then again, I’m a strong follower of Darwin.

If a user picks ‘passw0rd’ for their banking account, you can bet I’d laugh out loud if they complained about their account being emptied. If the ease of log in is more important to a user than the account being compromised, they deserve what they get.

Just like the people in the city who park their car with their stereo’s faceplate in plain view and the window cracked while they go work out for two hours. I’m not crying a single tear for them, unless it’s a tear of laughter.

I think the world is getting far too pampered, and as most trust-fund babies have shown (haha, c’mon, laugh a little), pampered tends to have a direct relation to stupidity… which the world is certainly not starving for.

Some people just have to stick their hand on the hot stove for themselves, because they just don’t wanna believe it when Mom and Dad tell them it’s a bad idea, and frankly, we need those people, because they’re the ones who get the definitive answer for the next kid.

C’mon, ‘even monkeys can memorize 10 digits’. Take “TiaRSPtiE4M2R” => (title casing) ‘this is a really secure password that is easy for me to remember’. I mean, you’d have to be an idiot not to be able to quickly and accurately recall something that simple, and relevant.

And hey, if you’re an idiot, you’re an idiot. Haha, it’s only my problem when you’re in charge… which sadly, is somehow usually the case.

Shane • July 13, 2009 11:21 AM

@Leftfield

“‘Strong’ password is the last thing you must have”

Granted, strong passwords are not going to solve even all of the password-related problems, but that was about the dumbest statement I’ve seen in awhile.

Not to mention the fact that PHP/HTML injections and the stolen FTP password (no matter how strong) seems to be a combination of a network issue (sniffing, MITM?), SysAdmin issue (cleartext FTP passwords? WTF? try SFTP), and a Web Application issue (lack of input sanitation? Go back to class).

None of which a firewall or OS would have solved. And I have no idea WTF ‘advanced protection’ is supposed to mean, but it sounds like bollocks to me.

John • July 13, 2009 11:27 AM

@derek:
SecureID tokens could be useful for this, but of course you wouldn’t want to carry one for every website you use, and I don’t know the risks of using the same SecureID token for multiple sites.

The first and most obvious risk is a replay attack. Attacker sees you log onto one site you have access to, and within a minute logs onto another site where you’re using the same SecureID.

BD • July 13, 2009 11:31 AM

Strong passwords come in handy when you have a worm outbreak on your LAN. The worm we dealt with attempted to break passwords on every machine on the network. There was a strong correlation between machines used by users with weak passwords and machines that were compromised by the worm. Admittedly, we could have avoided all of this if the previous sysadmin hadn’t bypassed the firewall and plugged our server directly into the internet facing router with a public IP.

Erik • July 13, 2009 11:52 AM

Does the U.S. Sarbanes-Oxley Act mandate password strength or was that mainly something the SOX toolkits/consultancies pushed?

Joao • July 13, 2009 12:08 PM

What you need to protect yourself against phishing is intelligence (verify SSL certificates… I do it every time) and for keylogging you check where keyboard is connected to, and use a program like KeyScrambler to avoid keyloggers. Not 100% secure, but it helps a lot! … and you can use passwords that can not be easily guessed.

Glenn Maynard • July 13, 2009 12:15 PM

Delaying after failed logins is still problematic. Remember, many people out there are behind NAT or proxies; you’ll have entire organizations coming from the same IP. What happens when the workday starts, a hundred people log into your service from the same IP, and five of them mistype their password? Everyone gets delayed.

Even when none of these things happen, “three strikes” is a bad idea. If I forget which password I used on a site and I have to try five or six of them before I remember which one I used, I should not get locked out.

Google’s approach works okay for now: add a captcha after a failed login attempt per IP. That’ll work well as long as captchas work–however long that will be. (They add it after a single failure, though, which is too quickly.)

I’m not sure how they handle the race condition of two people logging in behind a proxy simultaneously, one of them making a typo and triggering a captcha, and the other user’s successful login suddenly requiring a captcha in mid-login, though.

Michael • July 13, 2009 12:17 PM

@Rob, it sounds like you were at least dealing with (somewhat) sensitive data. It definitely sounds like overkill, though, given the dedicated line.

@Chris, I’m intimately familiar with FERPA. We had training on it every semester. A couple of notes, though… First, FERPA does not specify anything about IT policy. It simply lays out disclosure requirements. An educational institution could set password expiration dates of 50 years and still be FERPA compliant. Keep in mind that FERPA was passed in 1974, long before current IT systems were even imaginable (by politicians anyways).

Second (and more importantly), with the exception of the final grade that I entered at the end of the semester, I only had access to directory information according to FERPA definitions. Institutions can publish directory information on a public web page by FERPA guidelines (assuming notification to parents and students is made). Once I entered the final grade, I had access to it for about a week or two until that class no longer appeared on my account.

So it wasn’t really so much a question of FERPA compliance as it was poor RBAC design of the system.

@Erik, I do not believe SOX mandates anything regarding password strength.

Wade • July 13, 2009 12:20 PM

Michael touched on what I think is the major problem with password strength requirements: the “one size fits all” attitude.

I have accounts on some web sites merely so my comments can have a name attached to them (aside: The fact that this site allows me to specify my name without creating an account is a rare and brilliant bit of usability). For those sites, I really do not care even the slightest if someone “hacks” my account and posts with my name. For other sites where I’m a bit more active and there is the notion of private messages (such as the social networking ones), I care a small amount about the security of my account, but not much: it would be an irritation if someone hacked my account, but nothing serious. For my bank and stock portfolio sites, I care deeply about the security of my account, and it would be a major financial problem for me if someone hacks those accounts.

The problem is, site administrators typically see “password” and apply the strong password rules to them, forcing me to create a large number of impossible-to-remember passwords. I want a way for me to say “I don’t care about the security of this account, so let me use my userid or a blank string as my password”

Cerebus • July 13, 2009 12:27 PM

The paper explicitly presumes that an offline attack against the password using collected authentication protocol messages isn’t possible, which we should all already know from practice is generally false.

— C

Phuubaar • July 13, 2009 1:43 PM

@Joe Buck

Mainly that it hasn’t nearly enough entropy based on my estimate of a model for how people choose passwords. “asdf123!” consists of three highly predictable components. They are also in a predictable order, since it is very common to pick alphabetics first, then numerics, then punctuation.

Another, related reason was extreme ease of shoulder-surfing, from a combination of the sequence and how distinctly this user typed each character. This was how I found out what eir password was in the first place, in fact.

Why does the entropy matter in this case? Mainly dictionary-style attacks, either carried out en masse or on a specific user.

Why can’t we prevent that some other way? There were only a few ways that had obvious implementations available. The access is SSH-based. Blocking a network host after 15 consecutive authentication failures was the first try, and it failed hard: people would enter the same incorrect password 20 times in a row in quick succession, entirely blinded by their expectations to the content of any error messages. The latter was inferred based on both observation and log data. Locking accounts would have had similar problems and made it easy for any user to DoS another.

Timing-based approaches might be better. This is on the list of things to research, but it hasn’t made it to the top yet; from initial feasibility examination it looked nontrivial to implement. Other forms of obscurity are also being considered, such as changing SSH ports, but our userbase is not expected to be technical and the slightest whiff of anything nonstandard (especially when it wasn’t there before) has potential for serious usability problems.

In the absence of a good mitigation for dictionary attacks, users picking passwords with reasonable amounts of entropy is essential.

So why hasn’t the specific issue made it to the top of the list yet? Because there are other things to do first (including other security issues to handle), and our system administration base consists of volunteers. Most of the rest have a basic grasp of things, but find sysadmin stuff distasteful enough on average that they will expend minimal energy on anything that doesn’t need to be handled immediately, or so I am told. Then there’s myself, who both cares about it and enjoys doing it but still has limited throughput for actually improving things.

Welcome to the world of the future!

AppSec • July 13, 2009 1:50 PM

@idan:
While your theory is interesting and has some basis, there are somethigns to consider:

The dictionary of one individual will be greatly different then another due to their interests, occupation, and motivation.

A sequence of X characters will be no more random then the phrase of words.

I would also hope that the passphrase requirement wouldn’t be using an english dictionary to validate my phrase, as I might want to put my own little twist on it.

Shane • July 13, 2009 2:11 PM

@idan

Not to mention there isn’t exactly a tumbler to listen for with your stethoscope in these cases.

Perhaps an acronym’d sentence with mixed case contains a small amount of entropy when taken in the context of it being comprised of English words, but you aren’t given a ‘yay’ or ‘nay’ for each letter while attempting to crack it.

A dictionary attack works well because it is effectively an educated guess at commonly used words, phrases, and arrangements thereof. Being that there is an incredible number of combinations of English words that comprise memorable sentences, both in length and content, and including things like proper names or slang, I’d be hard pressed to believe that extensive knowledge of word and letter distributions significantly weaken this type of approach.

Although I wasn’t 100% clear at first glance whether or not you were discussing the acronym approach or fully written phrases / sentences. If it was the latter, my apologies, but that shouldn’t be news to anyone here, albeit interesting stats on word distributions.

Shane • July 13, 2009 2:27 PM

@Glenn

“What happens when […] a hundred people log into your service from the same IP, and five of them mistype their password? Everyone gets delayed.”

That’s just a poorly implemented scheme. It should never be based on IP, no authentication should use an IP address as any form of unique identifier. This is just common knowledge. If one user from that pool types their password incorrectly the specified number of times, that user’s account should be ‘frozen’ for a set (but short) amount of time, no matter where additional requests are coming from.

“If I forget which password I used on a site and I have to try five or six of them before I remember which one I used, I should not get locked out.”

The ‘three strikes’ issue, generally speaking and correctly implemented, is simply put in place to attempt to hinder online brute-force attacks. It should never ‘lock you out’ completely, unless it’s doing so to prevent a denial-of-service for the entire system (by denying one person service, to keep the system online), rather it should simply create a livable delay (say, three seconds for three strikes) that makes a remote brute force attack completely implausible with current technology.

No scheme is perfect, but these arguments sound a bit stretched. I do agree that Google’s captcha seems to be relatively effective, but IMHO still a lot more inconvenient than waiting 1-3 seconds for another login attempt. That is, of course, until Google’s captcha is broken, which isn’t far off, especially considering nearly every other captcha out there already has been. I wouldn’t bank on theirs for too much longer.

lyalc • July 13, 2009 4:02 PM

This is news?
Come on -this has been common knowledge as a self-evident fact for the 3 decades I’ve been working in the security industry.

Peter • July 13, 2009 8:03 PM

@lyalc

“This is news?
Come on -this has been common knowledge as a self-evident fact for the 3 decades I’ve been working in the security industry.”

The analysis in the paper applies to web passwords only. What browser were you using in 1979?

laki • July 13, 2009 9:48 PM

First of all, I just want to state that I read the entire paper as the abstract really doesn’t do it justice 😉

I agree that keeping the userid secret does add security. That’s the reason why it’s an industry standard to display a generic “incorrect userid and/or password” error message instead of having a seperate error message for each case. I disagree with the authors though on the amount of security it provides.

As stated earlier in the comments
1) Users like to pick their own userids and share them between sites
2) For many non-banking sites harvesting the userids is trivial. Aka my userid on many sites is “laki” belive it or not, (though not on my bank account)
3) Having a hard to remember userid is just as bad, (if not worse), as having a strong password creation policy. I still have to look up my userid for some sites.

On a different note, their characterization of password entropy is wildly off. A six digit pin doesn’t provide much security since an attacker will try common combos such as “123456”, or dates such as “070897”. This extends to regular dictionary based passwords, as can be seen by the real life examples of “brute force” (really dictionary) attacks against ssh servers http://www.securityfocus.com/infocus/1903

bonelyfish • July 13, 2009 9:53 PM

To be secure, one must use a password so strong that after pressing the change button the person will instantly forget.

We have to keep so many accounts and change every several weeks with a strong and non-repeative passwords, it is difficult even if written on paper least to say keeping all in the brain.

Sometimes I think that these security measures are so impossible to execute that they only want to shift the blame and say “I told you so” when something really happens.

Ed • July 14, 2009 4:32 AM

Can someone help me out with the analysis of passwords/passphrases.

I see two attack scenarios, a) the attacker doesn’t know anything about the characteristics of the password, length, character set, nothing; b) the attacker knows that it is a password or pass phrase.

In scenario a) it seems to me that length and character sets are everything. i.e. “lEt me 1n” is as easy or difficult to crack as “letMeex1t”.

The two cited articles discussing passphrases from hitachi and baekdal.com seem to base their analysis on the assumption that the attacker “knows” that a passphrase is being used, i.e. scenario b). In this case the password is already partly compromised.

It seems to me the ‘normal’ scenario is a) and that a carefully chosen passphrase, perhaps with uncommon words is easier to remember than a similar length random string and is just as strong. An acronym based approach just gives a more memorable way to generate a random password but is no stronger unless it is longer.

Michael Seese • July 14, 2009 4:57 AM

The blurb says that a weak password is OK if there is a “three strikes” rule. I thought the logic behind strong passwords (and changing them) was that if an attacker were to get his hands on the password file, and work at cracking it offline, a strong password would take longer to break than its expiration period.

AppSec • July 14, 2009 5:40 AM

@Michael:
I think that’s one of the assumptions that was invalid in the paper was the attacks and type of attacks were specific to on-line brute force. I.E.: There’s no way for the password file to be compromised and the attacker has no one id it is trying to attack.

In this specific case it is right.

@Shane
Using IP address as a partial piece of information to protect a user can be very useful, especially in using GEOLocation of the user. What are the odds of a user logging in from Texas and then an hour later logging in from Alaska?
VPN Proxy Routing? Possibly. But if the user is gettting their password wrong multiple times from that new IP address, I doubt it.

Sherwood Botsford • July 14, 2009 8:30 AM

All of my online bank accounts ask me for my card number as user ID, not my name. This is a 16 digit number. This makes for a sparse name space. I would expect that someone mis-typing their card number would have a bunch of digits that were right, and a few that were wrong. Repeated attempts should cluster. Even a large network behind a NAT firewall in unlikely to have more than a few dozen people attempting to log in to a given server at any one time. Spotting repeated attempts compared to spotting a brute force attack should be fairly easy.

In general I break down my online access into three categories:
* The many forums were I have a membership. The incentive for someone to break my account is small.

  • Online shops wehre I use my VISA card. The credit card companies sit up and take notice when the requested delivery address is different from the billing address. While credit card fraud is a risk, there are many ways to get visa numbers.
  • Banks.
    Here the large name space of the user ID combined with the password requirements, combined with using a non-windows based OS make me reasonably comfortable with the risk.

How hard would it be to embed a secureID into a bank client ID card. It wouldn’t even have to be the change every minute approach. Suppose that it effectively generated one time passwords. At any given time the display on the card lists a 4 character word, and a password. You sign in to the bank, it shows a set of 4 character words. You find the word that matches your card. You type in the password, and click on the word on the screen.

  1. Replay attacks don’t work. It’s a one time password.
  2. Keylogging doesn’t work. The only thing you typed is the password which is use once only.
  3. By presenting a set of words, you have the flexibility to have one account that can be accessed by multiple client cards. You also no longer have to have such strict time keeping between the client card and the server. The client card needs to have a button that says, “I’ve used this one now, make me a new one.”
  4. The set of words also takes care of accidental “create me a new password”

Sherwood Botsford
Sherwood’s Forests Tree Farm
“Trees for Rural Living”
http://sherwoods-forests.com
sfinfo@sherwoods-forests.com
50042 Range Road 31, Warburg, AB
(780) 848 2548

Matt • July 14, 2009 10:25 AM

I also disagree with the article’s conclusions.

I. Assumptions made in web services. Florencio’s paper says that semi-weak passwords satisfy brute force prevention in systems that have a three-strikes rule. The problem is that 95% of web services do not or will not have such prevention, if they have any prevention all. This is particularly important in the upcoming LAMP boom as many novice web programmers will either use pre-made login schemes that may not employ cracking prevention, or will use no prevention at all.

II. Burden on users. The burden on users seems to be the main thrust of his argument. However, they suggest that increasing the size and/or complexity of the username in addition to the password would be a better practice for prevention against bulk attacks. As someone who has roughly two dozen web services with logins and passwords, I think the burden of tracking usernames is just as strong as, if not stronger than, tracking passwords.

III. The three-strikes rule. The three-strikes rule is a bit short on info. If you require a three strikes rule on a single account, you run the risk of DoS attacks. The better solution is to require three strikes (or whatever rule you choose) on a single account from a single location (IP). However, you then increase the number of attacks possible on that account, assuming the attack can be coordinated (which is easily done by viruses). So having a weak password under this latter scenario is risky.

Overall:

One shouldn’t throw out good advice on brute force prevention just because it doesn’t help against phishing or keylogging, because it arguably places extra burden on users, or because in a well secured system it doesn’t provide extra protection. I think his near-condemning of strong passwords as a burden on users is a risky critique, and as both a web developer and system administrator I do not agree with his view.

That being said, I concur with one of the comments posted, that acronym passwords with some sort of consistent morphing formula (like all consonants are capitalized and all punctuation included) provide the best security, do not require ultra-long passwords, and are easy for users to utilize. Password rotation is still recommended. As for losing passwords, my recommendation is to store the “naked” phrase that is applied to the acronym algorithm on an encrypted storage device. Even then I would not include the algorithm with those phrases. Most people choose the same acronym algorithm for all phrases, so this should not be a burden.

p.s.
The best advice I can give about phishing prevention is to treat your passwords like your Social Security Number. Only the most trusted recipients get to process it.

$0.02

kingthorin • July 14, 2009 12:12 PM

“However, we find that relatively weak passwords, about 20 bits or so, are sufficient to make brute-force attacks on a single account unrealistic so long as a “three strikes” type rule is in place.”

Hmmm 20bits … so like 2 or ummmm if we round up 3 characters? Huh?

Shane • July 14, 2009 2:45 PM

@AppSec

“Using IP address as a partial piece of information to protect a user can be very useful”

I absolutely agree, hence my saying it should never be used as a unique identifier, rather than it never being used at all 😉

Just like someone’s User Agent string. It’s a very useful bit of information to attach to any authentication scheme, especially if multiple login sessions are allowed, but should never be relied upon as a unique identifier, just like an IP address.

“What are the odds of a user logging in from Texas and then an hour later logging in from Alaska?”

Granted, VPN proxies, crazy routes, and/or TOR networks are generally very rare cases when taken on the whole, but they *have to be taken into account, which is why, again, I say an IP address is a great piece of metadata to attach to a user’s login attempts, but it can never be relied upon as unique, even if it isn’t in only one of a thousand cases.

It really sucks, but that’s generally the sad fact of most computer security concerns… that ridiculous 1 in a million margin of something happening that doesn’t fit nicely into a simple set of rules. That’s why I love W3C and hate Micro$oft. The former loves standards, the latter likes to pee on them.

Standards make our lives so much easier, but what can you do? Computing is still stuck in the Dark Ages, frankly. We’re still using the King’s arm as a measuring tool.

A little rant there, but hey, that’s how I roll, haha.

Charles Andres • July 14, 2009 3:00 PM

From the paper: “We conclude that forcing users to choose strong passwords appears misguided: this offers no defence against the common password stealing attacks and there are better means to address bulk guessing attacks.”

We need a replacement for passwords on the Internet. OpenID is good for low security applications (like a blog comment). InfoCards are good for high security (like financial transactions). Now we just need sites to adopt these measures.

Rob • July 14, 2009 3:20 PM

@kingthorn: “Hmmm 20bits … so like 2 or ummmm if we round up 3 characters? Huh?”

No, 20 bits of entropy, not 20 bits in length. IIRC, there’s about a half bit per english character, so you’d need a 40 character passphrase.

laki • July 15, 2009 6:23 AM

@Rob @ kingthorm, no the paper is talking about a 20 bit search space. From the paper…

“a 6 digit PIN is approximately 20 bits if all digits are equally likely”

laki • July 15, 2009 6:30 AM

@kingthorm sorry, actually you’re close since a password containing upper/lower/digits and a 20 bit search space would fall between 3 or 4 characters long. aka 64^3 = 262,144 and 64^4 = 16 million

kingthorin • July 15, 2009 6:52 AM

Sadly I didn’t have time to read the paper/article the post was based on and took the quote quite literally.

Pier-Olivier • July 15, 2009 7:06 AM

It kinda reminds me of my teacher in my security class who refused to give me all the points on the description of what is a strong password because I didn’t wanna write that it had to be easy to remember. I don’t have any strong password easy to remember and they work just fine, they’re not less strong by the fact I have a good memory and many people don’t … although I understand the point that it is more practical, but in no way a fundamental criteria to consider a password “strong”.

over all I would prefer to be able to use some kind of very strong key encryption tied t o a security key like the one they have on paypal coupled with a strong password so that I can start a browsing session with it and all my website would automatically get their password entered. Come on people we’re in 2009 :/

KaiJen • July 15, 2009 1:57 PM

In my opinion one very important attack has so far been neglected. Especially for web applications I consider it to be important to not choose the same password for two different accounts. One can never been sure which credentials become compromised. One sleeps much better if only one account is affected.
I personally like PwdHash to help me with using different passwords for different web sites. And as a side effect, these passwords are usually less guessable than most of the ones a person can easily remember.

Lee Haywood • July 16, 2009 3:22 AM

I use key-strengthened hashes to make sure that a brute-force attack takes an unreasonable amount of time. If it takes 1 second for a client/browser to generate the hash, that’s fine but for an attacker 1 second to try each password is a formidable obstacle.

Richard Booth • July 16, 2009 5:03 AM

In my opinion, the use of any form of credential based authentication on the web is going to be somewhat limited given the increasing use of Man-in-the-Browser attacks. These real-time, scripted, evolutions of the classic Man-in-the-middle attacks have become so sophisticated that some people are of the opinion that any web authentication is useless against a determined attacker.

So then we get into a discussion on risk. I do not belive there is a correct or incorrect level of “strength” associated with a web based authentication method. What it ultimately comes down to is implementing an authentication control that is proportionate to the level of risk associated with a breach. Risk based authentication is widely used in the banking world where it is more than just the credential that lets you access your resources.

The one challenge with risk is that it relies on somebody’s perception or opinion. The risk that I associate with certain data types being compromised will differ greatly from the level of risk percieved by others looking at the same data.

In addition to risk, there is the question of context. Should a breach occur and some data be compromised, the context in which the data is seen creates additional variables in the percieved risk levels.

For example, take an eCommerce merchant using a supplier portal protected only with username and password. Now imagine that through an error (human or technical) a vulnerabilty existed whereby a supplier had access to a record of credit card data. If that supplier’s username and password was compromised through a low tech attack like a key logger or phishing attack, the risk associated on tha breach depends on a number of additional variables.

1) Who is the attacker? Some kid in his bedroom hardly poses a large risk to the credit card accounts of the eCommerce customers. If the attacker was a highly skilled fraudster, then the risk is increased significantly. But since the attacker’s profile is largly unkown the risk is difficult to pinpoint (plan for the worst and hope for the best?)

2) How bad is the breach? If all the attacker got access to through a username and password was the credit card numbers then the risk is again somewhat limited. If the data included not only credit card numbers, but also expirey date, CVV2, and maybe the cardholder’s date of birth and mother’s maiden name, then a potentially very high risk exists.

the list goes on…

There is no magic solution and no silver bullet, the best we can hope for is that the authentication method used (credential, risk based, knowledge based etc.) is appropriate to the risk and the context while still being friendly enough to be used by the relevant audience. I dont see an OAP using key-strengthened hashes to access their pension data?

Metaphoraclese • July 16, 2009 3:07 PM

@Richard

Well, if you want to get into all that…

Show me any browser-based authentication scheme that is 100% immune to replay attacks without altering the HTTP spec, and you’ll probably be famous for it.

The sad fact is that the web browser is a rickity ole horse drawn wagon, pulled by a real old mare named HTTP, and all the bells, whistles, brass, and additional gunmen in the world aren’t going to make it immune from the bandits who really want to rob it.

“Prepare for the worst, hope for the best” is about the best any of us can do.

The internet is a brand new baby in a dark dark world, and that baby has gotten a lot of candy for it’s last few birthdays, making it a real easy target for anyone with a sweet tooth. Most of these methodologies we’ve all adopted have been effective at nothing more than delaying the inevitable down to a livable threat, but pretty soon this baby has to start growing up and learning how to defend itself properly. Us comp.sci/sec kids are kind of starting to look like the TSA at this point, asking everyone to take off their shoes while the cockpit doors are still made of cardboard* 🙁

*Not generally true anymore, but for the sake of my argument…

Lee Haywood • July 17, 2009 7:51 AM

The ideas behind Digest Access Authentication (RFC2617) are largely immune to man-in-the middle attacks, although the scheme itself is very much outdated and has to be re-implemented with SHA-1 and key strengthening, etc. (which I’ve done in JavaScript).

Its main weakness is not providing a secure way to set a password in the first place, but once done you can use salted hashes in a challenge-response scheme that prevents both replay and man-in-the-middle attacks. That is, provided that the key continually updates at both ends for every request and is never reused.

MJMcEvoy • July 19, 2009 7:41 AM

One thing that the article and others missed, or I didn’t catch, is what I ran into with my bank.
The bank’s online system suggests a strong password using any keyboard character, of upto 15 characters. But they don’t require it. So when I generated a random 15 character password and entered it on their setup page, the password was accepted. But when I went to log in, not all the keyboard characters were displayed on the special web-based keypad that was required to enter the password. Nice try, but I haven’t been able to access my account on-line for 3 weeks now while I wait for the banks Help Desk to reset my account info.

rkddudgns • July 24, 2009 1:34 PM

I just got a random combination of letters from a random letter generating site or thing, then I memorize the random combination.

I think it is quite foolproo because it doesn’t resemble a word, acronym, and isn’t even pronouncible.

Mike • July 24, 2009 1:43 PM

I tend to like the “Forgot my Password” option. I let the website email me a password everytime I go to it and change it to something completely random. No need to remember.

Clive Robinson • July 25, 2009 4:09 PM

@ rkddudgns,

“I think it is quite foolproo because it doesn’t resemble a word, acronym, and isn’t even pronouncible.”

Sometimes the human brain can make sense of nonsense,

r, Realy
k, Kool
d, Dude
d, Does
u, Under
d, De
g, Ground
n, Nonsense
s, Sentances

8)

Neil Bruce • November 15, 2009 11:28 PM

Take a word or words you can remember. Encrypt it–I won’t tell you mine, but for example, take a key 2 to the right (if the letter is p use ]). Write down your encryption formula. Relax.

Alexandre Terrat • December 4, 2013 1:01 PM

Hello , I memorize sequences of hexadecimal 20 to 30 by including simple Latin phrases with a first password. Then to generate multiple passwords I simply reverse the first four numbers with the last four can not format my brain -. Never passwords saved on your computer – Or kill me …

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.