kosprov/jargon2-api

Fluent Java API for Argon2 password hashing

jargon2-api's Issues

Salt and Options managment

Hello and first of all congratulations !

This in not a issue... more about understanding correctly your implementation.

I'm going to make some statements and would like you to just confirm or not what I understood. Probably what I'm about to write could be a great boost to your implementation popularity, so you could put (in your words) in the documentations.

Please tell me if what is next is correct ?

---

1. Why the SALT is not part of the parameters that should be given during hashing / verification ?

Because the SALT is automatically generated the first time, and integrated into the final result of hashing. Rather it being added at beginning / end / or even blended in the password prior hashing the resulting chars[] is relieved from the DEVELOPER which can concentrate on more important things.

2. If I change the parameters of the hashing process, once I have already a certain amount of saved salted and hashed password in my DataBase, will I still be able to verify them?

Yes. As you can notice in the simple example, instantiation of the hasher is done specifying a certain number of parameters:

These parameters are also INCLUDED (as is the SALT) inside the resulting hash.
So the verification can be done using these specific parameters (extraction of the correct SALT length for example), no matter how different the actual hash object was instantiated.

As an addition to the above, this clever way of doing a "SAVE" of parameters for each hash, also gives the possibility to migrate smoothly the passwords to the new parameters during authentication of users (see the

example and followed explanation)

---

Vert.x's PRNG as Salt Generator

This is not an issue but just for people who are using jargon2 with Vert.x

For now SecureRandomSaltGenerator used by jargon2 does not setSeed() periodically which is recommended.

If you are using Vert.x, please notice:

Since Secure Random from java can block during the acquisition of entropy from the system, we provide a simple wrapper around it that can be used without the danger of blocking the event loop.

So thanks for the flexibility of this great library, we can change the salt generator:

val hasher = jargon2Hasher().saltGenerator {
    VertxContextPRNG.current().nextBytes(it)
}

How to properly check if an encoded hash can be verified?

Currently I'm doing the following to check if the an encoded hash/password can be verified:
verifier.hash(encodedHash).verifyEncoded()
Since I have different encoders (not just argon2).

However this seems overkill and also may throw an exception for other reasons (e.g., empty password).

So my question is if there currently is a better way to achieve this trough the provided API? Or do you recommend implement a check myself (e.g., something like startsWith...)?

Why create new Hasher per invocation

I am reading your code and for every public method invocation of HasherImpl you create a new HasherImpl which I have no clue why. Do you mind explaining?

Could not find appropriate jargon2Backend. Use either a service provider or define its class with -Dcom.kosprov.jargon2.spi.backend

Hi,

I am using your library in one of my minecraft plugins and I have this error:
https://pastebin.com/WppHxW6w

Thanks for your help.

Provide API to retrieve hasher settings of encoded hash

It would be nice to have an official API to retrieve the settings with which a hash has been generated. While these are encoded in the hash and it would be relatively easy to extract them manually, it would be nicer if the library provided a proper abstraction over this and left said parsing to the backend/actual implementations.

Motivation: I would like to automatically re-hash verified passwords if the currently used settings differ from those used when the password was originally hashed. At the moment, determining whether the settings have changed is relatively cumbersome.

Jargon2 fails in module envrioment

So I'm making a plugin for Minecraft server that supports Argon2id as hashing algorithm. The issue is that in my environment i have main app that can be customize by adding plugins. I'm putting jargon2 into a plugin and it does not make use of my plugins classloader as it just a jar with built .class files. It has it's own classloader which loads classes from my jar. No SPI or anything else will be loaded.
All of this can be mitigated by rebuilding app bundling jargon2 in parent classloader but that pretty invasive and against best practices.

I can't get my head around this. Since other libraries that use JNA/JNI can be bundled in plugins just fine without any issue but Jargon2:

1. Backend SPI is out of scope of parent classloader
2. Argument specification doesn't work as well. I get ClassNotFound exception
3. Programmatic backend spec fails silently

What can be done about this? I was told that SPI is actually considered legacy, would it be possible to move jargon2 backend to java modules? Would it help in my case? Is there a way just to bundle backend how it is without the hassle?

I rushed and already moved my db to jargon2 hashes using my site backend (I like how salt is handled). Maybe there is a way to migrate jagron2 hashes to let's say lazysodium?

Serialization and resource leak warnings

Eclipse is reporting a bunch of serialization and resource leak warnings.

There are 7 instances of "The serializable class [classname] does not declare a static final serialVersionUID field of type long" across various classes.

There are also 38 instances of "Resource leak: [something] is never closed" (all in ByteArrayImplTest.java)

Should these be resolved, or ignored with @SuppressWarnings("serial") and @SuppressWarnings("resource") ?