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.

  • 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, 2013 at 12:03
  • 3
    If it can be brute-forced/guessed, then by definition it wasn't a strong password. Sep 10, 2013 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, 2013 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, 2013 at 13:22
  • 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, 2013 at 14:47

10 Answers 10


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, 2013 at 9: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, 2013 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, 2013 at 13:44
  • 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. Sep 10, 2013 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, 2013 at 20:19

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.

  • 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. Sep 10, 2013 at 20:01
  • 2
    Energy limitations in the universe? Reference, please?
    – MikeS
    Sep 10, 2013 at 20:53
  • 8
    @MikeS It's discussed here: security.stackexchange.com/questions/25375/…
    – SpellingD
    Sep 10, 2013 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 ;)
    – user9850
    Sep 12, 2013 at 7: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. Sep 13, 2013 at 14:01

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).


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.

  • 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, 2013 at 23:00
  • @Kaz, locking the account will make no difference if the hashes have been stolen, something that happens too frequently. Sep 11, 2013 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, 2013 at 20:01
  • @Kaz, that's my point. The account won't be locked if the hashes have been stolen. Sep 12, 2013 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, 2013 at 16:42

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.


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.

  • 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, 2013 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, 2013 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, 2013 at 23:22

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.

  • 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, 2013 at 9:00

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.

  • 6
    Salting has nothing to do with the cracking time of a single password, it only prevents running attacks in parallel. Sep 10, 2013 at 20:01

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.

  • 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, 2013 at 23:34

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .