← Back to context

Comment by gruez

6 years ago

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

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

      1 reply →

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

      1 reply →

  • 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

      5 replies →

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.

      1 reply →

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

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.