Password4j is a user-friendly cryptographic library that supports Argon2, Bcrypt, Scrypt, PBKDF2 and various cryptographic hash functions.

Overview

logo

Build Status Maven Central Java 8 or higher Android 5.0 or higher Awesome

Quality Gate Status Security Rating Reliability Rating Maintainability Rating Coverage

Password4j is a Java user-friendly cryptographic library for hashing and checking passwords with different Key derivation functions (KDFs) and Cryptographic hash functions (CHFs).

Algorithms can be configured programmatically or through a property file in your classpath see Configuration section.

The configurations are mostly dependent on your environment. Password4j delivers a tool that can create a set of optimal parameters based on the system performance and the desired maximum computational time see Performance section.

Hash Verify

The library fully supports Argon2, BCrypt, SCrypt and PBKDF2 and can produce and handle cryptographic salt and pepper.

Documentation

Wiki javadoc

The full documentation can be found here. For a quick start you can follow the instuctions in the README.md.

The javadoc can be found here.

Installation

Password4j runs on Java 8 or higher versions by any vendor. It is supported by Android API 21+ as well.

The artifacts are deployed to Maven Central.

Maven Maven

Add the dependency of the latest version to your pom.xml:

<dependency>
    <groupId>com.password4j</groupId>
    <artifactId>password4j</artifactId>
    <version>1.5.2</version>
</dependency>

Gradle Gradle

Add to your build.gradle module dependencies:

repositories {
    mavenCentral()
}

dependencies {
    implementation 'com.password4j:password4j:1.5.2'
}

Scala SBT Scala SBT

Add to the managed dependencies of your build.sbt the latest version:

libraryDependencies += "com.password4j" % "password4j" % "1.5.2"

Usage

Password4j provides three main features: password hashing, hash checking and hash updating.

Hash the password

Here it is the easiest way to hash a password with a CHF (BCrypt in this case)

Hash hash = Password.hash(password).withBCrypt();

Salt and pepper may be optionally added to the builder (PBKDF2 in this case):

// PBKDF2 with salt 12 bytes long (randomly generated).
Hash hash = Password.hash(password).addRandomSalt(12).withPBKDF2();

// PBKDF2 with a chosen salt.
Hash hash = Password.hash(password).addSalt(salt).withPBKDF2();

// PBKDF2 with chosen salt and pepper.
Hash hash = Password.hash(password).addSalt(salt).addPepper(pepper).withPBKDF2();

// Custom PBKDF2 (PBKDF2 with HMAC-SHA512, 64000 iterations and 512bit length).
Hash hash = Password.hash(password).with(PBKDF2Function.getInstance(Hmac.SHA512, 64000, 512));

The same structure can be adopted for the other CHFs, not just for PBKDF2.

Verify the hash

With the same ease you can verify the hash:

boolean verified = Password.check(password, hash).withBCrypt();

Salt and pepper may be optionally added to the builder (PBKDF2 in this case):

// Verify with PBKDF2.
boolean verification = Password.check(password, hash).withPBKDF2();

// Verify with PBKDF2 and manually provided salt.
boolean verification = Password.check(password, hash).addSalt(salt).withPBKDF2();

// Verify with PBKDF2 and manually provided salt and pepper.
boolean verification = Password.check(password, hash).addSalt(salt).addPepper(pepper).withPBKDF2();

The same structure can be adopted for the other algorithms, not just for PBKDF2. Take in account that Argon2, BCrypt and SCrypt store the salt inside the hash, so the addSalt() method is not needed.

// Verify with Argon2, reads the salt from the given hash.
boolean verification = Password.check(password, hash).withArgon2();

Some algorithms encode into the hash the parameters that were used to compute that hash, notably BCrypt, SCrypt, and Argon2. When checking a hash, you can use the parameters from the hash rather than Password4j's configured defaults.

// Verify with Argon2, reads the salt and parameters from the given hash.
boolean verification = Password.check(password, hash)..with(Argon2Function.getInstanceFromHash(hash)));

Update the hash

When a configuration is not considered anymore secure you can refresh the hash with a more modern algorithm like this:

// Reads the latest configurations in your psw4j.properties
HashUpdate update = Password.check(password, hash).update().withBCrypt();

if(update.isVerified())
{
    Hash newHash = update.getHash();
}

Or if you want to switch from a CHF to another one:

PBKDF2Function pbkdf2 = AlgorithmFinder.getPBKDF2Instance();
HashUpdate update = Password.check(password, hash).update().withSCrypt(pbkdf2);

if(update.isVerified())
{
    Hash newHash = update.getHash();
}

Unsecure Algorithms

Many systems may still use unsecure algorithms for storing the passwords, like MD5 or SHA-256. You can easily migrate to stronger algorithms with Password4j

MessageDigestFunction md = MessageDigestFunction.getInstance("SHA-256");
HashUpdate update = Password.check(password, hash).update().withSCrypt(md);

if(update.isVerified())
{
    Hash newHash = update.getHash();
}

List of supported algorithms

Key derivation Functions Since Notes
PBKDF2 1.0.0 Depending on the Security Services your JVM provides
BCrypt 1.0.0
SCrypt 1.0.0
Argon2 1.5.0
Cryptographic Hash Functions Since Notes
MD Family 1.4.0
SHA1 Family 1.4.0
SHA2 Family 1.4.0
SHA3 FAmily 1.4.0 Depending on the Security Providers your JVM provides

Security of Strings

Strings are immutable objects and once stored in memory you cannot erase them until Garbage Collection. It is always recommended to use char[] instead of String for storing passwords(where possible - If we're talking of a web application, most web containers will pass the password into the HttpServletRequest object in plaintext as String).

An attacker that is able to dump the memory could read the password before you use it as input for Password4j; even if it is read after its usage, it is not guaranteed when the garbage collection occurs: that means that the password may be stored in memory indefinitely and its value cannot be erased.

For this reason Password4j provides a SecureString class that alleviates this problem. The provided char[] is wrapped around SecureString and it is never converted into a String during the process.

You can erase the underlying char[] with clear() method.

SecureString secure = new SecureString(new char[]{...});

Password.hash(secure).withBCrypt();
Password.check(secure, hash).withBCrypt();

secure.clear();
// At this point the underlying char[] = {\0, \0, \0, ...}

In addition to this, you may want to clean the original char[]. With the following code even the source is zeroed:

char[] password = {...}
SecureString secure = new SecureString(password, true);

// At this point password = {\0, \0, \0, ...}

The pepper can be expressed as SecureString as well.

Using SecureString or char[] does not completely defend you from attacks: the Garbage Collector constantly copies objects from the from space to the to space and ereasing the original char[] does not erase its copies; moreover it is never guaranteed that clear() is applied before the garbage collection. For these reasons the usage of SecureString or char[] just reduces the window of opportunities for an attacker.

Configuration

Password4j makes available a portable way to configure the library.

With the property file psw4j.properties put in your classpath, you can define the parameters of all the supported CHFs or just the CHF(s) you need. Alternatively you can specify a custom path with the system property -Dpsw4j.configuration

java -Dpsw4j.configuration=/my/path/to/some.properties ...

Here's a basic configuration (please do not use it in production, but instead start a benchmark session in your target environmentsee Performance section)

### Argon2
hash.argon2.memory=4096
hash.argon2.iterations=20
hash.argon2.length=128
hash.argon2.parallelism=4
hash.argon2.type=id


### BCrypt
hash.bcrypt.minor=b
# logarithmic cost (cost = 2^12)
hash.bcrypt.rounds=12


### SCrypt
# N
hash.scrypt.workfactor=16384
# r
hash.scrypt.resources=16
# p
hash.scrypt.parallelization=1
# length
hash.scrypt.derivedKeyLength=64

### PBKDF2
# with HMAC-SHA256
hash.pbkdf2.algorithm=SHA256
# 64000 iterations
hash.pbkdf2.iterations=64000
# derived key of 256bit 
hash.pbkdf2.length=256


### Legacy MessageDisgest
# algorithm
hash.md.algorithm=SHA-512
# append/prepend salt
hash.md.salt.option=append

Additionally you can define here your shared pepper

global.pepper=AlicePepper

and use it like this

// Hash
Password.hash("password").addPepper().withSCrypt();

// Verify
Password.check("password", "hash").addPepper().withSCrypt();

SecureRandom may be instantiated and used through SecureRandom.getInstanceStrong() to generate salts and peppers.

global.random.strong=true

but make sure that your JVM supports it and it points to a non-blocking source of entropy, otherwise you may experience huge performance dropssee SecureRandom.

Performance

This tool must be used in the target system because performances may vary on different environments.

Password4j is delivered with a tool that helps the developers to choose the right parameters for a specific CHF.

The class SystemChecker can be used to find these optimal values.

In the wiki you can find how to configure PBKDF2, bcrypt, scrypt and Argon2 depending on your responsiveness requirements.

Contributing

GitHub issues GitHub closed issues

Please read CONTRIBUTING.md for details on our code of conduct, and the process for submitting pull requests to us.

Versioning

SemVer 2.0.0

We use SemVer for versioning.

For the versions available, see the releases on this repository.

Authors

GitHub contributors

  • David Bertoldi - Main Maintainer - firaja

See also the list of contributors who participated in this project.

License

License

This project is licensed under the Apache License 2.0 License - see the LICENSE file for details

Changelog

GitHub Release Date

See the CHANGELOG.md file for a more detailed description of each release.

Comments
  • Argon2 not working as expected

    Argon2 not working as expected

    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.

    type: bug priority: critical status: confirmed 
    opened by anton-johansson 11
  • SCryptFunction.check() should honor derived0.length

    SCryptFunction.check() should honor derived0.length

    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.

    type: bug good first issue status: confirmed 
    opened by dpatriarche 9
  • Salt not extracted from hash when performing check

    Salt not extracted from hash when performing check

    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)
    type: bug priority: high status: confirmed 
    opened by zakhdar 7
  • Remove the slf4j-nop from compile classpath

    Remove the slf4j-nop from compile classpath

    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
    
    type: bug priority: critical status: confirmed 
    opened by sureshg 5
  • Verify function always return true, am I doing wrong?

    Verify function always return true, am I doing wrong?

    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 image

    • Device spec with Verify function always return true image

    • Other image image

    Additional context Here's my code and result:

    Code image

    Result image

    Thankyou firaja :D

    help wanted status: can't reproduce 
    opened by RasyiidWho 5
  • Argon2 Password validation not working, always showing false

    Argon2 Password validation not working, always showing false

    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.

    priority: medium status: can't reproduce type: question 
    opened by mykapps599 4
  • Question about using Strings

    Question about using Strings

    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.

    type: question 
    opened by jehugaleahsa 4
  • Bcrypt does not use hash parameter

    Bcrypt does not use hash parameter

    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)));
    
    good first issue help wanted 
    opened by user9209 4
  • Move assertions into separate method or use assertThrows or try-catch instead.

    Move assertions into separate method or use assertThrows or try-catch instead.

    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);
    }
    
    type: enhancement good first issue priority: low 
    opened by firaja 2
  • Remove this unnecessary cast to

    Remove this unnecessary cast to "xxx".

    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;
    }
    
    type: enhancement good first issue priority: low 
    opened by firaja 2
  • Commit for issue #64 erroneously removed

    Commit for issue #64 erroneously removed "$s0" prefix from scrypt hash strings

    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

    opened by dpatriarche 2
  • Bump slf4j-api from 2.0.4 to 2.0.6

    Bump slf4j-api from 2.0.4 to 2.0.6

    Bumps slf4j-api from 2.0.4 to 2.0.6.

    Commits
    • 5ff6f2c prepare for release 2.0.6
    • 2f4aa75 fix SLF4J-575
    • 363f0a5 remove unused parts
    • 171679b SLF4J-574: Add full OSGi headers, especially "uses" clauses
    • 921b5b3 fix FUNDING file
    • e02244c fix FUNDING file
    • 441d458 fix FUNDING file
    • f5e741b add FUNDING file
    • 2e71327 remove unused log4j dependency in the version definition section of pom.xml
    • 3ff2a30 start work on 2.0.6-SNAPSHOT
    • Additional commits viewable in compare view

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    type: enhancement priority: low status: confirmed 
    opened by dependabot[bot] 0
  • Bump slf4j-simple from 2.0.4 to 2.0.6

    Bump slf4j-simple from 2.0.4 to 2.0.6

    Bumps slf4j-simple from 2.0.4 to 2.0.6.

    Commits
    • 5ff6f2c prepare for release 2.0.6
    • 2f4aa75 fix SLF4J-575
    • 363f0a5 remove unused parts
    • 171679b SLF4J-574: Add full OSGi headers, especially "uses" clauses
    • 921b5b3 fix FUNDING file
    • e02244c fix FUNDING file
    • 441d458 fix FUNDING file
    • f5e741b add FUNDING file
    • 2e71327 remove unused log4j dependency in the version definition section of pom.xml
    • 3ff2a30 start work on 2.0.6-SNAPSHOT
    • Additional commits viewable in compare view

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    type: enhancement priority: low status: confirmed 
    opened by dependabot[bot] 0
  • Inconsistency between public and internal APIs

    Inconsistency between public and internal APIs

        @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 https://github.com/Password4j/password4j/issues/92#issuecomment-1342537831

    type: bug good first issue priority: medium status: confirmed 
    opened by firaja 0
Releases(1.6.3)
  • 1.6.3(Dec 8, 2022)

  • 1.6.1(Oct 10, 2022)

  • 1.6.0(Jun 17, 2022)

    Changed

    • BCryptFunction, SCryptFunction, #withBCrypt(), #withSCrypt(), getBCryptInstance(), getSCryptInstance() to BcryptFunction, ScryptFunction, #withBcrypt(), #withScrypt(), getBcryptInstance(), getScryptInstance() (#36).

    Fixed

    • Scrypt never prepends $s0 to the result (#64).
    Source code(tar.gz)
    Source code(zip)
  • 1.5.4(Nov 19, 2021)

  • 1.5.3(Apr 14, 2021)

  • 1.5.2(Feb 21, 2021)

    Changed

    • Raised the compatibility with Android API level from 26+ (Android 8.0) to 21+ (Android 5.0).
    • SystemChecker's benchmark tools returns a prototype of the function and the real elapsed time (#23)

    Fixed

    • Argon2 was not using the given pepper with Password.check(String, Hash).
    • Salt was converted from String to byte[] too many times. (#31).

    Removed

    • Dependency with Apache Commons Text.
    Source code(tar.gz)
    Source code(zip)
  • 1.5.1(Feb 6, 2021)

    Added

    • Hash stores the byte array containing the calculated hash without algorithm's parameters and salt (#26)

    Changed

    • Scrypt accepts dynamic key length (#24)

    Fixed

    • Improved toString() methods' readability.
    Source code(tar.gz)
    Source code(zip)
  • password4j-1.5.0(Feb 2, 2021)

    Added

    • Argon2 support

    Changed

    • Enums BCrypt and Hmac are moved from com.password4j to com.password4j.types

    Fixed

    • Some typos along the code.
    Source code(tar.gz)
    Source code(zip)
  • 1.4.0(Nov 15, 2020)

    Added

    • CHFs like MD5, SHA-1, SHA-2 and SHA-3 in order to increase compatibility with legacy systems.

    Changed

    • PBKDF2Function.getAlgorithm() returns a String instead of an Hmac enum. This make PBKDF2Function.toString() and CompressedPBKDF2Function.toString() more readable.
    • SystemChecker.isPBKDF2Supported() accepts a String instead of an Hmac enum.

    Fixed

    • Some typos along the code.
    Source code(tar.gz)
    Source code(zip)
  • 1.3.2(Sep 9, 2020)

  • 1.3.1(Mar 25, 2020)

  • 1.3.0(Mar 19, 2020)

    Added

    • Capability of updating the hash (re-hash) with a new configuration just after the verification process

    Changed

    • HashBuilder and HashChecker are less extendable because there are more maintainability issues than effective advantages
    • Pepper can be provided either with SecureString or String.

    Removed

    • Password.hash() and Password.check() methods that accepts a custom HashBuilder or a custom HashChecker
    Source code(tar.gz)
    Source code(zip)
  • 1.2.1(Mar 19, 2020)

  • 1.2.0(Mar 15, 2020)

  • 1.1.0(Mar 15, 2020)

    Added

    • Configurable delimiter for CompressedPBKDF2Function (before was $)

    Removed

    • Hash.check() method because Password.check() should be the only way to verify passwords.

    Fixed

    • Values from psw4j.properties are not properly cached.
    • Typos in README.md
    • Typos in SystemChecker's methods' signature.
    Source code(tar.gz)
    Source code(zip)
  • 1.0.2(Mar 15, 2020)

    1.0.2

    Change

    • SystemChecker.java has no more a main method but must be called from end user's code. Removed UI and execution from Maven profile.
    Source code(tar.gz)
    Source code(zip)
  • 1.0.0(Mar 11, 2020)

  • password4j-1.0.1(Mar 15, 2020)

Owner
Password4J
Password4J
Tink is a multi-language, cross-platform, open source library that provides cryptographic APIs that are secure, easy to use correctly, and hard(er) to misuse.

Tink A multi-language, cross-platform library that provides cryptographic APIs that are secure, easy to use correctly, and hard(er) to misuse. Ubuntu

Google 12.9k Jan 3, 2023
Easy to use cryptographic framework for data protection: secure messaging with forward secrecy and secure data storage. Has unified APIs across 14 platforms.

Themis provides strong, usable cryptography for busy people General purpose cryptographic library for storage and messaging for iOS (Swift, Obj-C), An

Cossack Labs 1.6k Dec 29, 2022
Example Java Cryptographic License Files

Example of verifying cryptographically signed and encrypted license files using Java, Bouncy Castle, Ed25519 and AES-256-GCM

Keygen 1 Apr 1, 2022
An authorization library that supports access control models like ACL, RBAC, ABAC in Java

jCasbin News: still worry about how to write the correct jCasbin policy? Casbin online editor is coming to help! Try it at: http://casbin.org/editor/

Casbin 2k Dec 30, 2022
JNDI-Exploit is an exploit on Java Naming and Directory Interface (JNDI) from the deleted project fromthe user feihong on GitHub.

JNDI-Exploit JNDI-Exploit is a fork from the deleted project ftom the user feihong-cs on GitHub. To learn more about JNDI and what you can do with thi

Nil MALHOMME 4 Dec 6, 2022
simple interface to verify user authenticity

React Native Simple Biometrics A simple and straight forward API to ask a user to authenticate with on device biometrics. This can be used to quickly

smallcase 135 Dec 29, 2022
AES block cipher modes with user interface.

AES Ciphers An implementation of The common AES block cipher modes of operations (ECB, CBC, CTR), with user interface. It allows you to encrypt and de

Abd El-Twab M. Fakhry 6 Nov 21, 2022
A Vaadin example application that use Firebase Authentication as its user database

Vaadin + Firebase Auth example A trivial example to use Firebase Authentication with a Vaadin application. The app is built based on start.vaadin.com

Matti Tahvonen 3 Mar 9, 2022
A small and easy-to-use one-time password generator library for Java according to RFC 4226 (HOTP) and RFC 6238 (TOTP).

OTP-Java A small and easy-to-use one-time password generator for Java according to RFC 4226 (HOTP) and RFC 6238 (TOTP). Table of Contents Features Ins

Bastiaan Jansen 106 Dec 30, 2022
A small and easy-to-use one-time password generator library for Java according to RFC 4226 (HOTP) and RFC 6238 (TOTP).

OTP-Java A small and easy-to-use one-time password generator for Java according to RFC 4226 (HOTP) and RFC 6238 (TOTP). Table of Contents Features Ins

Bastiaan Jansen 106 Dec 30, 2022
Java binding to the Networking and Cryptography (NaCl) library with the awesomeness of libsodium

kalium - Java binding to the Networking and Cryptography (NaCl) library A Java binding to Networking and Cryptography library by Daniel J. Bernstein.

Bruno Oliveira da Silva 206 Oct 5, 2022
The react-native Baidu voice library provides voice recognition, voice wake-up and voice synthesis interfaces. react-native百度语音库,提供语音识别,语音唤醒以及语音合成接口。

react-native-baidu-asr react-native-baidu-asr It is a Baidu speech library under React Native, which can perform speech recognition, speech wake-up an

dengweibin 11 Oct 12, 2022
A library for bypassing all of Java's security mechanisms, visibility checks, and encapsulation measures via the JNI API

Narcissus: thwart strong encapsulation in JDK 16+ Narcissus is a JNI native code library that provides a small subset of the Java reflection API, whil

ToolFactory 29 Nov 3, 2022
This is an android library to represent password strength.

PasswordStrengthView This is an android library to represent password strength. Preview How to use? Add maven to your project gradle file allprojects

null 33 Jan 3, 2022
Library to easily configure API Key authentication in (parts of) your Spring Boot Application

42 API Key Authentication A library to easily configure API Key authentication in (parts of) your Spring Boot Application. Features Easily configure A

null 2 Dec 8, 2021
ByteSkriptQuery - A library for deploying ByteSkript as a backend web technology.

ByteSkriptQuery A language library for ByteSkript that allows it to be deployed as a backend web language. Not only does this allow the creation of ad

null 1 Jan 4, 2022
A Twitter-API library JAVA

Tweety A Twitter-API library for JAVA. Code for Authorization (Oauth 1) can be found here :Authorization This api conta

Rohit Kumar 2 Apr 26, 2022
Java Secure Cookie Library

Java library for security cookies, client-side pieces of data protected from reading and modifications by client with strong cryptography

Sergey Vladimirov 1 Oct 9, 2022
Open Source Identity and Access Management For Modern Applications and Services

Keycloak Keycloak is an Open Source Identity and Access Management solution for modern Applications and Services. This repository contains the source

Keycloak 14.6k Jan 5, 2023