CODEWITHSUNDEEP
c++cryptographysalt-cryptographysha
Cheshire Cat
Cheshire Cat

Reputation: 223

SHA-512 - salt my password

As a exercise I wrote my own implementation of SHA-512 hash function in C++. I know it works because from abc i get

3a81oZNherrMQXNJriBBMRLm.k6JqX6iCp7u5ktV05ohkpkqJ0/BqDa6PCOj/uu9RU1EI2Q86A4qmslPpUyknw==

In Base64. Just like in test sites.

I have two questions:

  1. How to salt my password? If I have:

    string salt = "ssssssss";
string pass = "mysecretpassword";

    Should I create string to input as salt+pass="ssssssssmysecretpassword"? Or maybe in reverse manner? I tried to find the answer everywhere on google - I can't find something that would really fit.

  2. What encoding in base64 i should use to get exact hashed password like in /etc/shadow file?

Upvotes: 1

Views: 3662

Answers (2)

Anton Samsonov
Anton Samsonov

Reputation: 1422

Theoretically, prepending salt (non-secret data) to password (secret data) is bad. Because, since hash functions process their input sequentially (in blocks of 1 to 64 bytes and more), it is possible to precompute hash function state for the initial blocks of non-secret data and use it as a starting point for all future permutations, — effectively removing almost any additional protection a salt may introduce. However, practically, salt + password usually occupy less than a single input block of a cryptographic hash function (typically, 512 bits or more), so this is not considered an issue.

More important thing is that, when it comes to cryptography, you should never invent your own wheel, but rather use an already existing security scheme whenever possible. When you ask yourself: “Should I do this, or should I do that?” (like “Should I prepend or append salt?”) — chances are high that you are inventing a wheel, which will give you a false sense of security.

With the task of “salting a password”, one road to take is the Hash-based message authentication code (HMAC) scheme, also known as keyed hash: simply use your salt as message and your password as key — and the function will combine the arguments in a proper way, relieving you of duty to remember “whether to prepend or append”. This function is actually a wrapper for regular hashing functions and is quite simple, so you may easily implement it yourself if your crypto framework lacks one, but be sure to test against known results.

The other possible alternative is a Password-Based Key Derivation Function like PBKDF2, which is yet another wrapper on HMAC or similar function. An important benefit of PBKDF2 is that it may perform several [thousand] rounds of hashing instead of just one, which may be increased as processing power evolve.

PS. You do understand that salt must be chosen random on each occasion and not remain static (or, even worse, a dictionary word), do you?

Upvotes: 1

Steve Jessop
Steve Jessop

Reputation: 279195

1) Provided the hashing scheme is good, it doesn't make a difference for security purposes whether to prepend or append the salt. Only if you want to match the result of some other defined password-hashing process.

2) /etc/shadow/ doesn't contain anything so simple as the SHA-512 hash of your salt+password. One application of a hash function is not generally sufficient for password hashing, and this is a situation where overkill is called for.

I believe any GNU-based system will be using crypt(3) with one of the glibc-supported additional algorithms. Wikipedia says that by default 5000 rounds of SHA-512 are used, but doesn't mention where the salt is applied. The final string is the base-64 encoding of the hash after all those rounds. You need to go deeper into the details of what crypt does, than is covered in the man page. You also need to check the number at the start to see whether the algorithm even is SHA-512, or one of the other options.

[Edit: I found a description of an SHA-512 crypt algorithm but I don't know whether it's the form they actually implemented or just a proposal.]

Other *nix systems will have their own equivalents, not necessarily using the same hash function or the same overall algorithm.

The basic reason for hashing 5000 times, is that it means an attacker with access to the hashed password is only capable of testing 1/5000 as many candidate passwords using a given amount of processing power. Meanwhile your system is only capable of authenticating 1/5000 as many login attempts, but that's not a harmful limitation (in fact under certain circumstances the system will throttle the rate of login attempts anyway, so it would make essentially no difference).

Upvotes: 2

Related Questions