Many, many websites will happily accept passwords of $X characters and then hash only $(X-Y) characters on registration, but try to hash all $X characters on login, so of course the hashes don’t match. And at no point do they tell you the maximum number of characters.

I once had a page that prevented pasting, but last pass's password generator still worked. So I put in a long password using that, but when I clicked to register it came up with a blank error message. Turns out they had a 16 character limit that was only enforced when you typed in the box, so I had to count the number of letters they allowed me to type and then let lastpass generate a password of that length. Infuriating.

This has happened to me on many occasions, even with bigger sites which "should know better". Tis why I'm always slightly paranoid about entering in long passwords when signing up to new sites.

Square Enix's account management on the PS4 allowed me to set a password with a space on the end, but their website strips spaces from the password field when you sign in.

Fun fact: it's actually really easy to submit a string with a space on the end when entered via a PS4 controller.

Trimming spaces is the one evil that is kind of necessary. Way to many text selection tools select trailing spaces. Firefox and Chrome both do when selecting words. Got a mail with a reset password and want to copy it over? Yeah, good chance the space is copied as well. On a few occasions even ended up in my password manager. Please, just apply password rules everywhere consistently.

> Please, just apply password rules everywhere consistently.

This would honestly fix all of it, without even needing to communicate information about how passwords are handled. Although, I think those rules should be communicated as well, so users can make good choices about password security. If spaces are removed, that lowers entropy and users may want to add additional characters or restrict spaces in their password generator.

It may not be easy. You might have dozens of different client applications with different requirements or abilities. But it is simple: Figure out your best practices and your lowest common denominator. Then apply those rules to every password every time in every context.

Alternatively, if you have clients which (for whatever reason) need a special case, create a separate hash for that special case and then use that only for that client. (Likely, this will reduce the overall security of the account, but if this is your lowest common denominator, allowing other clients to have greater security certainly doesn't hurt you.)

On a semi-related note I once had to help a coworker who couldn't log into a server using an auto-generated password listed like so:

The password is p4ssw()rd.

Turns out they didn't realize the period was part of the password.

Back in the day, I created an AOL password with CTRL-BACKSPACE in it. It worked when using the AOL software but when I tried to log into the website, it deleted the password.

Yes, this is terribly annoying, often there is a minimum length but no mention of maximum length. I see this on many, many websites...

What kind of range limits are you talking about? 30? 100?

Lots of sites have a limit of 72 characters, maybe even without the developers knowing about it. Bcrypt has a limit of 72

It's honestly a crapshoot. I've seen as low as 8 (a sibling poster says 6), but 10, 12, 15, 16, and 20 are not unusual. It's usually an even number, so you can just knock 2 characters off your password at a time (after making it an even number) until you're down to the maximum to figure it out.

Wells Fargo’s is 12 IIRC.

Lots and lots of legacy systems do this, very low limit, case insensitive, numbers and letters only. I know of a major retailer with 10 character, case insensitive, alpha numeric for All their systems. Why? Because that’s the lowest common denominator (as400).

That's how my dentist's billing website works. Except it's limited to 8 alphanumeric characters, not 10, and they were quite happy to accept my pasting a 16-character generated password into the field. Unfortunately, they don't have a password reset link; instead, the you call the receptionist and they read out your password to you over the phone. This isn't a legacy system, either. I can only imagine the backend is written in QBasic or something.

I have a 14 character WFC password, seemingly works fine.

Try changing the last two characters and see if it still lets you in. It's not that uncommon that people mix up when to filter input and when to validate it.

Tried and failed (to login). Looks like they are at least validating my entire password.

I believe that Blizzard had a limit of ~20 until recently for battle.net accounts (don't know if that's still the case).

Passwords for Blizzard accounts are also case-insensitive, as they are converted to upper case before hashing. Try it!

I first found this while working on a WoW server emulator in around 2009, but I believe it's been the case since Battle.net 1.0 was launched in 1996. In order to preserve backwards compatibility, it's never been changed.

I remember that Microsoft got stuck with a 16 character limit for a while thanks to hotmail.

"for a while"

You mean until May of 2019?

https://techcommunity.microsoft.com/t5/Azure-Active-Director...

Often it's 20. Not sure why 20 is so common.

Someone somewhere probably posted a code sample with a 20 character limit...

I've seen 6 characters and 16.

Had this issue with Google a few years ago when I tried to set my password to something ludicrously long (think 5000+ characters). It would happily change my password, but I couldn't log in to anything afterwards…

For many years, Schwab ignored any characters after 8 in its password. Discovered that when I knew I flubbed one of the last characters, and it still worked.

I still can't believe a major bank got away with that for so long, apparently unharmed.

I learned this the hard way when I started using a password manager. I had the bright idea to start using 90 character passwords for all my accounts and suddenly I couldn't log into a lot of accounts.

I had something similar happen with (iirc) spectrum of the power company a couple years ago. Their customer portal let me use a complicated password to sign up, it sent me the confirmation email prompting me to log in, and refused my password for forbidden characters. But then I couldn’t reset my password because I hadn’t verified, and I couldn’t modify the account cause I couldn’t log in. I was just trapped in limbo. Customer service said they couldn’t fix it for me. I had to pay my bill by phone until I moved.

Ah yes, this reminds me of my University account. I chose a long password generated with my password manager, which of course contained a chara66 that was both allowed at set up and usage. But because I had to frequently type it in without my password manager (i.e. on a University PC), I wanted to change it. But the change dialog asked for the old password and didn't accept it, due to the forbidden character. I had to go to the support who refused to believe my story and wasn't able to change my password. It took a few weeks to get hold of a person who was allowed to change passwords.

So many home-routers are run with horrid CGI-scripts on the back-end - I'd not be amazed to learn that submitting a form-field with `blah` in it would try to run the command blah (probably via busybox).

If you have time/patience it might be worth exploring.

I've actually rooted an Asus router owned by a relative, this was about 5 years back so it's hopefully fixed now. Noticed some strange behavior after a mistype and tried something like `whoami` (not exactly) and got root back so tried a reverse she'll with NC which worked perfectly. Googled it afterwards and found a ton of similar flaws on other home routers. Tried to do some kind of responsible disclosure but never got a reply or saw a fix then I forgot about it.

>Avoid backticks in passwords.

Is there even a reason to include special characters in passwords? They add 10% more security[1] but cause all sorts of issues with systems. Just use an alphanumeric password that's 10% longer, and if special characters are mandatory, use a safe character at the end like _ or -.

[1] 6.55 bits per character (all printable ascii characters) rather than 5.95 (only alphanumeric)

Special characters in passwords were highly recommended when rainbow tables were an effective way to attack password hashes. See this old Coding Horror blogpost for an idea what it was like at the time: https://blog.codinghorror.com/rainbow-hash-cracking/

Salted hashes have made rainbow tables less effective. Password managers have made single-use passwords more tenable.

Not knowing how a system will store my password, I still prefer to include special characters where available. Anecdotally, I tend to see the systems that are most averse to special characters are also strict about character limits, so simply increasing password length is not possible.

Password Managers are the new goto for obtaining all passwords and web browser zero days make it very easy to lift and then use for a variety of purposes. A simple lined small note book is good, but made secure is best, yet how would you make a pwd note book secure from someone else? This even applies to devices like bank cards and other things which needs a security code of sorts.

Keep your password manager offline with Keepass2 USB keyboard plugin for Keepass2Android [1], but I'm not sure how well it works. Too-fast USB keyboard input does seem to have issues (the open issue seems similar to things I've seen an AlphaSmart 2000/3000 do in USB emulation mode; PS/2 always worked fine).

There's also this other project, which seems more generic/difficult [2]

1: https://github.com/whs/K2AUSBKeyboard 2: https://github.com/pelya/android-keyboard-gadget

Make the passwords one character longer than what is noted in the book? Only you know the character and where it is added.

For bank cards with fixed lengths, increment/decrement the nth character, swap two characters, or do a circular shift.

Or an arbitrary number of characters. If you know the additional six alphanumeric characters added, that's another 14 million combinations to test.

Or 2FA, or ....

> 10% more security (6.55 vs. 5.95 bits per character)

That's not how this works. By your logic having a password consisting of 1,2,3,4 is only twice as secure as having just 1,2.

That's absolutely how bits of entropy work.

However symbol frequency is also significant for entropy.

Do you think 1 in 25 four letter passwords contain a backtick?

If you were brute forcing an ASCII password (no whitespace), would you naively cycle from ! up to ~ for each character?

The context is randomly generated passwords, so dictionary attacks (or other attacks that look at the plaintext from a Huffman encoding perspective) aren't really relevant.

That's most definitely not how security works. The strength of your password is not proportional to the number of bits of entropy it has.

The way you're phrasing this may be misleading.

The strength of a password / passphrase increases with the power of 2 raised to the bits of entropy.

That's an exponential proportion, rather than a linear one. But a proportion all the same.

Example:

Given mixed-case alphanumeric (62 characters) and an 8-character password length, the number of combinations is:

    62^8 = 218,340,105,584,896 (keyspace -- 218 quadrillion)
    l(62^8)/l(2) = 47.6 (bits of entropy)

A 10 character password (if randomly chosen from the same character set) has 10^17 possibly combinations (about 4,000x more), and 59.4 bits of entropy, 11.8 bits more. 2^11 = 2048.

In the context of randomly generated passwords, it's absolutely ok to think about it in terms of the logarithmic relationship between 1) entropy per symbol times number of symbols and 2) strength of the password.

He said 10% stronger (which I took to mean 10% more entropy), not 10% more time to crack.

> He said 10% stronger (which I took to mean 10% more entropy), not 10% more time to crack.

Hence the problem?

Yes, measuring "strength" by "bits of entropy" is technically correct (the best kind of correct...).

It's also exponentially misleading... possibly the worst kind of misleading?

Just look at the question: "Is there even a reason to include special characters in passwords? They add 10% more to security...". I don't know about you, but to me doesn't really portray an understanding of the fact that it takes twenty-five times longer to crack such a password for merely 8 characters, not merely 10%.

I mean, counting in entropy with the knowledge that the applied effects can be logarithmic is the standard way of discussing such matters. It's sort of the basis for the information theory that's underneath this type of work.

Edit: And the point of his argument is that more symbols of a smaller corpus of symbols can be equivalent if the entropy is equivalent.

According to KeePass2, the password: "12" contains 7 bits of entropy, but "1234" only contains 5 bits of entropy.

Is that right?

I wouldn't trust it. If you use the "Hex key - 128-bit" preset, it returns a different amount of bits every time you click it. Here are 3 samples:

    3f38ba8a6ce3aa800f007c2e431df7fd  124 bits
    9339bf587ee11b12d207df846a879cf4  129 bits
    8ca4354a9038df590fecec1f964062fd  121 bits

Due to missing or repeated characters from the set of the hex alphabet?

which doesn't make sense.

I randomly generated an 8 character alphabetical (all lower case) password "jraxxhwr". According to keepass it has 32 bits of entropy, but the entropy should be 26^8 = 37.6 bits because the search space is all 8 character letter permutations. There's no way you can reduce the search space from 37.6 bits to 32 bits unless you have an oracle that says which characters I used.

It does make sense, because the keepass entropy estimate presumably (like the excellent zxcvbn) tries to approximate the empirical distribution, not the theoretical uniform one.

In theory, "68703649" and "12345678" are equally likely to be pulled from the hat, but in practice one is a much better password than the other. You can reduce the search space by trying the passwords with higher (empirical) probability first.

> the keepass entropy estimate presumably […] tries

KeePass sources are available [0], you can see the specific algorithms it uses in [1].

[0]: https://sourceforge.net/projects/keepass/files/KeePass%202.x...

[1]: https://fossies.org/windows/misc/KeePass-2.42.1-Source.zip/K...

Thanks. I've looked at the code, and it does not seem to try to estimate the empirical distribution (doesn't appear to be using dictionaries, for examples).

Then the discrepancy maybe comes from the number of glyphs within certain categories, or their repetition?

If passwords are hashed should any character be prohibited at all?

Some do MD5($password) in a sql string.

I don’t... but i’ve seen it

MD5 and all other hashes still take arbitrary bytes as input, so they wouldn't be the source of any restrictions; I suspect the majority of them are due to character set/encoding issues more than anything else.

Presumably he's talking about code like this:

   $cursor.execute("SELECT * FROM users WHERE username = '$username' AND hash = MD5('password')")

Allowing any value would allow for SQL injections, so the programmer does the lazy thing and "sanitize" the inputs ($username/$password) with a roll-your-own "sanitizing" function that throws an error if there are "evil" characters.

Another way to say this that wouldn't rile so many people up is "In order to achieve the same size search space, you'd have to use ~10% more alphanumeric characters than all of printable ASCII."

Is there a special reason to forbid using native languages unless your native language is English?

bits usually add exponential complexity, so that '10% more' security might mean a password that's a million times harder to brute force..

10% more refers to the character length for the same amount of security, so that's already baked in. eg. you can get a 128-bit entropy password with 22 alphanumeric characters, or 20 characters with all printable characters.

calculations here: https://news.ycombinator.com/item?id=20678529

Based on your numbers they add 10% entropy per character. Which compounds into an increase of 210% over a length of 12 characters. Thus you'd need the password to be at least 3 times longer with only alphanumeric characters to have the same entropy.

no, check your math.

number of characters required for 128 bit entropy password using alphanumerics: 21.49[1]. round off to 22

number of characters required for 128 bit entropy password using all printable characters: 19.5[2]. round off to 20.

22/20 = 110%

[1] https://www.wolframalpha.com/input/?i=solve+log_2(62%5Ex)%3D... (under "real solution", click on "approximate form")

[2] https://www.wolframalpha.com/input/?i=solve+log_2(94%5Ex)%3D...

There are about 138k printable characters, not 62.

I went to change my password on a forum site that I had not used in a few years. My old password was really weak - think "abc123" or something similar.

I logged in and then attempted to change my password to my new standard of 20+ character upper/lower/symbol. The problem was, they'd upgraded their forum software, and there was a bug that added password strength validation to the "old" password field.

So I was putting in:

Old: abc123 New: sZp10VzIoZI9g143

And was getting the error message "error: your password must be 8+ characters long". After about 10 minutes of frustration and realising they had both client and server validation I went down a similar route as you and used forgot-password even though I knew the password.

Oh yeah, I've run into a lot of similar problems with even very well tested applications. The password reset field would accept inputs not valid at login time. I mostly ran into this when generating random passwords 100 characters in length from LastPass.

At one point GitHub even changed reduced their max password input to a sane amount, and I couldn't log in anymore with my existing insane password length a few years ago.

In most cases they fix the case when I report it, but my bank is terrible.

Similarly, my Belgian ISP (Telenet) has WiFi home gateways that are configured by their web portal, and config is pushed by the ISP.

I figured out that they only did validation on SSIDs client-side, so managed to get around that to put emoji's in my SSID.

Which then proceeded to soft-brick the entire thing on config push. I'd have to log in to the web portal via another connection, change the SSID there, and then reset the hardware with the reset button to get internet working again.

The stereo in my 2013 GTI crashed hilariously if you tried to pair a Bluetooth device with anything in the name outisde of [a-zA-Z0-9]. I wish I'd have messed around with it some more before I sold it (it was a silly car to own for how little I drive)

Oooh this reminds me, I am trying to learn a language that of course has ‘non-standard’ characters, and not even anything particularly exciting - Ä, Ö and the like. I thought it’d be cool to help memorise words (and be super secure) by changing frequently used passwords to phrases that contained these words... ...Caused me some trouble.

> avoid backticks in passwords

I learned that lesson a different way: When I had a Windows phone my email password had a backtick, and the only way to enter it on the phone was to long-press the apostrophe, pick backtick from the three or four apostrophe variants that appeared, and pray I didn't fat-finger it and enter the wrong character. In general, there are just some second class citizen characters you should always avoid, because you never know how hard they're going to be to enter when you're on a phone or a kiosk or whatever. (Tilde, I'm looking at you, too.)

There are regional keyboard layouts lacking backtick completely. (I would have to use alt+96 or switch keyboard from my default (and only) Czech QWERTZ layout to type `, if I hadn't more convenient AutoHotkey shortcut in effect.)

The Indian version of personal retirement fund NPA website does this, I learnt a lesson. Every certain weeks you Have to change password. No big deal. I will just add an incremental number. Ok, password now is PasswordPass1. Lets login, Wrong password? Why? Error Password length exceeded.

So, the password change page will accept any length password, will silently truncate it if longer & save it. Now on login page you have to guess the password length or reset.

This is one reason why I stick to alphabet (+case) in my passwords, when I can make them long.

I had the exact same issues with some passwords which were accepted when creating them, then not accepted anymore when used to log in.

This plus emails such as [email protected] or [email protected] show how much sites are broken because of some philosophical ideas of developers.

I once had the bright idea to use a backslash as a one character password for my girlfriends computer, thinking it would provide amazing convenience – a single character, just above the enter key. Turns out this doesn't work very well, even on a Mac, which you would think would have gone through fairly robust testing.

Once upon a time, I went through my logins and tried to change them to strings with weird characters. I ended up with a password of on an internal school site and couldn't change it to anything else, since the "change password" site somehow rejected it.

I had a similar issue when my bank introduced a new banking app. The web login page has different requirements for the password than the app. I.e. on either I can set my password to something that the other will not accept.

I had a backtick in one of my passwords very long ago. When I first got my iPhone I couldn't figure out how to type that backtick until I realized one needs to press and hold and apostrophe.