Add support for the Argon2 hashing algorithm that was the winner of the most recent "Password Hashing Competition" (https://password-hashing.net/). The public repo for the algorithm can be found here:
Specification PDF here:
There is some information here about using it with Java:
and there is an online generator here that can be used to validate the output from a new Lucee function:
Suggest the name of the function would be:
with parameters of:
Variant (either Argon2i, Argon2d or Argon2id)
Text Input (the value to be hashed)
Salt (the salt to be used)
Parallelism Factor (a number between 1 and 10
Memory cost (a number between 8 and 100000)
Iterations (a number between 1 and 20)
Hash Length (a number between 4 and 100)
- I've just taken a look at the implementation and there are few things that don't seem right:
1) There is no "salt" parameter for the `GenerateArgon2Hash` function. My understanding is a salt is required for an Argon2 hash. If you take a look at https://argon2.online/ it will not let you generate an Argon2 hash without one.
2) The `Argon2CheckHash` function has an option to tell it which "variant" to use for the hashing, but like the other parameters passed into `GenerateArgon2Hash`, you don't need to tell the check function the variant as it is part of the hash, right at the beginning, e.g. `$argon2i$`
3) In the `core-base.fld` file the description for the `hash` parameter of `Argon2CheckHash` is "Degrees of parallelism, a number between 1 and 10." which is clearly not what the hash is 😀
Otherwise, it appears to be functioning correctly.
Just want to note regarding the “missing” salt parameter, that the GenerateArgon2Hash function actually creates a salt for you. I believe it is pretty typical for these sorts of hash implementations to generate a salt for you if one is not provided. I suppose it might be more complete to allow a salt to be passed in, but a salt is definitely being used internally.
I saw your blog post, and you can see that in your example hash the salt is included:
The $ is a delimiter, and the salt comes before the hash I believe, so in the hash above W7SEywipzFzD847FdFzojQ is the salt, and qr+tDogG/BaOL7NZCQ5f0Bb4I9KPZCP7g4npVo+AncA is the actual hash.
What I would like to know (this is a general question, not directed at you) is why in the current implementation: GenerateArgon2Hash.java#L60-L61 the hash is verified right after being generated? Is it possible for it to fail? As it stands now, every hash generation will take twice as long, since your input will actually get hashed twice when GenerateArgon2Hash is called.
- Interesting, I'm not all that familiar with Argon2 so I wasn't aware of the structure, but that makes sense, but it would be more complete to allow you to pass your own hash in, but it could be an optional parameter as long as the "default" hash is random and not the same every time.
With regards to it checking the hash after generation, that does seem a little strange and like you say, would mean it takes twice as long as needed.
is right. I’ve fixed my mistake in core-base.fld and also I’ve removed the unnecessary variant argument. Thanks for the input. This is the pull request .