77

I work in C# and MSSQL and as you'd expect I store my passwords salted and hashed.

When I look at the hash stored in an nvarchar column (for example the out the box aspnet membership provider). I've always been curious why the generated Salt and Hash values always seem to end in either one or two equals signs.

I've seen similar things while working with encryption algorithms, is this coincidence or is there a reason for it?

Improve this question
14
  • 20
    As an aside, if you are storing Base64-encoded binary data in an NVARCHAR field, I weep for your 6x storage waste! For one, Base64 can only contain 64 of the characters in the lower half of ASCII (so you only need VARCHAR to save half). For two, Base64 explodes each byte of data into 1-4 characters. SQL Server already has a VARBINARY type that is quite capable of storing your hashes without bloat from encoding, and doesn't care about collation in its comparisons... :-)
    – jimbobmcgee
    Jun 17, 2014 at 15:28
  • 3
    @WillieWheeler, the hash has to be stored somehow. Base64 might not be the perfect storage medium, but there's nothing inherently wrong with it. If hash("my password") produces the array [1,2,3,4,5] and I need to store those values in a database, there are worse choices than storing the string AQIDBAU= (Of course, if the hash function in use is already producing a string, it seems a bit silly to then Base64 encode it.)
    – Brian S
    Jun 17, 2014 at 20:42
  • 2
    @WillieWheeler I think you are missing the point. Re-read what Brian S wrote - he was not talking about properties of base64 for hashing - that would be absurd base64 is not a hashing algorithm. He is saying that there is nothing wrong with storing a hash (produced by a hash function/algorithm) in base64 form.
    – Andrew Savinykh
    Jun 17, 2014 at 21:29
  • 3
    The OP says that the he stores the hash and it ends with equals signs. That suggests that he's confusing hashing with Base64 encoding. If the point is that it's fine to base64 encode a hash, then of course, but what does that have to do with anything?
    – user21123
    Jun 17, 2014 at 21:37
  • 2
    Yeah, I finally realized what is going on. I looked in my SSH public and private key files and noticed that they also have the =/== endings. These are base64 encodings of byte arrays, like BrianS and zespri describe. Thanks guys.
    – user21123
    Jun 18, 2014 at 6:47

2 Answers 2

Reset to default
105

These hashed string are (usually?) coded in the Base64 format and the equal sign are used for padding the string to make the length (number of bytes) divisible by three. Wikipedia explains it pretty well: http://en.wikipedia.org/wiki/Base64.

Improve this answer
41

Could it be Base 64 encoding padding?

The '==' sequence indicates that the last group contained only one byte, and '=' indicates that it contained two bytes. The example below illustrates how truncating the input of the whole of the above quote changes the output padding:

http://en.wikipedia.org/wiki/Base64#Output_padding

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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