13

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

ksoviero@ksoviero-Latitude-E7440:~$ head -c 16 /dev/urandom | base64 gorv/cp+lSiwiEfKck2dVg==

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?

Improve this question
4
  • 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. Commented Jul 29, 2014 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. Commented Jul 29, 2014 at 18:04
  • Related, why are the symbols there? programmers.stackexchange.com/questions/245219/… Commented Jul 30, 2014 at 9:47
  • Note that a Base64 string will NOT always terminate with the == padding. Commented Jul 30, 2014 at 13:04

3 Answers 3

Reset to default
24

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

Improve this answer
7
  • 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? Commented Jul 29, 2014 at 17:05
  • 2
    Honestly, I don't need the tell-tale '==' signs to recognize 'gorv/cp+lSiwiEfKck2dVg' as some Base64 encoding. Commented Jul 29, 2014 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. Commented Jul 29, 2014 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. Commented Jul 30, 2014 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. Commented Jul 30, 2014 at 12:47
15

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

Improve this answer
1
  • 1
    This is the best answer since it increases security over the other two options provided while not increasing the password length. Commented Jul 31, 2014 at 4:38
-2

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.

Improve this answer
2
  • Any reason why I was downvoted? Or just for grins. Commented Jul 29, 2014 at 17:42
  • 1
    Keeping them there as known characters has no impact when compared with removing them entirely. Commented Jul 30, 2014 at 6:14

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.