0

I am in the process of programming a password manager(for educational purposes only!) in C++. To generate the master key, my program will run the previously inputed master password through the password hashing function argon2 to generate a master key. I have 1 problem. I need a way to generate salt for use with that hash function. From my previous research(Google search: "generate salt c++", and searching StackOverflow), I have seen people do various things similar to this:

#include <iostream>
#include <string>
#include <cstdlib>
#include <ctime>
using namespace std;

static const char alphanum[] =
"0123456789"
"!@#$%^&*"
"ABCDEFGHIJKLMNOPQRSTUVWXYZ"
"abcdefghijklmnopqrstuvwxyz";

int stringLength = sizeof(alphanum) - 1;

char genRandom()  // Random string generator function.
{

    return alphanum[rand() % stringLength];
}

int main()
{
    srand(time(0));
    for(int z=0; z < 21; z++)
    {
        cout << genRandom();

    }
    return 0;

}

My question is: Will generating a random string with rand() be enough, or is there a more accepted method of generating salt, or a library that can do it for me?

P.S When I searched StackOverflow, I could really only find articles on PHP and C#.

Community
  • 1
  • 1
haet244cut
  • 33
  • 1
  • 1
  • 7
  • Have a look at http://stackoverflow.com/q/7114043/212870 – Alan Stokes Apr 30 '16 at 13:36
  • I think you may have misunderstood my question. I'm not doubting the randomness of rand(). I was asking if there was a more well-known way of doing this that more people use and trust. (e.g some component of a crypto library) – haet244cut Apr 30 '16 at 14:16
  • Just to add on to my question, I have already successfully programmed this in python, and used os.urandom(n) to generate salt, but a) python is a little too slow, and b) something about how python manages strings tells me I shouldn't be using it to manage passwords. disclaimer: this is just my opinion, I don't want to start a flamewar – haet244cut Apr 30 '16 at 14:21
  • You should be doubting the randomness of `rand()`; it's pretty terrible. – Alan Stokes Apr 30 '16 at 14:39

1 Answers1

2

If you really just need a salt, i.e., something you can hash with a password to make the hash unique, then it just needs to be unique. In particular it doesn't need to be random or unguessable in any way.

I would concatenate the real time system clock with a counter.

Using the system clock guarantees that values will be unique for different runs of my program, and using the counter guarantees that values will be unique within the same run of my program.

This is appropriate for server-type scenarios where the same process handles lots of passwords. If your program might run many times per second, or have many instances running in parallel, add the process ID too. If your process is distributed, include the server IP address or MAC.

It's also fine to call whatever version of uuidgen() your system has, OR to use a real cryptographic random number generator.

Note that lot of implementations use really short salts, even though keeping the salt short is completely unnecessary. Don't do that, because it makes it hard to make sure they're unique.

Matt Timmermans
  • 53,709
  • 3
  • 46
  • 87
  • OK thanks for the answer, but I have a few questions. 1) Are you saying a CSPRNG would be overkill/not usable? And 2) I swear I've read in many places that seeding with the system clock is a _really_ bad idea, does this not apply to this scenario? – haet244cut Apr 30 '16 at 14:57
  • 1) Feel free to use a CSPRNG if you want . (I added that to the answer). It's not required, but in a lot of environments it's easy and it'll certainly do. 2) There are lots of uses for random number in cryptography. When you need a random number, seeding a PRNG with the system clock is a bad idea, because it's easy for an attacker to guess what the system clocks was. BUT, a salt doesn't need to be random. It only needs to be unique, so incorporating the system clock is fine – Matt Timmermans Apr 30 '16 at 20:24
  • @haet244cut the salt does not need to be random. What Matt is saying is that it needs to be unique. This prevents two people with the same password having their password hash to the same thing. – Steve Apr 30 '16 at 20:24