amdelamar / jhash Goto Github PK

The latest published package is not mirrored in JCenter for some reason.

https://bintray.com/bintray/jcenter/jhash

https://bintray.com/amdelamar/mvn/jhash

Might be because of the group id change.

First you'll need to generate a pom.xml

Then update maven/gradle instructions:

Gradle:

repositories {  
   jcenter()  
}

Maven:

<repositories>
    <repository>
        <id>bintray</id>
        <url>http://jcenter.bintray.com</url>
    </repository>
</repositories>

Hi,

My project have the below requirement

1. hash algorithm to use is Password-based Key Derivation Function 2 (PBKDF2).
2. The salt values must be at least 32 bit in length and unique for every password entry
3. The salt values must be generated using an approved cryptographically secure random number generator (CSRNG).

For the 1st and 2nd point, I think the jhash can achieve. But for the 3rd point, is there any way for jhash library to allow us to specify our own custom salt values, rather than let the jhash library generate. The intention is to allow my application to use an approved CSRNG to generate the salt values.

Hi,

I have a runtime crash on devices with API < 26

java.lang.NoClassDefFoundError: Failed resolution of: Ljava/util/Base64;
        at com.amdelamar.jhash.util.HashUtils.encodeBase64(HashUtils.java:103)
        at com.amdelamar.jhash.Hash.create(Hash.java:182)

This class seems to be not available on older devices.

Hi team,
Would you please let us know whether your lib supports Android platform ?
Tons of thanks

https://github.com/amdelamar/jhash/blob/master/src/main/java/com/amdelamar/jhash/util/HashUtils.java#L33

Creating a new SecureRandom is probably not as good an idea as having a single instance, or even a ThreadLocal<SecureRandom> (I'm not actually sure if SR is threadsafe. It probably is).

This would prevent inheritance (extends) and instantiation (new HashUtils()).

https://github.com/amdelamar/jhash/blob/master/src/main/java/com/amdelamar/jhash/algorithms/BCrypt.java#L404

Your bcrypt impl isn't re-entrant; calling bcrypt() calls key(), and key overwrites pA, which is a global static mutable variable. Uhoh.

Skip the install step like so:

before_install:
 - chmod +x gradlew

install: echo "skipping install step"

script:
 - "./gradlew check"

The default install step runs gradle assemble. So doing that AND gradle check isn't really useful when tasks are being repeated on every build.

Currently com.github.amdelamar does not match the actual package com.amdelamar used.
This should be updated so it can be published to maven central.

When using BCrypt with iterations less than 10 (if not 2 chars):
Hash.password(pass).factor(9).algorithm(Type.BCRYPT).create();
However BCrypt supports 4+ rounds. I think we must add 0 before rounds if it's less then 10 when appending to hash string.

Exception in thread "main" java.lang.IllegalArgumentException: Missing salt rounds
	at com.amdelamar.jhash.algorithms.BCrypt.create(BCrypt.java:508)
	at com.amdelamar.jhash.Hash.create(Hash.java:196)
	at ua.i0xhex.discr.Main.main(Main.java:16)

I'm migrating from a python backend to the jvm and would love to use this library. Most of my hashes however are currently using the 2b revision of bcrypt. This version bump technically only applied to the openBSD implementation and should be functionally identical with 2a everywhere else. It should be possible to handle it just like 2y.

For now I will just replace the $2b with $2a in all my fields as a workaround.

https://github.com/amdelamar/jhash/blob/master/src/main/java/com/amdelamar/jhash/Hash.java#L265

This is a security issue – the reason you sometimes see passwords/salts passed as char arrays, and not Strings, is that Strings are impossible to securely eliminate from the process; they don't disappear until they get GCed and might even end up interned someplace. You can't wipe their contents either. If you eliminate the content of a char array (Arrays.fill(charArray, '\0')), you've got a better chance of eliminating the content from memory introspection tools. This is a pretty exotic security measure (if some process gets to look into your JVM process internals, you've got problems!), but nevertheless, that is why things like JPasswordField and such work with char[]. By having char[] based arguments in the first place you're creating the illusion that you're supportive of this security protocol, but you're not, as you're making strings out of em. Either eliminate the char[] based methods, OR document with all sorts of <blink> tags and other such 'HERE BE DRAGONS!' (you can tell I'm not a fan of this plan) that you're writing a check your code can't cash, OR BOTH stop turning them into strings, wipe all the char[] arrays you make yourself, and either wipe the input param char array or document that caller should take care of that ASAP. Do a global search for String to find all cases of this, same for char[].

See all the issues by running:

./gradlew javadoc

Compatibility with https://github.com/jeremyh/jBCrypt

It looks like the generated hashes are not compatible
to jeremyh version of BCrypt

String yourHash = BCrypt.create("password", 12);
String theirHash = BCrypt.hashpw("password", BCrypt.gensalt (12));

Assert.assertTrue(BCrypt.checkpw("password", yourHash)) -> FALSE

String testHash = BCrypt.create("password", theirHash, 12);
Assert.assertTrue (HashUtils.slowEquals (theirHash.getBytes(), testHash.getBytes())) -> FALSE

Where is my mistake?

Edit
BCrypt Tester: https://www.dailycred.com/article/bcrypt-calculator
theirHash -> Password and hash match
yourHash -> Password and hash do NOT match

plugins {
  id "org.sonarqube" version "2.6"
}

./gradlew sonarqube \
  -Dsonar.organization=amdelamar-github \
  -Dsonar.host.url=https://sonarcloud.io \
  -Dsonar.login=xxxxxxxxxx

https://sonarcloud.io/projects

https://github.com/amdelamar/jhash/blob/master/src/main/java/com/amdelamar/jhash/Hash.java#L269

There's a bug here: If I pass algorithm "PBKDF2withGobbledygook", I'm supposed to get a NoSuchAlgorithmException("Unsupported algorithm type."), but I won't. Instead the operation works but produces an unverifiable invalid value.

https://github.com/amdelamar/jhash/blob/master/src/main/java/com/amdelamar/jhash/Hash.java#L180

You've got 10 methods called 'create' here, and some of the paramtypes are the same. This is going to cause confusion and it's unclear what/how to use this. My advice:

Have 1 convenience method that just takes a single String, and then have a builder kind of deal. Instead of:

Hash.create("pass", "pepper", 13), I'd write: Hash.create().password("pass").pepper("pepper").complexityFactor(13).build().

parameter is not clear enough as to the intent of that variable. The named methods ensure everyone can at a glance see what's going on, IDE autocomplete will guide you as to what you can do and lets you write javadoc for each element, and while that's more code to write, you don't actually specify pepper, rounds, algorithm, etc, unless it's important to do so (you'd go with the default choices if it's not), so apparently these things are important, which means: It's good that they are all explicitly named like this.

Note, if I were to write:

Hash.create("pepper", "pass", 13), the code compiles and runs without warnings or errors, and yet that doesn't do what I expected (I flipped the pepper and pass args). There's no way I can easily tell I messed that up. Had I written: Hash.of().password("pepper").pepper("password").create(), I can visually identify I'm doing it wrong, and it's highly unlikely I'd ever make that mistake in the first place.

JCenter is shutting down https://jfrog.com/blog/into-the-sunset-bintray-jcenter-gocenter-and-chartcenter

Need to publish this library to Maven Central.

https://github.com/amdelamar/jhash/blob/master/src/main/java/com/amdelamar/jhash/Hash.java#L72

https://github.com/amdelamar/jhash/blob/master/src/main/java/com/amdelamar/jhash/Hash.java#L53

Seems like bad API design to throw a (checked!) exception in the signature that can't actually happen unless your implementation is corrupt. You might as well throw an InternalError. Catch and rethrow as runtime exception (because it can't happen). Corrupt / weirdly configured JDKs might not have the appropriate algorithms in their built in security library, but a checked exception is still a bad design decision here: A user of a library trying to go with your defaults will not be able to meaningfully recover from such an error, so what are they going to put in their catch block?

https://github.com/amdelamar/jhash/blob/master/src/main/java/com/amdelamar/jhash/exception/InvalidHashException.java#L3

This should be a runtimeexception. Comes down to the same problem: If I were to write code that uses this library, and this exception occurs, what am I going to do? 99.95% of the time, what I want to do is blow the current execution stack with an exception explaining what exotic bad thing just happened. Passing on the very exception YOU throw (because the library is the best at generating a message, presumably) accomplishes just that, but being checked makes that hard for me. Sure, it's theoretically possible a corrupt hash is an expectable condition that can be recovered from, but that's a really exotic use case. Think about it: There are really only 4 possible scenarios here:

• Your own library has a bug (such as what happens with passing in PBKDF2Gobbledygook as algorithm, then InvalidHashEx would happen). There's nothing sane I can do here. You can't use checked exceptions to make calling code somehow deal with your bugs.
• There's a version mismatch and your library changed the scheme of that hash between versions. Similarly, nothing sane I can do but 'log it and exit', which just propagating that exception will do in a far superior way than forcing every caller to try to do that.
• The JVM is corrupt. In which case all bets are off anyway.
• The data in the DB got overwritten or corrupted. In which case all bets are off anyway.

Checked exceptions are for somewhat expectable conditions that one assumes can be recovered from. Let me put it this way: InternalError isn't checked either.

Re-license just the "Jhash" portion. Not the individual algorithms. Although, it would be nice to relicense each of them to be the same license, but we'll save that for a later time.

See https://gradle.org/whats-new/gradle-5/