Do we really need a long and complicated password for websites?

Question

Most of websites that handle important information (Gmail, for instance) have some kind of brute force protection. Sometimes if you try more than X times it will lock the account or at least give you a captcha to solve.

Currently all the security experts keep saying the same thing: make long, mixed chars, high entropy passwords. This makes a lot of sense if you think about a RSA key, or something that could be decrypted offline, but is it really important when we talk about online account passwords?

For example, we create a password for Gmail using only 6 letters from the english alphabet. This is approximately 26^6 = 309 million combinations. If we consider that we can test 1 password per second (which I think is faster than we actually can, if you take into account the Gmail captchas), we will need up to 10 years to break and 5 years on average.

Points to consider:

• If you use the same password on different website, another website could be hacked and you password exposed. I'm assuming that the password is unique. Used only with Gmail.
• If somebody can grab the database they could brute force the hash of your password offline. I'm assuming that the website uses at least a salted hash (very unlikely that the hacker will try to break all passwords) and/or is very unlikely that the database will be hacked (it's a fair assumption with Gmail)
• I am also assuming that your password is not a dictionary word or something easy to guess. This should rule out multiple account brute force (eg. testing the same common password across multiple accounts).

Is it safe to assume that we don't need a really long password to websites as soon as we follow the other security measures? If we suggest that people use a long password just because they normally don't follow the other security advice (use same password across accounts, etc). Aren't we really trying to fix the symptoms and not the cause?

PS: Some other questions address almost the same thing, but the answers always consider that the person is using the same password across websites or that the website database is easily stolen.

Answer 1

The following doesn't really do this justice, but in summary...

In an ideal world no, complicated passwords should not be required for online resources.

But, in that ideal world we are dependent on the administrators of the system to harden systems to prevent unauthorised access to the 'password file', the following will minimise the risk:

• Securely configure the infrastructure;
• Apply patches promptly;
• Have some form of monitoring to identify a compromise in the event of a zero-day exploit scenario (so that users can be 'told' to change their passwords);
• Have and follow 'secure' programming/development methodologies;
• Only employ trustworthy individuals.

The complete combination of which is unlikely for many sites.

Weaknesses in the above list may result in exploits that enable passwords to be bypassed altogether, but irrespective of the nature of a successful exploit it is a safe bet that, after gaining unauthorised access to a system attackers will attempt to exfiltrate the password file and subsequently brute force it to aid onward compromise of other systems (by exploiting password recycling).

So while there is no guarantee that a strong(er) password will prevent all bad stuff, it can help to mitigate for weaknesses in providers' solutions (whether known or not).

For the avoidance of doubt we are also dependent upon the service provider to do the following:

• Apply hashing and salting to passwords;
• Ensure the password is never exchanged in clear-text.

I guess for most end-users the decision about password complexity and length will come down to the information the site (and therefore password) gives access to.

My recommendation is: if it is something important use a complex password so that in the event of a system compromise other people's passwords are likely to be discovered first. But if it something trivial and convenience is more important take a chance on a weaker password, but accept that a hack could lead to loss of access to the account and/or release of information from the account.

For many site owners I suspect the decision to require complex passwords is a combination of FUD and the desire to minimise the impact of a critical failure of controls by increasing the amount of time to brute-force passwords, thus giving longer to rectify and minimise actual user account compromise (although if an attacker has access to password hashes they probably have sufficient system access to compromise the system in other ways anyway).

Answer 2

The long password recommendation is to protect passwords from being cracked if someone has access to the hash of that password.

Tools like hashcat can easily (using gpu) test 93800M c/s md5 hashes

As a user usually you don't know how does the site stores your password so it is better to use a long password to mitigate those attacks.

Answer 3

Picking good passwords is hard. Humans and our penchant for patterns simply aren't very good at it. Multiply that by the dozens of accounts we accumulate over time, and this is the root of the problem.

So yes, eliminating bad passwords and password reuse can solve the problem of creating soft targets, but it doesn't solve the root problem of maintaining all of those accounts and passwords, which is what leads to the bad passwords and password reuse in the first place. So, it's well and good to say "just follow good password security policies" and you'll be safe, but without tackling the problem of account management you haven't solved anything.

So, what is the answer? Use a password manager. This solves the problem. When you offload the password creation and management problem to a tool that was designed specifically for that purpose, you get strong passwords by default, and never need to re-use a password again. It isn't a perfect solution (nothing is) but it's the best we have at the moment and makes questions of password complexity and length moot, because when you aren't the one having to create and remember the password, you no longer care how complex and long it is, only that it is generated with enough entropy to make it strong, and a password manager gives you that.

Answer 4

The only sane assumptions for any web developers using local password authentication are:

1. that their users are going to be using the same password for everything;

2. that the site has already been compromised, even if they haven't finished writing it yet; and

3. there will be some really expensive legal liability attached to the consequences of that compromise.

(Please note that I am not implying, neither am I suggesting, that all — or even any — web developers are sane or know enough about what they are doing to realise that what they are doing would be be insane if they knew what they were doing. Simple hashes, whether plain or salted, are computationally close enough to plain text as to make no nevermind these days, and yet one still finds plain text, unsalted MD5, etc. scattered all over the web in so-called "tutorials" that people are coping and pasting into production on servers everywhere.)

Those assumptions mean that even if I'm running a site with extremely local application dedicated to allowing people to list recommendations for organic, free-range, locally-grown gluten-free hamster treats, I have to treat your password as if it were your PayPal, eBay and email accounts all combined (because there's a pretty good chance that it effectively is). And that means that in order to protect my own rather precious behind, I have to take at least some minimal steps to protect your precious behind whether you like it or not. Ideally, that means making your password something that can't be trivially brute-forced (using a crypto-random salt and an expensive key derivation function) and putting an absolute lower limit on the character count (ideally with no upper bound, within reason), while still allowing you to use something that's easy for you to remember (none of that "must use at least one accented character, one emoji and one hiragana" nonsense). In other words, letting you use a really short password exposes my personal buttocks to unwarranted hazards, so don't expect me to allow it. And that's if my site doesn't guard any secrets except your password. If there is any actual personal data associated with you that I am responsible for, expect my paranoia on your behalf to increase dramatically.

Answer 5

There are issues with a couple of your assumptions.

309 million is a laughably small number if there is an offline attack. And on an offline attack, even with a good salt, the attacker will go after the low hanging fruit first. Ie. find the passwords that are in the dictionary, then the short passwords, then other simple passwords. How much of a problem this is is debatable though - the chance is good that an attacker with acess to the password database also has access to whatever else he is after. - This assumes that no password reuse is taking place.

309 million is, as you note, too large a search space to brute force in an online attack. However your assumptions that lead to this number is dubious. We as a species are notoriosly poor at two relevant tasks; comming up with genuinly random sequences and remebering random sequences. This means that your entropy is significantly lower if you selected a 6 characters password. This can be avoided if you use a password manager or similar utility, but in that case you might as well also go for a longer password to protect against offline attacks.

In conclusion; getting good entropy in your password depends on the entropy pr character and the length of your password. - If you have good entropy per character you can accept a shorter password. However that is an approach that is poorly suited for most humans, since we remember longer strings with lower entropy per characters better than shorter strings with high entropy per character. We also such at generating random strings, and the advice you quote is for people who do not use password managers to generate passwords.

Answer 6

Using a complex password for a single secure site is like using a special lock on your apartment door, which makes opening the door take longer and protects you better from 1% of all burglars

Most answers deal with all kinds of attack scenarios, which could compromise your password, but to decide if a smaller password (6 Characters) is sufficient if you use it only on 1 single site with reasonable good security we only have to compare a single number:

How many attacks work significantly better on a weak password than on a strong password?

If online brute-force protection is sufficiently strong (a premise in the question) the only relevant attack scenario is offline brute-forcing. In all other attack scenarios (plaintext password read, session theft, social engineering, phishing, user forgery) the complexity of the password doesn't play any role (if it is not a standard password)

So how many % of attacks on your account or on gmail will probably use a feasible offline brute-forcing of your password? Probably next to none. Brute forcing will only work against a hash or encrypted version of your password. Anywhere else your password is in plaintext (so complexity is irrelevant) or not relevant at all (e.g. session-id, direct access from an insider to the mail-storage server)

The only instances where your password is encrypted or hashed are 1. salted hash in the database and 2. transfer of your password via HTTPS

1. Salted Hash in the database If the hacker did gain access to the database where all user-passwords are stored (probably one of the best secured points in the infrastructure) but could not get access to any other services (like an active session-id or direct account access) Then an offline attack against your salted hash with an brute-force attack would quickly wield your password.

2. HTTP Transfer Very unlikely because the attacker would have to brute-force your HTTPS stream to isolate your password, so password length most likely doesn't matter much.

So the only scenario in which a long password actually protects you is if someone gets access to the (probably) most secured data-storage of the infrastructure without anyone noticing - and without enough access to get an easier access to your account. I would say this scenario is really improbable, because in the vast number of vulnerabilities and attacks against your account, this is only one unlikely attack type.

Answer 7

My answer is simply yes. You can't assume sites are using salted hashing methods. For example, MD5 is still being used in the wild and people think its perfectly acceptable.

But with a strongly salted hashing mechanism, there's just no way someone can gain access to the actual password, even if it be a low char pass. Especially speaking if your server is properly secured and your api takes the proper precautions for brute force attacks.

Answer 8

While it is safer to make complicated passwords, I always recommend making them easy at the same time, and also have a uniqueness per website. The only way this would be a vulnerability is if you fall for a phishing scam, which is why it is important to have multiple ways to recover your email address, because your email is your way to recover other accounts.

Here are the rules I use personally:

• At least 8 or 10 characters, preferably 12 or more
• Use something that means something to you
• Abbreviations or using a number instead of a letter can be easy but effective
• If you want, you can use a prefix or suffix to keep passwords unique

So for example: ThisIsMyPassword14si

Uses: Capital letters, numbers, and the suffix of si for stack exchange, and has a year of something that means something personally. This kind of password usually always shows as a strong password.

There are also more services that allow you to sign in using another token-based service. I think this is a great idea, because you can log out whenever you like to remove any access, and you don't need a password for every single service (assuming the developers have designed the process correctly). HOWEVER, you must be more careful with the password to that service and have multiple recovery options for it in case you loose it for whatever reason.

I think that google is heading in the right direction here, by having multiple recovery options and 2-factor authentication. The problem is, almost anything can be spoofed if you do not pay attention to the actual page that is requesting your information.

Hopefully in the future, there will be a device that is on you, like a mobile phone, that can act as the security clearance for web services. Apps are controlled by the distributor, so having one app per platform to get the request for access, and ask for your permission will be the right way to handle it in the future, so we don't have to worry about this individual password for everything nonsense.

... one day...

Answer 9

Lets not forget that someone doesn't need to brute force one target. They can try the same password with many targets making the users with the most common passwords vulnerable.

Answer 10

You forgot the local physical attack! A long complex password makes shoulder spotting much less likely to succeed. Even if someone stares at my keyboard, he won't get my passwords unless he's Rainman. (cannot comment)

Answer 11

When using a reliable two-factor authentication system, using a less secure password is reasonable. It's still best to use a difficult password generated by a password generator using upper and lower case, numbers, and symbols.

But folks who will not do deploy such a secure password; in the case of a service that offers two-factor authentication, those folks can feel reasonably secure.

Answer 12

You can't secure your password by using large scale of combination.For that you have to crypt your password.Some common crypt algos are md5,SHA-1,SHA-256 stc.But still it's not 100% secure.Attacker can decrypt your password using tools like hash cat with high GPU as mentioned above.

So in a nut shell no algo is 100% secure.But you can generate a strong password mechanism by using salts with existing crypt algos.Here is some famous crypt algos.

http://en.wikipedia.org/wiki/Comparison_of_cryptographic_hash_functions