42

Let's say I'm setting up a new account on a website. Should I bother using a strong password? My reasoning is this:

Password strength is a rough measure of how long it would take to brute-force my password from a hash. Brute-forcing even a 'weak' password is difficult via the authentication endpoint for the website - it's too slow, and limitations on the number of incorrect password attempts are commonplace. Brute-forcing even 'strong' passwords is becoming trivial when you have the password hash, and this situation will only get worse. In the situation that password hashes are leaked from a website, passwords are reset anyway.

It seems to me that there's no difference between using the password fredleyyyy or 7p27mXSo4%TIMZonmAJIVaFvr5wW0%mV4KK1p6Gh at the end of the day.

fredley
  • 1,455
  • 1
  • 16
  • 25
  • 7
    What's the point, really ? If you're sensible, you'll use a password manager and then using a strong password on a new web site becomes irrelevant. – Stephane Sep 10 '13 at 12:03
  • 3
    If it can be brute-forced/guessed, then by definition it wasn't a strong password. – CodesInChaos Sep 10 '13 at 12:43
  • 2
    The point of the Arstechnica article is that now passphrases (like in XKCD #936) are now (more easily) crackable using the tool, not that (pseudo) random passwords of the same length are as easy to crack. – Peanut Sep 10 '13 at 12:54
  • 1
    @eklam This question is not about the relative strength of different passwords, but whether strength is even a desirable quality of a password. – fredley Sep 10 '13 at 13:22
  • What I would like to know is: What is the relation between cracked and leaked/stolen/phished passwords. If cracking is a rare strategy to pirate an account, then password strength beyond a basic difficulty is largely irrelevant. –  Sep 10 '13 at 13:27
  • @what My point exactly. If there's a password leak my password is reset anyway, so besides using unique passwords for each service, is there any point in using strong passwords? – fredley Sep 10 '13 at 13:29
  • 9
    @Peanut: xkcd #936 is *not* recommending passphrases of the sort that the Ars Technica article describes: the Ars Technica article describes cracking passwords that are, verbatim, phrases that exist in corpora such as Wikipedia. xkcd #936 suggests choosing several random unrelated words. (The latter will eventually become crackable, too, but that's not what the Ars Technica article is about.) – ruakh Sep 10 '13 at 14:47
  • @ruakh True! I misspoke. I've seen similar articles on Ars however talking about how Hashcat can concatenate dictionary words to try and crack passwords. – Peanut Sep 10 '13 at 16:01
  • @JeffFerland, Xander, Scott: wuh? the proposed duplicate has nothing to do with this question. One is about how much entropy a type of password has, the other is about how much entropy to aim for. – Gilles 'SO- stop being evil' Sep 10 '13 at 18:12
  • @fredley by 'password hash' are you referring to the IV? Or are you referring to a secure hashing algorithm? – Dan Esparza Sep 10 '13 at 19:40
  • @Stephane - password managers are not an option for a large class of situations, and in those situations it's especially tempting to become complacent for the sake of convenience. – detly Sep 11 '13 at 00:42
  • @detly I'm afraid I don't know what you're referring to. – Stephane Sep 11 '13 at 07:01
  • @Stephane - any situation where you're legally required not to write down or otherwise store a password. Some employment contracts have such clauses, especially where there are export control or ITAF concerns; there could be plenty of others. So memory is the only option. But, you don't want to be calling IT every week because you can't reliably memorise a bunch of strings of random digits, so if a bunch of people on a Q&A site tell you that a short simple password is as good as a long complex one, problem solved ;) – detly Sep 11 '13 at 07:14
  • You're completely right! Everybody should enter `1234` or `password` as their password! It only takes a hacker to enter `password` in the login box for everybody and you know no hacker would do that... – noɥʇʎԀʎzɐɹƆ Jul 02 '16 at 01:04

10 Answers10

80

Brute-forcing even 'strong' passwords is becoming trivial when you have the password hash, and this situation will only get worse.

This is not true. A highly random password is near impossible to bruteforce given that the web application in question is using a strong hashing algorithm like bcrypt or pbkdf2. On the other hand, weak passwords are laughably easy to bruteforce even if a strong hashing algorithm is used.

So yes, there is merit to using a strong password.

  • 28
    I think the most important point to make is that it should be unique, so that even if the password is compromised, it only compromises that single account. – Polynomial Sep 10 '13 at 09:39
  • 1
    Absolutely agree with @Polynomial about the value of password uniqueness. Also, passwords for any accounts that allow password recovery or change for other accounts (such as the password for your main e-mail account) should be stronger, since if that service is penetrated it can be used as a springboard for further attacks against other services. – user Sep 10 '13 at 12:22
  • 4
    While there is merit to using a strong password, the OP is asking what is the EFFECTIVE difference of using a weak password versus a strong password. As in, are people who use weak passwords 300% more likely to have their account hacked, or is there only a 1% greater likelihood of being hacked? – TruthOf42 Sep 10 '13 at 13:44
  • wouldn't scrypt be better then bcrypt as it takes longer to hash and so less easy to bruteforce –  Sep 10 '13 at 14:17
  • 2
    Not just *near* impossible. A password with sufficient entropy (not necessarily length) *can't* be broken by brute force, because increasing the entropy increases the difficulty of cracking exponentially, and there's only so much energy in the universe. – Brendan Long Sep 10 '13 at 20:05
  • 2
    @BrendanLong That's only in the *worst* case, when you have to search all/near all the "password universe". You can always be "lucky" and obtain the correct password in the "first guesses". Surely, on average only 1 crack every `10^ - (big_number)` will take a feasible time to finish, but it's still a possibility. – Bakuriu Sep 10 '13 at 20:19
  • @Bakuriu No, it's not a possibility. The probability is so low that the chance of you "getting lucky" and brute-forcing that 100+ bits of entropy password is **zero**. Period. At such small scales, probability ceases to be meaningful, and using the "mathematically the probability is not zero" argument is simply not reasonable (and that is without even considering that the "probability" of your brute forcing program failing due to a hardware error and reporting a false positive is unimaginably larger than the probability of it succeeding in a "feasible time"). – Thomas Sep 11 '13 at 07:35
  • 1
    @Thomas I don't agree. The definition *I* use are: impossible event is something that *cannot* happen, due to some "law"; i.e. there *isn't* a sequence of events in the universe of events that produces that result. This is *strictly stronger* than saying that it has probability `0`, since events with probability `0` *can* happen. Given a random product(of random number of random numbers) of positive integers, obtaining a result of `-1` is *impossible*, while getting a result of `2` has probability `0` but *is* possible. Probability != possibility. – Bakuriu Sep 11 '13 at 08:06
  • I consider possible even an event that would take `G -> G -> G -> G -> G -> G ->G` lives of the universe to happen on average(that's conway's chained arrow notation and `G` is graham number). The fact that nobody will ever see that happen doesn't change the fact that the event is possible. My remark was "philosophical" not practical, i.e. I am **not** saying that people should just try brute-forcing at random since it's possible to "get lucky". – Bakuriu Sep 11 '13 at 08:08
  • @Bakuriu Except that "possibility" is what you actually care about here. You are using probability outside its range of applicability to the problem at hand, and engaging in theoretical trivia which is meaningless in practice. Sorry but I have to disagree. – Thomas Sep 11 '13 at 08:08
  • @Terry your answer is based on an assumption: "`the web application in question is using a strong hashing algorithm like bcrypt or pbkdf2`". Unfortunately, this is a baseless assumption (unless you know which site specifically the OP is referring to), and statistically it will be false. Quite simply, the huge majority of websites *still* do not use strong slow hash. So the q comes back to: given that bruteforcing weak passwords live is difficult, and with a weak hash even a strong password can be cracked from the hash - should I bother? I don't think you answered for the general case. – AviD Dec 24 '13 at 10:39
  • @Terry, Why do you recommend bcrypt/pbkdf2 over SHA/MD5? – Pacerier Apr 11 '14 at 13:57
  • @Pacerier http://security.stackexchange.com/a/31846/10211 –  Apr 11 '14 at 14:07
15

No password is unbreakable, but they don't have to be unbreakable. They only have to outlast an attacker's patience. Even when someone steals the hashes, they typically decide after the first few million that they've got enough passwords, and if yours hasn't been cracked by then, it is still safe.

That's the thing about strong passwords. The only measure of strength you really need is that it has to be stronger than the passwords everyone else is using. But since you have no idea what that might mean (because you don't know the other users' passwords), the best way to go is to make yours as strong as possible.

The Spooniest
  • 1,637
  • 9
  • 10
  • 6
    Your first phrase isn't true. A password with around 160 bits of entropy is unbreakable through brute force, due to energy limitations in the universe. – Brendan Long Sep 10 '13 at 20:01
  • 2
    Energy limitations in the universe? Reference, please? – MikeS Sep 10 '13 at 20:53
  • 8
    @MikeS It's discussed here: http://security.stackexchange.com/questions/25375/why-not-use-larger-cipher-keys/25392#25392 – SpellingD Sep 10 '13 at 22:03
  • 2
    @SpellingD energy limitations are based on current state of technology. Quantum computer may make breaking 160 bits of entropy possible withing a day with single solar panel... but maybe the attacker would have to wait 500 years for them to be in purchase ;) – Danubian Sailor Sep 12 '13 at 07:37
  • 1
    The entropy issue assumes that you're using brute force to crack the password. If an algorithm is broken -and thus far, it seems that no algorithm lives forever- then the complexity of the cracking problem goes down, and that can bring it back into the range of physical practicality. – The Spooniest Sep 13 '13 at 14:01
  • @SpellingD, That seems to ignore dna computing, quantum computing, and breakthroughs *beyond* quantum computing. Hence "No password is unbreakable" still may hold true. – Pacerier Apr 11 '14 at 14:09
  • @Łukasz웃Lツ No, you need something beyond quantum computers. QCs only halve the effective key length of symmetric crypto. – CodesInChaos Apr 11 '14 at 14:24
  • 1
    Yes, obviously my link is based on the current state of technology. That being said, as long as computers use some form of energy to run, there will be some arbitrary length of bits that will be impossible to brute force for any given technology, so there does/will exist some password(s) unbreakable through brute force. – SpellingD Apr 11 '14 at 18:08
4

When a strong password is also a long password, you have the benefit of it being difficult to shoulder surf.

Some sites and services have APIs that consume user account credentials - unless they are also rate-limited and protected from IP spoofing, they become another attack channel with a faster brute forcing rate.

Chances are if you are using a short password, it didn't come from a password generator - which means the password isn't going to very random. Humans are dreadful at picking random numbers.

If normal password managers a little to slow to navigate with mouse and keyboard; there are fingerprint and proximity auto-login devices on the market.

If the website is spammy and of low value to you, you might opt for a weak memorable password. But it can be very difficult to anticipate the future value of any information or service you have merged with the website. Some website might have Terms of Service holding users liable for damages incurred from breaches due to a weak password (assuming they knew).

LateralFractal
  • 5,143
  • 18
  • 41
3

You are assuming that the only way someone could compromise your password is to get the hash. Strong passwords are also valuable in that they are much harder to break without the hash. PizzaTime is much easier to guess given my Ninja-Turtle-like love of the bready disks than is rpqwe;fdlaskje[]@#4094fd93.

gjmulhol
  • 31
  • 2
  • Not if the account is locked after a bunch of tries, and the owner of the account has to verify it externally to unlock it. – Kaz Sep 10 '13 at 23:00
  • @Kaz, locking the account will make no difference if the hashes have been stolen, something that happens too frequently. – Paddy Landau Sep 11 '13 at 18:31
  • @PaddyLandau Why would the account be locked, if the intruders have access to the hashed password database? They are not sitting there guessing passwords until accounts get locked; they are cracking hashes. – Kaz Sep 11 '13 at 20:01
  • @Kaz, that's my point. The account won't be locked if the hashes have been stolen. – Paddy Landau Sep 12 '13 at 16:15
  • 1
    @PaddyLandau If the hashes are stolen, then the password is quite moot. The site whose hashes are stolen is "pwned", and that extends down to your account. You now have a problem related to that password only if the password itself stores some personal info, or if you re-used the password for other sites. – Kaz Sep 12 '13 at 16:42
2

I've spent a lot of time working with authentication frameworks, standards and implementations of national significance so its not a straightforward answer sorry.

Passwords alone don't buy much, but neither does any control on its own. A password that takes more computation to guess than one that takes less is obviously better against a dictionary or brute force attack. The salt and number of rounds used in PKDF2 allows the system operator to tune the computational brute force cost, but dictionary based password attacks will always feature in an attackers arsenal where there are no/minimal controls to prevent brute force attacks (eg obtaining a copy of the salted password hash against which to mount a dictionary/brute-force attack) whether offline or online.

It is typical to lock out an account after some velocity of invalid attempts is reached. This is an example of a control that makes weak/short/guessable passwords acceptable such as how 4-6 digit credit card PINs are used; the two factor authentication approach (something you have and something you know) and the trusted key entry device (PIN pad), the account/card lock-out controls, strong key distribution and reset processes together make the overall authentication system acceptably secure for VERY SHORT passwords. And when its not acceptable, additional controls are introduced to control risks, eg devices to prevent card skimming, user education to cover the keypad when entering your PIN, better auditing and monitoring etc. There are also well known human factors to consider, e.g. long/cryptic/hard-to-remember passwords and people forgetting them or writing them down vs shorter and hopefully easier to remember passwords that don't get written down or recorded somewhere.

So in answer to your question, 'it depends'. What other controls are present to mitigate the risks of a short/guessable password and still render the system acceptably secure for your information? If you don't know the answer, or you don't trust the service operator then you should only minimally trust them (or not at all) with your information REGARDLESS of password length.

What information are you hosting or sharing with the service provider?

What are the consequences of its unauthorised modification, destruction or disclosure?

It may depend how creative or knowledgeable you are because you may be surprised what can be achieved with a little bit of information if there is a payoff in terms that are meaningful to the threat agent.

Andrew Hacking
  • 264
  • 1
  • 2
1

That is not true. Passwords are not leaked only by their hash, and hashes are very different in terms of strength.

Also you are forgetting salting, that increases exponentially cracking time with brute forcing.

As an example, the best brute force can't crack a 50-character WPA2 password in a reasonable time, while an 8-character alphanumeric key is forced even with a laptop.

techraf
  • 9,141
  • 11
  • 44
  • 62
Max
  • 19
  • 1
  • 6
    Salting has nothing to do with the cracking time of a single password, it only prevents running attacks in parallel. – Brendan Long Sep 10 '13 at 20:01
1

Most hackers use a brute-force approach when finding passwords: trying all possible combinations. This method, though seeming stupid, is becoming more effective as the computers are getting faster.

Generally, you should use a strong password to delay that method. And oh boy it can be delayed! This site here gives you a notion of how strong your password is against this kind of attacks.

BTW, a strong password is only effective against this method. There are others that don't depend on your password but on your privacy settings like your cache, logged in sessions among many other things. You should check your computer for spyware and malware regularly to avoid these.

flapas
  • 111
  • 1
  • 4
    Oh, but just in case you are tempted, **don't** put your actual password into an online tester. Sure, we think this one is fine, but you never know... – Rory Alsop Sep 10 '13 at 16:42
  • 1
    @RoryAlsop The same threat exists from a legitimate site. Assume that every site stores passwords in the clear, and is staffed by people some of whom harvest cleartext passwords. – Kaz Sep 12 '13 at 16:45
  • Yes - but normally you don't reuse passwords, right, so this isn't an issue. But if you put a real password into a malicious password checker site - they then have one of your real passwords! – Rory Alsop Sep 12 '13 at 23:22
1

You are right, and this is a major annoyance. In fact this whole business of hashing passwords and choosing ones that are hard to crack via hashing is a completely pointless sham, and constitutes what Schneier calls "security theatre".

Password hashing is irrelevant, except in specific situations: authentication protocols that communicate hashes in the clear (which shouldn't be done), and password databases which store hashes in a way that is world readable, like the classic /etc/passwd (which isn't done anymore).

In the old days, if you were on a public Unix system with thousands of users, like a machine or farm of machines, providing e-mail accounts for university students, poor passwords were literally cracked left and right. The password file of such a system was a big magnet for cracking, with big payoffs. Of course, such a password file is completely stupid. Any decent Linux distro nowadays puts password hashes into /etc/shadow.

So, the point is, that if an attacker has access to the hashes, the system in question is either ill-designed (quasi-plaintext network authentication protocols, publicly readable password databases) or it has been compromised to the point that knowledge of your plaintext password is no longer relevant, since the attacker needed admin privileges to obtain the hash.

Still, hashes provide a tiny layer of additional security. And that layer protects those who re-use passwords between sites. If one site is "pwned", so that attackers possess your hashed password, you are in trouble if you used the same password elsewhere and that password is easy to crack.

Ironically, people are more likely to re-use very difficult passwords on multiple sites, because they are hard to remember. Second to that, they are likely to quasi re-use the same difficult password by introducing small variations on it. For instance if the original password is considered strong enough to be acceptable by one system, they will just use it on another system, but change a 1 to a 2, or 3 and so on. If attackers crack the password with a 1, they can easily guess the others.

It is much easier to generate and memorize relatively easy passwords, such that they are completely unrelated to each other.

Here is also another thing people overlook: site admins are not your trusted friend. You must suspect not only outside attackers, but also insiders. On any site where you have a password-protected account, there could be an evil administrator who collects plain text passwords. You don't even know whether or not passwords are hashed. Assume that they are not hashed, and assume that among the admins of every site is a malicious person who collects passwords. Even if you know that the site's software uses a hashed password database, you cannot assume that the code has not been modified. The Javascript (or whatever) UI itself handles passwords in the clear.

Oh, and if you don't see "HTTPS" in the browser bar, all bets are off! Your randomly-generated, 32 character password is being collected by someone, in the clear.

A password has to be only difficult enough that it cannot be guessed in several naive re-tries (attempted entry via the normal authentication mechanism). Any decently implemented site implements the important security measure of locking an account that has been guessed too many times, so that the legitimate user has to take extra steps to unlock it.

If your password cannot be guessed in a half dozen attempts, and you're able to generate and remember completely different passwords of this type for every site, you are basically okay.

Password creation UI which forces users to concoct convoluted passwords is annoying, counter-productive, and not founded in any rationally conceived security principles, or the correct identification of possible threats.

Kaz
  • 2,303
  • 16
  • 17
  • And you can add all websites asking you to enter your password through plain HTTP, or those that don't manage securely their SSL certificates and therefore also have HTTPS compromised... – tricasse Sep 11 '13 at 09:00
0

Personally, I think it depends on what's behind the password. Yes, strong passwords are far more secure, as Terry did an excellent job articulating. But for me, the stronger I make the password, the more frustrating it becomes for me to remember what the password is, type in the symbols and casing correctly, etc.

There's a significant difference in the real world between a small, suitcase-style padlock and a deadbolt you put on your front door. Each has an appropriate use, and obviously the less complex the lock, the more risk you're willing to accept.

My bank and e-mail accounts? Those get the deadbolt. Things I don't particularly care about as much… those get the lighter lock.

Pete
  • 101
  • The problem is that more and more sites that nobody cares about are insisting on the deadbolt. Your online banking site should not require a particularly strong password. Why? Because a strong password is only needed to to protect the password itself, in case of a breakin. A breakin is something that must not happen to your online banking. If the bank is cracked, I couldn't care less whether they have my hashed password and attack it; no other site has that password. The attackers might not even need to crack that password in order to mess with the bank accounts. – Kaz Sep 10 '13 at 23:34
0

Yes, of course you should enforce strong passwords, for all the good reasons in the other answers, but it's important to remember that passwords and their hashes exist in a context and not in isolation. Your comment about hashes being increasingly easier to reverse is a good indication of this - it can be true, but it's not universally true that reversing hashes is trivial if you use the right controls but it highlights a really important consideration... it should also be the case that accessing hashes is a well secured process.

However, in most cases passwords are protected against disclosure by other passwords.

Passwords need to be protected throughout a chain of data flow where each link in the flow is protected by another password from (for example) a web browser input form, across an encrypted link (hopefully), into a server demon, into a back-end application, into a library or framework for rehashing, and into/out of a database.

Often, all of these links in the chain are protected by passwords in some way (for example the back-end application is protected against malicious eavesdropping code being added by the modification account password of the deployer or application developer), and the database hashes are protected by the database user account password and database server access account, and so on.

Although strong passwords can only be considered as 'strong' as the weakest password/control in this chain, a risk analysis should confirm that the front-end password management and authentication functions offered to the user are the most likely to be attacked, and should therefore merit more attention - and certainly as high a strength threshold as you can reliably enforce.

David Scholefield
  • 1,824
  • 12
  • 21