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.

  • 2
    What do you consider as long? In your example using a 8 character long alpha numeric password makes an online brute force attack unfeasable. But that is not a likely attack anways.
    – aggsol
    Commented Nov 5, 2014 at 15:02
  • 8
    while its true that gmail have some good security measures in place, it's also true that they are a big fat target for nefarious people and are likely under some form of attack daily. I think that password managers are the way to go until someone comes up with a way to have easy to remember but hard to crack passwords (obligatory XKCD link: xkcd.com/936). Just because a site or service appears to have good countermeasures in place does not mean that they won't be hacked or suffer system (or human) errors. Or of course, sabotage.
    – jammypeach
    Commented Nov 5, 2014 at 16:14
  • 1
    There is no good answer. Unfortunately, random passwords (eg, "pl3sqzjwAb") tend to be hard to remember and type. Most people would probably be happier with "pass phrases", but many sites will not allow them, for various reasons, good and bad.
    – Hot Licks
    Commented Nov 5, 2014 at 18:45
  • 10
    Currently all the security experts keep saying the same thing: make long, mixed chars, high entropy passwords [citation needed]
    – Cthulhu
    Commented Nov 6, 2014 at 11:40
  • 1
    It would be interesting to see some credible analysis of how many actual exposures/penetrations are due to weak passwords, vs all the other holes in security. It's not clear that the million-customer penetrations at Target, Home Depot, et al were due in any way to weak passwords.
    – Hot Licks
    Commented Nov 8, 2014 at 4:24

12 Answers 12


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

  • 7
    You forgot "no programmer ever makes a mistake".
    – user
    Commented Nov 5, 2014 at 21:02
  • The only answer so far that actually addresses the question of letting the services handle protecting the customer.
    – Zack
    Commented Nov 5, 2014 at 21:47
  • @MichaelKjörling I sense a hint of irony? But yes, agreed and updated. Thanks.
    – R15
    Commented Nov 6, 2014 at 7:59
  • @R15 Only a hint of irony. The simple fact is that any mistake on part of a programmer in the wrong part of the code can lead to exploitable weaknesses, and it is far from certain that even with code review such mistakes are caught before someone manages to exploit them and it turns into a major issue. No malice on any developer's part required.
    – user
    Commented Nov 6, 2014 at 9:38
  • 1
    @Falco my original intention of the list was to illustrate our dependencies on the service provider and I did not want to constrain this to 'just' the password side of things in case anyone picks this up in the future and uses it as a tick list for configuring a service. I'll edit the answer to make it more specific (though I do not agree entirely with your analysis).
    – R15
    Commented Nov 7, 2014 at 13:46

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.

  • 2
    Hopefully whatever sites you use do not store passwords in plain text, that would be very bad, and illustrates the need to use different passwords.
    – Jonathan
    Commented Nov 5, 2014 at 12:47
  • 2
    Thinking this way we can assume that we don't need a long password for services like gmail. Since it's very unlikely that their DB will be hacked and even if it is, it's more unlikely that somebody will target your username. Is it right? or maybe this assumption is way too optimistic?
    – drpexe
    Commented Nov 5, 2014 at 13:17
  • 2
    @drpexe But then again, people could have said the same about LinkedIn. Commented Nov 5, 2014 at 16:02
  • 6
    That assumption is way too optimistic @drpexe ... it's safest to assume every password will be hacked, because probably one will, but there's no real good way to predict which it will end up being.
    – aslum
    Commented Nov 5, 2014 at 17:05
  • 5
    @drpexe You cannot assume that Gmail (or any other provider) will not be hacked. In fact, Google has been hacked before. Commented Nov 5, 2014 at 17:14

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.

  • 1
    @drpexe Then you've failed the "easy to guess" security requirement you put in place. There isn't enough entropy in six character "easy to remember" passwords for them to be strong. Particularly once you start talking about several dozen to a hundred of them or more.
    – Xander
    Commented Nov 5, 2014 at 15:39
  • 2
    @drpexe Sure, I'm not saying that it couldn't work for anybody...Certainly it could. It's just not a great general solution to the problem.
    – Xander
    Commented Nov 5, 2014 at 16:20
  • 2
    This doesn't seem to really answer the core question.
    – Lilienthal
    Commented Nov 5, 2014 at 21:16
  • 3
    @Lilienthal I'm primarily pointing out that the basic premise of the proposal is flawed, rendering the specifics irrelevant.
    – Xander
    Commented Nov 5, 2014 at 21:26
  • 5
    More explicitly, the problem is that it may seem easy to remember dozens of 6 character passwords. But remembering even ten 6 character passwords at full entropy is impossible for a human to suffer through. I would suggest noting this in your answer, as it's what the OP is actually proposing and you don't explicitly call out that's where the question is flawed.
    – djechlin
    Commented Nov 5, 2014 at 22:57

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.


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.


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.

  • 1
    It's so unlikely that it happened at least 7 times last year to major companies. Here is a list of major breaches. You may notice that GMail is on that list. While it makes up a small portion of all attacks, when it does happen it exposes millions of passwords. If you look at how likely it is that any given person has an account at a breached site, the odds are actually pretty good. That list includes yahoo, adobe, gmail, and snapchat. I think odds are pretty good any given person has had their password breached in the last two years.
    – Kyeotic
    Commented Nov 7, 2014 at 17:07
  • 1
    @Tyrsius in those cases would having a "complex" password make any difference? As time goes by, I am more inclined to believe the safest password.. is the one that does not exist.
    – prusswan
    Commented Nov 7, 2014 at 18:23
  • 1
    @prusswan Yes, having a complex password gives you more time before the password can be determined. This allows you to change the password on the breached site. The more complex, more time you have. Sufficiently complexity combined with a proper password hashing method (like bCrypt) will make it so difficult that it will likely not be finished before the attacker gives up. The point is that odds are this is going to happen to you, and its better to be prepared with a difficult-to-crack password. Even better if the password is unique, and cracking it will only expose the breached account.
    – Kyeotic
    Commented Nov 7, 2014 at 21:16
  • 1
    @Tyrsius there is no evidence that gmail has been breached. If you follow the discussion about the "Gmail list" there is no evidence that pw hashes were actually stolen, and most people indicate the logins are probably from xtube or other sites...
    – Falco
    Commented Nov 8, 2014 at 9:39
  • @Falco That's good to know. I think my point still stands though: while these attacks are less frequent, when they do happen they result in hundreds of thousands, sometimes millions, of breached credentials. Instead of looking at the frequency of the attacks, we should be looking at the number of people affected per year. It gives a much better indication of how likely you are to be affected by these kinds of attacks.
    – Kyeotic
    Commented Nov 10, 2014 at 16:51

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.


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


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.


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)


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.


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.


  • 7
    hashing is not the same as encrypting
    – drpexe
    Commented Nov 6, 2014 at 8:46

You must log in to answer this question.

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