Is there any point in using 'strong' passwords?

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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.

Answer 10

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.