Hello! This is mostly a question about your library.

I noticed a lot of the methods either accept a string or return a string, such as addSalt(String). I noticed when you convert these back to byte[], you are using UTF 8. When I take an existing salt, that's just a byte[], and try to convert it to a String using new String(bytes, StandardCharsets.UTF_8) I always get an error about it being an invalid salt. These are salts that were generated prior to using your library.

I am curious how UTF 8 works in this situation. Normally, byte values >127 are interpreted as surrogate pairs, meaning the character is composed of 2 or more bytes. Some sequences of bytes are not valid unicode, as some ranges are reserved. I am curious how UTF 8 handles this situation and was hoping you knew off hand. Is it replacing those byte sequences with a default character (like those that appear as a square symbol or question mark diamond), or is it keeping the byte sequences as-is?

Would it be possible to create overloads of addSalt taking a byte[] so I could use this library? In case you're curious, when I persisted my passwords and salts to a database, I used Base64 to encode byte[] rather than UTF 8.

Add banner to involve more people with the project

This project should be almost zero dependency.

Is your feature request related to a problem? Please describe.
com.password4j.Utils uses java.security.AccessController (at line 508)

With JDK17, java.security.AccessController is deprecated and marked for removal.
https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/security/AccessController.html

.... this is in conjunction with the deprecation of SecurityManager
https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/SecurityManager.html

.... additional documentation on the matter is found here:
https://openjdk.org/jeps/411

Describe the solution you'd like
A code update that does not depend on a deprecated class.
Naturally, for now, at least while using JDK17, things still work, but wanted to make sure you knew about this.

Describe alternatives you've considered
Apologies---I'm not currently aware of a course of action to recommend.

Thank you.

Describe the bug
Conversion from String to byte[] changes the original generated salt in Argon2

To Reproduce

Hash hash = Password.hash(test.plainTextPassword).addRandomSalt().withArgon2();
assertTrue(Password.check(test.plainTextPassword, hash));  // fails

in particular what is generated by HashBuilder#addRandomSalt() is different from Hash#salt

Expected behavior
HashBuilder#addRandomSalt() == Hash#salt

Environment:
1.7.3+

Describe the bug
I've been using Argon2 in an application not written in Java. Now, I want to start checking those Argon2 hashes in my Java application using password4j.

My other application has generated an Argon2 hash that looks like this:

$argon2id$v=19$m=16384,t=2,p=1$nlm7oNI5zquzSYkyby6oVw$JOkJAYrDB0i2gmiJrXC6o2r+u1rszCm/RO9gIQtnxlY

The clear text password for this is Test123!. If I fill in those values on this online checker, things work exactly the way I want it:
https://argon2.online

But when I use password4j, I always get false when running it like this:

        boolean verified = Password.check("Test123!", "$argon2id$v=19$m=16384,t=2,p=1$nlm7oNI5zquzSYkyby6oVw$JOkJAYrDB0i2gmiJrXC6o2r+u1rszCm/RO9gIQtnxlY").withArgon2();
        System.out.println(verified);

I've also noticed that it seems to ignore the configuration values in the hash itself (such as t=2 and p=1). I've tried setting them to match the hash, but that shouldn't be necessary...

To Reproduce
See Java code above.

Expected behavior
I expect the above to yield true.

Environment:

• OS: Ubuntu 20.04
• JDK Oracle JDK 17
• Version 1.6.2

Additional context
N/A.

ho do i stop this appearing every time I start java?

|
| Password4j
+ \ .: v1.7.3 :.
\.G_.*=.
`(H'/.| ✅ Argon2
.>' (_--. ✅ scrypt
_=/d ,^\ ✅ bcrypt
~~ )-'-' ✅ PBKDF2-SHA1/SHA384/SHA512/256/SHA256/SHA512/224/SHA224/SHA512
/ |
' '
⭐ If you enjoy Password4j, please star the project at https://github.com/Password4j/password4j
🪲 Report any issue at https://github.com/Password4j/password4j/issues

Describe the bug
This issue happen in random device, verify function Password.check(password, hash).withBCrypt() always return true, even with wrong password.

To Reproduce
App with login (username & password) system.

Expected behavior
Verify function return correct value.

Environment:

• OS: Windows

• IDE: Android Studio 4.2 Canary 12

• Device spec with working Verify function
  

• Device spec with Verify function always return true
  

• Other
  
  

Additional context
Here's my code and result:

Code

Result

Thankyou firaja :D

Implementation of Lyra2

SecureString.toString returns a masked value like [***]. However, the number of * returned is taken from the number of characters of the contained password, exposing it's length. I suggest to always return the same constant (e.g. [*****]) instead.

Describe the bug
I am considering migrating from com.lambdaworks:scrypt to com.password4j:password4j. The derived key length of hashes generated by the lambdaworks implementation is 32 bytes, while password4j's scrypt implementation produces 64 byte derived keys. This is fine. The problem is that when checking against an existing hash, password4j's scrypt's check() method requires that the input hash's derived key be 64 bytes. If the derived key length of the input hash is not 64 bytes then check() returns false (com.password4j.SCryptFunction line 151).

To Reproduce
Verify with these (valid) hashes generated by com.lambdaworks:scrypt:

Test hash 1: password = "Hello world!"
$s0$e0801$fl+gNAicpGG4gLMkUTCvLw==$N5wE1IKsr4LPBoetJVW6jLzEH4kTVXuKGafvAA8Z+88=

Test hash 2: password = "!@#$%^&*()_+";
$s0$e0801$1uFqXES/I17Wj6W85SLXNA==$GvPgo5L9KMtde+jpR5rRd5U7Qa6mcRMFAoy5E50iBro=

Expected behavior
I would expect that password4j's HashingFunction.check() methods respect the derived key lengths of the input hashes they are checking against. Looking at the code for password4j's argon2 implementation it does in fact appear to respect the derived key length of the input hash.

It would also be nice if password4j's scrypt had a configurable derived key length, similar to argon2's "hash.argon2.length".

Environment:

• n/a

Additional context
n/a

NOTE
If you agree with the above change then I would be happy to submit a pull request.

The project has a lot of jUnit tests but they do not share a common structure: this may lead to uncovered cases for some algorithm.

The test suite regarding the alogirthm should have a defined structure.

PS: by now no issue found.

Describe the bug
Library cannot be loaded on Java8 JVMs

To Reproduce
attempt to use the library on java 8

ERROR java.lang.UnsupportedClassVersionError:
com/password4j/jca/providers/Password4jProvider has been compiled by a more recent version of the Java Runtime (class file version 53.0), this version of the Java Runtime only recognizes class file versions up to 52.0

Expected behavior
Java8 JVMs should be able to load Password4j

Environment:

• OS: Mac 0S
• JDK: Zulu 8.0.372
• Version: 1.7.0

Additional context
Add any other context about the problem here.

Issue Description:
Application throws a NoClassDefFoundError for Password class even though it is present in the final application build.

Steps to reproduce:
Simply use the Password class to create an scrypt hash as mentioned in the password4j getstarted page.

Expected behavior:
Generate a hash without Exception.

Environment:

• OS: mxlinux
• JDK Amazon Corretto
• Version 8
• enterprise ear file deployed on wildfly server

Additional context:
This is happening because the static block of Password.java is not loading due to an eventual NPE that occurs in the library code. This in turn stops this class from loading and manifests as a java.lang.NoClassDefFoundError in the application.

Please confirm if this is an issue or requires any configuration change.

Exception stack trace:
Caused by: java.lang.NullPointerException
at com.password4j.AlgorithmFinder.getAllPBKDF2Variants(AlgorithmFinder.java:346)
at com.password4j.Utils.printBanner(Utils.java:582)
at com.password4j.Password.(Password.java:37)

Problem in line number 346 of AlgorithmFinder class. The provider creating the problem is ThreadLocalSecurityProvider. The size says 4 but returns null.

    @firaja That works like a charm, thanks for the quick support and fix!

I accidentally noticed something else though. See this test:

    @Test
    public void test_using_function_directly()
    {
        String hash = "$argon2id$v=19$m=16384,t=2,p=1$nlm7oNI5zquzSYkyby6oVw$JOkJAYrDB0i2gmiJrXC6o2r+u1rszCm/RO9gIQtnxlY";
        Argon2Function function = Argon2Function.getInstanceFromHash(hash);

        boolean test1 = Password.check("Test123!", hash).with(function);
        assertTrue(test1);

        boolean test2 = function.check("Test123!", hash);
        assertTrue(test2);
    }

When using the function directly to check, it doesn't work. This is not the case with for example Bcrypt. Not a big deal for me, I'll use the first way, but I thought you should know. Maybe extract this to a separate issue? Or ignore, it's up to you. :)

Originally posted by @anton-johansson in #92 (comment)

Complete the GitHub wiki https://github.com/Password4j/password4j/wiki

Each method of SystemChecker class returns an int, but for algorithm like Argon2 there is the need to return both the number of iterations and memory, since memory must be lowered if the minimum execution time required cannot be met.^{See Section 9}

It could return a prototype of the function.

Result result = SystemCheker.find...(...)

result.getPrototype() // instance of AbstractHashingFunction
result.getElapsed() // this may be not equal to the desired minimum computational time

Some classes and function use bad naming conventions like BCryptFunction instead of BcryptFunction or withSCrypt() instead of withScrypt().

When using hash(String) the salt is automatically generated as array of bytes, then converted into String and passed to hash(String, String) and in many cases i converted into array of bytes.

This double conversion is useless, even if the drop in performance is minimal.

The usage of String#getBytes() inside the library without any explicit charset make the result depend on the JKD implementation of Charset.defaultCharset().

If a target system uses a different default charset and/or declares a different file.encoding property, hashing or checking passwords may not work properly.

Solution

Find all String#getBytes() and replace them so that the charset (UTF-8) is explicit.

Describe the bug
in the documentation (for Argon2) it is mentioned that the SALT is stored in the computed hash and therefore automatically used during a call to check, which is not the case and needs to be specified again manually during a verification call.

When the documentation refers to the hash, does it refer to the com.password4j.Hash object ? or the computed hash (hash.getResult()) ? it maybe not a bug but the documentation is unclear on this point.

To Reproduce

psw4j.properties :

global.random.strong=true
global.pepper=MyPepper
hash.argon2.memory=4096
hash.argon2.iterations=160
hash.argon2.length=128
hash.argon2.parallelism=2
hash.argon2.type=id
hash.argon2.version=19

Test :

Hash hash = Password.hash("my password").addRandomSalt().withArgon2();
String result = hash.getResult();
Password.check("my password", result).withArgon2()  <== return false

Working code :

Hash hash = Password.hash("my password").addRandomSalt().withArgon2();
String salt = hash.getSalt();
String result = hash.getResult();

Password.check("my password", result).addSalt(salt).withArgon2();  <== return true

Expected behavior
If salt is already embedded in the computed hash (hash.getResult()) it need to automatically extracted from here (if it exists) in the verification function , this would avoid having in database (result has saved in db in my case) a column for the result and another column which would contain the salt.

Environment:

• OS: Windows 10 Pro
  java version "11.0.9" 2020-10-20 LTS
  Java(TM) SE Runtime Environment 18.9 (build 11.0.9+7-LTS)
  Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.9+7-LTS, mixed mode)

Describe the bug
If developing out of maven and project structure is not "/src/main/resources/.." properties file can't be found. Also can't set path manually.

To Reproduce
Develop a simple application with Netbeans (Ant build) and try to run.

Expected behavior
Load properties as defined in properties file.

Environment:

• OS: Windows 10
• JDK OpenJDK 11.0.2
• Version 1.3.1

Additional context
Project structure:

• project root
  |
  • resources (x/y/z/abc.properties)
    |
  • src (...)
    |
  • test
    (etc.)

• Argon2id with a minimum configuration of 15 MiB of memory, an iteration count of 2, and 1 degree of parallelism.
• scrypt with a minimum CPU/memory cost parameter of (2^16), a minimum block size of 8 (1024 bytes), and a parallelization parameter of 1.
• For legacy systems using bcrypt, use a work factor of 10 or more.
• PBKDF2 with a work factor of 310,000 or more and set with an internal hash function of HMAC-SHA-256.

Is your feature request related to a problem? Please describe.
Would like to check if hash actually need rehashing before wasting resources on recalculating it

Describe the solution you'd like
A needRehash method returning boolean (perhaps on HashChecker object) that shows if parameters are up to date without necessarily calling HashChecker#update.
I'm guessing that in current state, calling this method on hash with same parameters would generate new hash anyway, even if it's parameters are the same as before

Describe alternatives you've considered
Right now we are reading paramters from the encoded hash itself (e.g. $argon2id$t=...), but it sounds like a job that can be done by the library not the developer.

From sonarcloud report: Casting may be required to distinguish the method to call in the case of overloading

Noncompliant

public void example() {
  for (Foo obj : (List<Foo>) getFoos()) {  // Noncompliant; cast unnecessary because List<Foo> is what's returned
    //...
  }
}

public List<Foo> getFoos() {
  return this.foos;
}

Compliant

public void example() {
  for (Foo obj : getFoos()) {
    //...
  }
}

public List<Foo> getFoos() {
  return this.foos;
}

Describe the bug
The ScryptFunction#hash generates a correct output but appends a $s0. It might be a blunder while coding...
To be checked where it came from (maybe some wrong specifications).

To Reproduce
Just hash anything with scrypt

Expected behavior
No $s0 should be prepended

Environment:

• Any

Additional context

Describe the bug
just to let you know - while playing with your implementation I found some typos on your wiki

BcryptFunction on wiki vs BCryptFunction in source
ScryptFunction on wiki vs SCryptFunction & findWorkFactorForSCrypt & findResourcesForSCrypt

The Hash class should store the hash in the form of byte[]. This data must not contain the parameters that are normally encoded in the final hash String by the algorithm (like the salt, number of iterations, memory, etc...)

Hash hash = Password.hash(...)...
hash.getBytes();

When logRounds is 31 (the max allowed value), this shift results in a negative number. Effectively the rounds is set to 0.

Is there any plans for Password4J to be modular compatible?

Is your feature request related to a problem? Please describe.
In a situation where there are different remote java repositories for the same company, I would like to standardize all the password hashing algorithms among them. My goal is that all of them use password4j. I manage the property file (psw4j.properties) and they manage their code. Currently, the salt length can only be changed via code (not via properties), which can lead to inconsistencies between repositories.

Describe the solution you'd like
I would like to be able to have the salt length a configurable property like global.salt.length=16 which is used in the class SaltGenerator.

Describe alternatives you've considered

• I could use the default (hardcoded) length of 64 but that is a bit too long for my taste.
• I would need to make sure that each remote dev team uses the same length by clear communication and in-depth code review (which is a lot more work for me).

Additional context
great library by the way, huge fan!

Describe the bug
We are looking to use password4j in an application that has a strict security policy, meaning that a static initializer will prevent the Password class from loading. We would like to add additional exception handling to allow password4j to be usable in this environment.

To Reproduce
Run password4j with a heavily restricted security policy - e.g. no FilePermissions.

Expected behavior
Password4j should be usable even when no access to psw4j.properties due to a restrictive security policy.

Environment:

• OS: [All]
• JDK [OracleJDK 11 and 17]
• Version [1.7.3, 1.8.1]

Additional context
We have a fix ready. I will supply a PR.

Describe the bug
Correcy bcrypt hash failed to be verified.

To Reproduce
Call:

String hash = "$2b$12$fRnFJP6V1PybWlgvGYYeEutnpgtmYPBy94UPwpKfH2J5GbxA22cFC";
String password = "1234";
boolean verified = Password.check(password, hash).withBCrypt();

verified is false!

Expected behavior
verified should be true!

Environment:

• OS: Windows 10 2011
• JDK 11
• Version group: 'com.password4j', name: 'password4j', version: '1.4.0'

Workaround

char minor = passwordHash.charAt(2);
String rounds = passwordHash.replaceFirst("\\$.{2}\\$([0-9]+)\\$.*", "$1");
boolean verified = Password.check(password,passwordHash).with(BCryptFunction.getInstance(com.password4j.BCrypt.valueOf(minor), Integer.parseInt(rounds)));

The project doesn't really need a logging system that could interact negatively with the logging system of the target environment.

Describe the bug
Since v1.7 the default encoding was changed from UTF-8 to ISO 8859-1.
When hashing strings with characters not supported by ISO 8859-1, they get replaced by the ? character, leading to incorrect hashes.

To Reproduce
Hash a string with unsupported characters (e.g. ’) with both v1.6.x and v1.7.x with different results.

Expected behavior
Hashes don't differ for different versions.

Balloon hashing (Wikipedia), is similar to Argon2, which has proven memory-hardness properties. But it claims to match the performance of similar algorithms. It seems easy to implement. And it is recommended by NIST password guidelines.

There are Rust and Python implementations for references.

Balloon actually wraps existing hash functions, so we may need a generic type over MessageDigest for any standards non-space-hard cryptographic hash function.

From sonarcloud report:

When testing exception via @Test annotation, having additional assertions inside that test method can be problematic because any code after the raised exception will not be executed. It will prevent you to test the state of the program after the raised exception and, at worst, make you misleadingly think that it is executed.

You should consider moving any assertions into a separate test method where possible, or using org.junit.Assert.assertThrows instead.

Alternatively, you could use try-catch idiom for JUnit version < 4.13 or if your project does not support lambdas.

Compliant

// This test correctly fails.
@Test
public void testToString() {
    Object obj = get();
    Assert.assertThrows(IndexOutOfBoundsException.class, () -> obj.toString());
    Assert.assertEquals(0, 1);
}

Describe the bug
i have implemented Password Encryption with [password4j/Argon2] .

• Successfully Encrypted password
• Password validation not working, always showing false.

To Reproduce
#Step1#: Encryption
Hash hash=Password.hash(userEnteredPassword).addSalt(salt).addPepper(pepper).withArgon2();
#Step2#: Validation
boolean verification=Password.check(userEnteredPassword,hash..toString())
.addSalt(salt))
.addPepper(pepper)
.withArgon2();

 # Details# : 
      userEnteredPassword : yesh599_33 
      salt                                : yesmykaps599
      pepper                          : 80953

#Argon2() Config Details#:
hash.argon2.memory=4096
hash.argon2.iterations=99
hash.argon2.length=128
hash.argon2.parallelism=4
hash.argon2.type=id
hash.argon2.version=20

Expected behavior
Password verification always showing false.

Environment:

• MAC: [iOS]
• JDK [Open JDK 11]
• JVM Character Set (UTF-8)

Additional context
Kindly let me know, if any changes required.

Thanks for this great project
A problem is that it is not possible to use the hashing based on raw byte arrays.
I tried to use Argon2 hashing with a raw byte array as salt and a password consisting of raw bytes.
(This is the way argon2d and argon2id are used to decrypt Keepass databases)

However it is impossible to insert these arrays. It can only be done by creating a String out of the bytes and then pass the strings. However, under the hood the Strings/CharSequences are converted to bytes again. However some UTF8 decoding takes place, not resulting in the original byte arrays!

It would be great to have a version also including hash functions that take byte arrays as input

Feature that automatically updates the hash after the verification in case the configurations are changed

You shouldn't add the slf4j nop impl to the classpath ( https://github.com/Password4j/password4j/blob/master/pom.xml#L53) as it causing package conflict issues for modular applications. Usually application using this library brings proper slf4j impl.

 error: module dev.xxx.openjdk.playground reads package org.slf4j.impl from both org.slf4j.nop and org.apache.logging.log4j.slf4j

There is currently no way of disabling the printBanner from showing in console without using a properties file.
To Reproduce
Instantiate password4j classes without a psw4j.properties.
Expected behavior
A way of disabling the printBanner without creating a psw4j.properties.

Environment:

• OS: MACOS 13
• JDK 17
  

thanks!

Describe the bug

The commit for issue #64 erroneously removed the "$s0" prefix from scrypt hash strings. The "$s0" prefix is present in the hash string generated by the original lambdaworks scrypt library's SCryptUtil.scrypt() function (from package: "com.lambdaworks:scrypt:1.4.0"). From the lambdaworks scrypt library's README.md, the "$s0" prefix indicates "version 0 of the format with 128-bit salt and 256-bit derived key".

To Reproduce

Using the scrypt library, call com.lambdaworks.crypto.SCryptUtil.scrypt() with any values for parameters passwd, N, r, and p. The returned hash string will have the "$s0" prefix.

Expected behavior

Password4j's scrypt hash strings should have the same format as hash string generated by the lambdaworks scrypt library, which includes the "$s0" prefix.

Environment:

• OS: Any
• JDK Any
• Version 1.6.0

Additional context