I am currently working my way into hashing with SHA512.

To my knowledge, the result of such hashing is often passed around as a string in this format


And now I am simply wondering: within this string, what is the true nature of "salt" and "hashed-secret" --- are they "real" strings (as shown here for example, as output of the crypt tool); or is there a "rule" that says that those strings should always be base64 encoded.

4 Answers 4


You need to distinguish between SHA512 (a general-purpose hash function) and sha512crypt (a password hashing function based on SHA512). A string starting with $6$ is the output from sha512crypt. It's possible you knew this already, but the wording of your question leaves open the possibility that you didn't.

The specification for sha512crypt is here. It doesn't say much about the construction of the salt, only this:

For the SHA-based methods the SALT string can be a simple string of which up to 16 characters are used.

At least one implementation (for python) says that the salt must be composed of alphanumerics, dot, and slash (the characters used in the original DES-based unix crypt). I think it would be wise to stick to those characters.

The hashed-secret is base64 encoded, not with the MIME base64 alphabet but with the unix crypt alphabet.

The encoding used is as follows:

  • 1
    Note: there are a lot of other steps in the sha512crypt function that aren't related to the questions you asked. If you want to make a compatible implementation you'll have to read the whole thing. It's far from a simple SHA512(concat(salt,pw)).
    – user54862
    Jan 20, 2017 at 14:01
  • Yep, other implementations as well - FWIW, mkpasswd and the underlying crypt functions in Unixlikes also expect only alphanumerics, dot, and slash ([a-zA-Z0-9/.]) in the salt, and will reject all other characters as "Illegal salt character". Feb 15, 2022 at 2:59

often passed around as a string in this format

I think I get invited to different parties than you do.

This is the format used for storing passwords on Unix systems and processed by crypt. Its also used in some other systems (e.g. apache).

is there a "rule" that says that those strings should always be base64 encoded.

Crypt does not use base64 (or at least it never doesn't for older password formats) it uses radix-64 encoding. Both use 64 ascii characters to encode binary data - but they are not compatible.

AFAIK there is no standards documenting defining these records - only a convention.

  • Could well be. I am very new to this party; and I wasn't exactly invited but pushed into ...
    – GhostCat
    Jan 20, 2017 at 13:51

That format is just a common representation of the underlying hash value. The hash itself is a binary value of a specified length (depending on the specific hashing algorithm used). In the case of SHA-512, it's 512 binary digits, or 64 bytes, or 128 hexadecimal characters, or an 88 character long base64 encoded string. They all correspond to the same underlying hash, just as "one", "un" and "eins" all correspond to 1.

Similarly, the salt is just a bunch of binary digits. You could represent it in any form you choose, as long as you represent it in the same way wherever you expect to be able to compare hash values. Base64 encoding just happens to be a fairly reasonable way of transferring arbitrary binary data around. In some cases, the bunch of binary digits happens to correspond to a string in some text encoding format, in which case you wouldn't need the encoding, technically, but you would need some way of detecting whether the string was intended as a string, or as a representation of underlying binary.


Just for the record: based on the input the other answers provided, I finally used the "correct" search words; which pointed me to

to this question on SO ... that gave me the exact thing I was looking for.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .