0

I am currently developing a login for my website, (using node.js and MySQL) and would like some feedback on the password hashing code. 

const crypto = require('crypto');

function RandomSaltString(length) {

    return crypto.randomBytes(Math.ceil(length/2))//I have absolutely no idea what this is
        .toString('hex')        //And this
        .slice(0,length);      //Well I think know this thought

};

function Hash(password, salt) {
    var hash = crypto.createHmac('sha512', salt);
    hash.update(password);

    return hash.digest('hex');
};

function preparePasswordForStorage(password) {

    var salt = randomString(20);
    const hashedPassword = hashFunc(password, salt);

    //Will encrypt the hashed password and salt here once I figure it out.

    return {
        hashedPass: hashedPassword,
        salt: salt      //Will be stored in db directly after this.
    }
};
schroeder
  • 125,553
  • 55
  • 289
  • 326
user109321948492842303
  • 31
  • 1
  • 4

1 Answers1

1

Two issues I see:

  • the salt size is recommended to be the size of the hash, which would be 64 bytes in this case, however a 10 byte salt isn't terrible.
  • You only have one iteration of the hash. You should have a minimum of 10,000 iterations (ideally more) of the hash, to help make it brute force resistant.

Having said that, why are you doing your own password hashing code? Use PBKDF2, bcrypt, scrypt or Argon2. You're reinventing the wheel for no good reason.

Swashbuckler
  • 2,155
  • 8
  • 9
  • Use an Argon2 binding. Password hashes partially makes up for weak passwords by making both a cracker and legitimate parties to do extra work. If you're doing that then you want to force the cracker to do as much work as possible and you want your own computer to that work as efficiently as possible. Argon2 is best because it uses operations that x64 computers are good at. PBKDF2 is easy to crack using GPUs. Bcrypt can't be brute forced efficiently using GPUs or Intel CPUs, but can be done efficiently on other kinds of hardware. Scrypt is ok if you give it a lot of time, but Argon2 is better. – Future Security Mar 01 '19 at 18:30
  • Ive done some research now. And I really really want to reinvent the wheel here. I bet I can do better than a existing libary. What if I use ALOT of iterations and different algorithms (randomly) for the iterations? sha512, sha256, md5 whatever there are. – user109321948492842303 Mar 01 '19 at 19:29
  • 2
    @user109321948492842303 You clearly do **not** have the experience to reinvent the wheel. We don't need more square wheels, they don't work very well. Don't be a [Dave](https://security.stackexchange.com/q/25585). – AndrolGenhald Mar 01 '19 at 19:36
  • @AndrolGenhald Maybe I dont. But I still will for my application, you can help or not help. I wont be releasing anything, so you wont have any more square wheels anyway. – user109321948492842303 Mar 01 '19 at 19:43
  • @user109321948492842303 No. That's not any better than PBKDF2. That has already been proposed many times. No one is an expert in any subject after two hours of "research". There really isn't much room to improve on Argon2 until hardware and chip fabrication change drastically unless someone is aiming for a completely different scenario than ordinary key derivation or password authentication. (Argon2 was a collaboration of experts and has been seriously scrutinized.) Finally, comments are not the appropriate place to ask questions that should be a new post. Only clarification requests are okay. – Future Security Mar 01 '19 at 20:25
  • @Swashbuckler Im using PBKDF2 with a key length of 128 and the salt is also 128 bytes or bites or whatever they where at this time. Also, a million iterations. Am I good? – user109321948492842303 Mar 02 '19 at 08:48
  • @SwashBuckler Also im using a 40+ char pepper. (Stored in my sourcecode(on a different server than the db)) – user109321948492842303 Mar 02 '19 at 09:05