Multiple hash iterations

[GoogleCodeExporter]

Once issue 830 is fixed, I intend to use Guavas Hashing API for creating 
password hashes. At the moment, the code would look something like this:

public static String encodePassword(String password, String salt) {
  HashFunction func = Hashing.sha256();
  HashCode result = func.hashString(password + salt, UTF_8);
  for (int i = 0; i < ITERATION_COUNT; i++) {
    result = func.hashBytes(result.asBytes());
  }
  return salt + result.toString();
}

I was wondering if the possibility of hashing a hash n times could be added to 
the API? Also, a salt generator that generates random hexadecimal values of a 
given length would be very useful.

Original issue reported on code.google.com by toellr...@gmail.com on 22 Dec 2011 at 5:59

[GoogleCodeExporter]

I suspect that your "salt generator" would be adequately implemented by 
SecureRandom...no?

Original comment by wasserman.louis on 22 Dec 2011 at 5:59

• Changed title: Multiple hash iterations

[GoogleCodeExporter]

Absolutely. I currently use the following code to generate salts that are 10 
chars long, but the length should probably be configurable.

private static final SecureRandom random = new SecureRandom();
private static final int SALT_LENGTH = 10;

public static String getRandomSalt() {
  String randomHexString = new BigInteger(40, random).toString(16);
  String result = Strings.padStart(randomHexString, SALT_LENGTH, '0');
  assert result.length() == SALT_LENGTH;
  return result;
}

Original comment by toellr...@gmail.com on 22 Dec 2011 at 6:10

[GoogleCodeExporter]

I was assuming you'd be interested in salt as a byte[], which is the form I'd 
expect you to actually end up using?  And a SecureRandom lets you just do 
nextBytes(byte[]).

Original comment by wasserman.louis on 22 Dec 2011 at 6:20

[GoogleCodeExporter]

I have to store the salt as well as the password hash at some point in the 
database and the last time I checked, Hibernate's/Oracle's support for byte 
arrays was a bit iffy. Therefore, i decided to simply convert everything to 
String. 

By the way, I've created a utility class for creating secure password hashes:

http://pastebin.com/T8yUi72S

Please feel free to reuse anything for Guava you might find useful.

Original comment by toellr...@gmail.com on 22 Dec 2011 at 8:43

[GoogleCodeExporter]

Semi off-topic, but I'd use bcrypt instead of salted / stretched SHA-256 for 
password hashing:

http://codahale.com/how-to-safely-store-a-password/

It's more secure, and it's also simpler to use, since it handles salting / 
stretching for you.

There is a java implementation at

http://code.google.com/p/jbcrypt/

bcrypt stores the salt and hash as a String.

Original comment by nev...@gmail.com on 22 Dec 2011 at 11:13

[GoogleCodeExporter]

bcrypt looks like a great library. It's "only" version 0.3, though, which might 
be a dealbreaker for the guys at my company who are in charge of deciding about 
using a 3rd party library like that. It was tough getting them to allow Guava. 

Original comment by toellr...@gmail.com on 23 Dec 2011 at 3:02

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

The java implementation (jBCrypt) is indeed in version 0.3, and I guess that 
might be a problem to get it accepted as a 3d party library...

bcrypt itself is 12 years old, though, and the java implementation is only one 
of many implementations. I think the version 0.3 thing is just a version naming 
scheme problem, since the Java implementation is quite old (version 0.1 was 
released in May 2006, 0.2 in April 2008, and 0.3 in February 2010).

http://en.wikipedia.org/wiki/Bcrypt

http://www.mindrot.org/projects/jBCrypt/

Original comment by nev...@gmail.com on 23 Dec 2011 at 6:46

[GoogleCodeExporter]

Yeah, sorry, that's what I meant: jbcrypt. I also wanted to add that the 
passwords I want to hash are for users that are all employees of our company 
and they are for an application that drives our business, but which is not 
accessible from the outside. I'm just looking for a simple, but fairly secure 
encoding that is better than storing the passwords as plain texts (which is how 
they are stored at the moment!). A hacker wouldn't really have much to gain by 
cracking the passwords, except for disrupting our business processes (which 
might be all they want to do).

Nevertheless, using a 3rd party library at version 0.3 might not be justifiable 
in this case.

After reading the blog by Coda Hale, I've updated the above code to hide the 
salt inside the hash at an offset based on the password's length. A hacker 
should not be able to discern what the salt is which should make cracking the 
encoding all the more difficult:

http://pastebin.com/t2PwAZHY

Original comment by toellr...@gmail.com on 23 Dec 2011 at 1:00

[GoogleCodeExporter]

I wonder how difficult it would be to take a given HashFunction and iterate it 
n times.  That'd be my preferred way to address this issue.

Original comment by wasserman.louis on 24 Dec 2011 at 4:15

[GoogleCodeExporter]

Original comment by wasserman.louis on 5 Jan 2012 at 8:53

• Added labels: Package-Hash, Type-Enhancement

[GoogleCodeExporter]

It doesn't seem clear that Guava needs to add anything. I think a user could 
pretty easily create a HashFunction implementation that delegates to another 
HashFunction and feeds the result through itself N times; if not, please let us 
know.

Original comment by kevinb@google.com on 10 Jan 2012 at 11:53

• Changed state: WontFix

[GoogleCodeExporter]

This issue has been migrated to GitHub.

It can be found at https://github.com/google/guava/issues/<id>

Original comment by cgdecker@google.com on 1 Nov 2014 at 4:14

• Added labels: MigratedToGitHub

[GoogleCodeExporter]

Original comment by cgdecker@google.com on 3 Nov 2014 at 9:09

• Added labels: Restrict-AddIssueComment-Commit