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.