I generate passwords for everything that requires security using the following method:

ksoviero@ksoviero-Latitude-E7440:~$ head -c 16 /dev/urandom | base64 

256^16 combinations is more than enough security (for me at least), and would take 2e21 years for even the most powerful computer to brute force (at 5 billion attempts per second, which is impossible).

However, notice the last two characters? Those are always there due to the format base64 takes and the fact that I'm using 16 bytes.

Is there a reason to include or not include the two '=' symbols? The argument to include them would be that they add additional symbols and length to the password. However, if you assume that the attacker knows that I generate passwords using this method (and for security, you have to assume that they know everything sans that actual password), then the two '=' symbols are already known, and therefore add no additional security. However, can they hurt?

  • 5
    As a side note, a single GPU can already crack over 5 billion hashes per second (depending on the hash). An AMD R9 290X can do around 10-11 billion MD5 hashes per second. – PwdRsch Jul 29 '14 at 17:20
  • @PwdRsch I'm not worried about cracking a given hash locally, or rather, I'm more worried about brute forcing SSH, HTTP login pages, etc. Especially among third parties who don't have time out periods for multiple failed login attempts. IMO, if you have the password hash, then you have the password. It might take a while, but I wouldn't bet my security on you being unable to break a hash you already have. – Soviero Jul 29 '14 at 18:04
  • Related, why are the symbols there? programmers.stackexchange.com/questions/245219/… – Liath Jul 30 '14 at 9:47
  • Note that a Base64 string will NOT always terminate with the == padding. – Jacob Jul 30 '14 at 13:04

Base64-encoding processes input bytes by groups of 3; each group yields 4 characters. The '=' signs are padding so that the string length is always a multiple of 4; since the '=' signs are not part of the core Base64 alphabet (letters, digits, '+' and '/'), the decoder knows that these signs are padding and don't encode actual bytes. That way, input sequences of n bytes, where n is not a multiple of 3, can be unambiguously encoded and decoded back.

Entropy-wise, the '=' signs do not harm and do not help. You can leave them or remove them as you wish, it would not change anything for security.

(If they hurt, then this means that the password hashing function used in the system is extremely poor and weak, and that would be a problem which should be fixed -- not by removing the '=' signs, but by using a good password hashing function instead.)

  • All other things being equal, wouldn't obscuring the password(removing '==') so that it's not clear that it's generated in base64 be beneficial? – Cruncher Jul 29 '14 at 17:05
  • 2
    Honestly, I don't need the tell-tale '==' signs to recognize 'gorv/cp+lSiwiEfKck2dVg' as some Base64 encoding. – Tom Leek Jul 29 '14 at 17:25
  • IMO, the = do help in the case that the attacker hasn't realized it's base64. Otherwise they do not harm or help. But on average, they still help. – Mooing Duck Jul 29 '14 at 22:30
  • Given the threat scenario which was however given only after you posted this answer (so still, a fully good answer, with the information available at that time), I'd say the two extra characters most probably do help. The scenario assumes no intrusion and DB theft, but someone trying random (or dictionary) passwords on SSH from the outside. That attacker knows nothing about the password, its structure, or its length. So any two additional characters which need to be guessed are as good as any others. Even if these two chars are always the same, the attacker doesn't know. – Damon Jul 30 '14 at 9:19
  • Well as Soviero's profile on this site mentions the URL of his server he just gave away the last two characters of his password. However in combination with fail2ban or similar measures the password should still be complex enough. By the way: pwgen -s is a good tool to generate passwords and should be installed by default. – Rüdiger Voigt Jul 30 '14 at 12:47

The answers given already answer the question, but if you wanted a password of the same length with those equals replaced by more random characters (more characters that are random, not more randomness), you can just round the number of bytes read up to the nearest multiple of 3:

head -c 18 /dev/urandom | base64

This is because base64 encoding operates on groups of 3 bytes (as Tom Leek already pointed out).

  • 1
    This is the best answer since it increases security over the other two options provided while not increasing the password length. – Major Major Jul 31 '14 at 4:38

It sounds like you already know the answer.

Keeping them reduces the password space to search. Consistency between passwords is only harmful if you can reduce the password space down to an exhaustible size based on your password generation. Which in this case I don't believe is possible. I personally like to include more symbols in my password generation, but with the length you're generating keeping them isn't harmful.

  • Any reason why I was downvoted? Or just for grins. – RoraΖ Jul 29 '14 at 17:42
  • 1
    Keeping them there as known characters has no impact when compared with removing them entirely. – user43639 Jul 30 '14 at 6:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.