I think of Netflix as a technically savvy company, so was surprised to see that they have a password length restriction (60 characters).


I assume there's a legacy reason for this. What might it be? Presumably they're hashing their passwords; if so, why might they not be able to remove the length limit?

They also disallow the tilde character (~).

2 Answers 2


I think of Netflix as a technically savvy company, so was surprised to see that they have a password length restriction (60 characters).

I assume there's a legacy reason for this. What might it be?

Some of the reasons in the Q&A: "Why restrict the length of a password?" on StackOverflow are:

  • An attempt to save storage space. (Source)

  • The front-end intgrates with some old legacy system that does not handle more than a given number of characters. (Source)

  • A case-insensitive 10 character alphanumeric password has 839,299,365,868,340,224 possible permutations. (Source)

  • That's all the space they have in their database to store your password. (Source)

  • The algorithm they use for encryption doesn't work well with large passwords. (Source)

  • They are storing your password as plain text and are trying to save space, but it might also be to try and stop people making their passwords really long and then forgetting them. (Source)

Not every answer there was listed above, see the link for other guesses.

Another explanation on StackOverflow Q&A: "Password max length with bcrypt, blowfish" is:

"BCrypt will work with much longer passwords, though only 72 characters are used. You would have no advantage at all, but theoretically you would hinder people with password managers using longer passwords.". (Source) Also refer to this StackOverflow Q&A: "Best Practices: Salting & peppering passwords?".

Any of those reasons sound likely. Netflix is unlikely to discuss how their user's passwords are secured but the limit is long enough for security, just inconvenient if you have a longer password.

Researchers have tested various websites, one of many articles is: "Netflix and Walmart online sites have one thing in common: bad password rules, study shows". Some places simply have poor policies. There are limits to the value of what is being protected.

  • Might be a combination of an old legacy system that forbids the tilde character and a 12 char salt using bcrypt. Just guessing here but I do not know of some hashing method with a 60 char length limit. Also ( I dare to say it ) disk space cannot be their problem as they will be hashing. They just must be. (Maybe that was more of a prayer than a real answer...)
    – Ben
    Sep 3, 2018 at 5:35
  • 1
    I also think it is reasonable to assume they are hashing.
    – Eli Rose
    Sep 3, 2018 at 13:34

The only security-valid reason I'm aware of boils down to "to avoid DoS attacks against our slow password hash by uploading absurd amounts of password", and 60 is too low a limit for that to make a lot of sense.

The next-least-bad reason I'm aware of is "because users are dumb and if we let them use the entire text of Moby Dick as their password, some of them will, and then some of them will mistype some of it or think they used Don Quixote instead, and then they'll think they have completely forgotten their password and are either going to consume support resources or just stop using the site", which has at least the advantage of not assuming the users are any less intelligent than whoever came up with the password policy.

Or maybe they just can't possibly imagine anybody using an actual honest-to-$DEITY long passphrase. I'll be honest, none of my passphrases are longer than 60 characters; it's a pain to type that much. Heck, it might even only be a client-side limitation, put in by somebody who doesn't understand anything about password security but thinks they're saving space in the database.

All other reasons are bad signs, security-wise.

Some of them are more or less bad than others. Anything involving "to save space" or "the size of the field in the database" is a critical red flag; it means they're storing the passwords either in plain text or under reversible encryption, instead of even a minimal-quality hash. That means anybody who has access to their credential store - be it an untrustworthy admin, or any "hacker" who finds a SQL injection - can probably figure out every one of those credentials with minimal difficulty. Alternatively, they could "just" be using an obsolete password-hashing algorithm that has an inherent maximum length (still not good - those algorithms are obsolete for good reasons - but at least you'd probably need a rainbow table or a few hours of EC2 time to brute-force them).

  • "60 is too low a limit for that to make a lot of sense." Not sure what you mean here. You can't have "too low a limit" to prevent a DOS like this, and 60 characters should be more than enough for a reasonable password, so it's a reasonable limit. Sep 7, 2018 at 9:01
  • @ChrisCooper If their password hashing algorithm is tuned decently and there's any form of respectable anti-brute-forcing protections to how quickly passwords can be tried, even a few hundred characters isn't going to cause enough additional computational cost to be a significant issue for the server. Kilobytes or megabytes of password would, but 60 characters of UTF-8 text is usually only 480 bits; even with salting that isn't going to take very long at all to hash for each iteration. Fair point on "more than enough", though; see first part of third paragraph.
    – CBHacking
    Sep 7, 2018 at 18:46

You must log in to answer this question.

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