Discussion between li x and AndrolGenhald

Feeds

14:07

0

Q: Is it good practice to store information about a subkey inside a hash?

I recently wrote out a small javascript library that allows you to verify identity server password hashes in nodeJS. While I was doing the research I learnt that the type of hash, iterations and salt length is encoded by adding extra bytes to the final hash that is given in base64 afterwards. Sp...

AndrolGenhald

What are "identity server password hashes"? All I could find is this which doesn't appear to hash passwords.

li x

@AndrolGenhald Identity server is how .net core api's handle authentication

AndrolGenhald

Aha, this appears to be what you're talking about. It's using PBKDF2 with 10,000 iterations by default (which seems a bit low, but that's a separate question).

Possible duplicate of When hashing passwords, is it okay to store the algorithm used right there in the database?

li x

@AndrolGenhald There's a difference to the question you flagged, the algorithm type, iterations and salt length are encoded directly inside every hash as well part of it alongside a subkey.

AndrolGenhald

Sorry, I overlooked that you were wondering about the salt as well. This should answer that.

li x

14:07

I think your misunderstanding my question, this is creating a subkey using PBKDF2 correct, but that is only the subkey. After we've generated that hash we store it as part of a buffer of which the first inital 26 bytes also includes information about the inital encoding before it's turned into base64. Those questions don't answer the security implications of embedding details directly into the output base64 hash.

AndrolGenhald

I believe I do understand the question, but perhaps this is a better duplicate.

Password hashing methods generally store all information needed to verify the password as a single value

li x

This isn't a duplicate as in this case the salt/details are separate from the hash to be verified.

So it's normal practice to store the salt length, encryption type and iterations as part of the output hash?

To essentially be used to later verify the hash?

I'm working on this open source package that allows you to verify identity server hashes in your browser or nodeJS server github.com/LiamDotPro/node-identity-server

In the node world normally you'd use something like bcrypt but that only returns back you a key and they don't add the encoding information as standard back, so presumably it's not used to verify hashes or not needed.

AndrolGenhald

If we're talking about the same thing I believe the salt is indeed stored

li x

Eventually I'd like to be able to provide a lot of what identity server does but in the browser or node, but for the moment it's just a little bridging library. I want to know why this method is better practice or more secure, I feel like the questions you've linked don't answer my concerns or question :/

AndrolGenhald

bcrypt stores all of this in a single value as well

li x

14:14

Do you have a link handy?

If not I can google it

AndrolGenhald

Bcrypt

bcrypt is a password hashing function designed by Niels Provos and David Mazières, based on the Blowfish cipher, and presented at USENIX in 1999. Besides incorporating a salt to protect against rainbow table attacks, bcrypt is an adaptive function: over time, the iteration count can be increased to make it slower, so it remains resistant to brute-force search attacks even with increasing computation power. The bcrypt function is the default password hash algorithm for OpenBSD and other systems including some Linux distributions such as SUSE Linux. There are implementations of bcrypt for C, C#,...

github.com/aspnet/Identity/blob/… is where the salt is copied for .NET Identity

li x

Aye I saw I'm really familliar with the process

I can see where you coming from with the duplicate

If you think that's right I'll mark or delete the question. Though thanks for the information.

AndrolGenhald

I'm not sure that you understand how salts work, your verifyPassword function is generating its own salt, which will cause verification to always fail

This is a good overview of how password hashing works in general if you want to read up on it

or maybe I was wrong, I'm just confused by let salt = await crypto.randomBytes(16);, but it looks like you're overwriting it later?

li x

huh? are you talking about my library?

Oh right, it currently works. Though that could be replaced with a standard buffer, general good implementation means you should use inefficient methods to mitigate timing based attacks

thanks for the link I'll make sure to read more :-)

AndrolGenhald

"general good implementation means you should use inefficient methods to mitigate timing based attacks" sounds a bit off to me

using constant time methods is the general solution

Just making things take longer doesn't necessarily help as long as it always makes it take longer by the same amount.

li x

14:46

You'll notice in the Microsoft implementation they specifically haven't optimized the comparision of bytes, I think it's somewhat common practice.

AndrolGenhald

If your talking about ByteArraysEqual the intent isn't for it to be slow, it's for it to be constant time (based on the length of a and b in this case, it fails early if they're not the same length)

3

Q: String Comparison Timing Attack in Plain English

Could someone please tell me what a string comparison timing attack is in simple terms? I have Googled this, but all the explanations are very technical. Also, is this attack an better than a brute force attack? Please correct me if I am wrong, but I believe this attack is used to crack passwords.

attacks password-cracking

li x

15:21

That's a great example!

I vaguely understood the reasoning for doing it but I think this fills the gap exactly.

Transcript for

Discussion between li x and AndrolGen…