Secure password hashing algorithm in go.

[Jeff]

I'm am looking to implement in go, the following code written in Java.

I have not  been able to find any apis or modules for this.  Is it possible to achieve this, did I just not the right resources? How are we doing secure hashing in go?

Thanks.

  /**
     * Encrypts the given password with a salt
     *
     * @param password The password string to be encrypted
     * @param salt     A randomly generated salt for the password encryption
     * @return The byte[] containing the encrypted password
     * @throws NoSuchAlgorithmException
     * @throws InvalidKeySpecException
     */
    public static byte[] getEncryptedPassword(String password, byte[] salt)
            throws NoSuchAlgorithmException, InvalidKeySpecException {
        String algorithm = "PBKDF2WithHmacSHA1";
        int derivedKeyLength = 160;
        // The NIST recommends at least 1,000 iterations:
        // http://csrc.nist.gov/publications/nistpubs/800-132/nist-sp800-132.pdf
        int iterations = 20000;

        KeySpec spec = new PBEKeySpec(password.toCharArray(), salt, iterations, derivedKeyLength);

        SecretKeyFactory f = SecretKeyFactory.getInstance(algorithm);

        return f.generateSecret(spec).getEncoded();
    }

[Patrick Mylund Nielsen]

You should use https://godoc.org/golang.org/x/crypto/bcrypt, or something like https://godoc.org/github.com/pmylund/go-hmaccrypt (shameless plug) which uses bcrypt and has a local secret that helps you prevent SQL injections elsewhere (i.e. code you have no control over) from compromising the digests.

In a while, the general recommendation will probably become Argon2, but for now its library support is pretty poor.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Matt Silverlock]

Go has a PBKDF2 package (https://godoc.org/golang.org/x/crypto/pbkdf2) - but unless you *explicitly* need to use it, you should prefer bcrypt (https://godoc.org/golang.org/x/crypto/bcrypt) or scrypt (https://github.com/elithrar/simple-scrypt - gives the Go scrypt package a saner API).

Note that the comments on that Java code are misleading - password hashing/key derivation is not 'encryption'. 

[roger peppe]

On 2 December 2015 at 00:21, Matt Silverlock <elit...@gmail.com> wrote:
> Go has a PBKDF2 package (https://godoc.org/golang.org/x/crypto/pbkdf2) - but
> unless you *explicitly* need to use it, you should prefer bcrypt
> (https://godoc.org/golang.org/x/crypto/bcrypt) or scrypt
> (https://github.com/elithrar/simple-scrypt - gives the Go scrypt package a
> saner API).

For the record, why is bcrypt preferred over pbkdf2 ?

[Matt Silverlock]

bcrypt is more memory-hard—i.e. can be tuned to consume a non-negligible amount of RAM per round—when compared to PBKDF2.

PBKDF2 should only be used if you need to meet FIPS certification requirements in the US.

scrypt is better still, and is more configurable depending on your hardware specs/resource requirements.

I wouldn't use any other password hashing algorithm right now, winner of a contest or not, until well tested *implementations* make an appearance.

[James Pirruccello]

I think you are describing scrypt in your bcrypt description.

Bcrypt is (probably) better than PBKDF2 because bcrypt uses a lookup table whose values change constantly, making it less amenable to pure-GPU bruteforcing (with shared memory) than PBKDF2. But I am not a cryptographer, etc.

My question for the original poster is whether he needs to maintain compatibility with a legacy system, or whether he is looking for a good system when starting from scratch.

[Jeff]

"My question for the original poster is whether he needs to maintain compatibility with a legacy system, or whether he is looking for a good system when starting from scratch."

it will be a new system that will import existing records, which will have already hashed user passwords.

[James Pirruccello]

In that case, a classic approach would be to bcrypt all of the previously-hashed passwords.

Your options are then:

- Continue doing this indefinitely. Let's say the prior hash was a simple SHA256. You can SHA256 then bcrypt everything.

or

- For all imported passwords, note that you have to SHA256 then bcrypt these legacy passwords. Once the user logs in for the first time, you can remove the SHA256 step, and directly password -> bcrypt. Note that for passwords above a certain length (I believe it's 72 characters), this is inadvisable because bcrypt does not see all characters.

What I would *not* recommend doing is an incremental upgrade, where new passwords get the bcrypt (or PBKDF2) treatment, but old ones retain their old SHA256 (for example) until first login. You want to apply the secure hashing step to all passwords in the database in case it gets compromised.

Again, I am not a cryptographer and this should not be relied on for cryptographic advice.

[ssrs]

Have you get a solution? i have the same problem too, golang is not compatible with java SecretKeyFactory

在 2015年12月2日星期三 UTC+8上午7:47:22，Jeff写道：

[minf...@arcor.de]

I've often encountered demands for password encryption, where simple string hashing would suffice.

Speed-wise FNV-1a is barely to beat. Add some magic number to the result and you are good enough.

The algo fits in a single handful of lines.

Of course this ain't military strength encryption, but should suffice for eye-protection of any non-critical stuff.

 

[roger peppe]

On Mon, 7 Jan 2019 at 13:58, <minf...@arcor.de> wrote:

I've often encountered demands for password encryption, where simple string hashing would suffice.

Speed-wise FNV-1a is barely to beat. Add some magic number to the result and you are good enough.

Not for password encryption. FNV isn't designed for crypto hashing, and speed is specifically something you do not want for password hashes, because if it's fast it's quick to run through a dictionary attack.

That's why algorithms like PBKDF2 exist.

The algo fits in a single handful of lines.

Of course this ain't military strength encryption, but should suffice for eye-protection of any non-critical stuff.

 

--

[Sam Whited]

On Mon, Jan 7, 2019, at 07:58, minf...@arcor.de wrote:
> I've often encountered demands for password encryption, where simple string
> hashing would suffice.

You should never encrypt passwords; encryption implies that you can get the original password back out, it's a two way street.
Some form of hashing is always what you want (of course, you can't just hash and call it a day; there's still more work to do).

> Speed-wise FNV-1a is barely to beat. Add some magic number to the
> result and you are good enough.
> The algo fits in a single handful of lines.

You also don't want speed when hashing passwords, this is why all the methods other people have been listing (I use Argon2 or PBKDF.2 depending on the application, personally) are actually a type of hash called a Key-derivation function (KDF). FNV-1 is not a cryptographic hash function and is not suitable for password storage.

OWASP has a good overview of password storage if you're interested: https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet

—Sam

[buc...@gmail.com]

I spent most of November studying password hashing and IMO argon2id should be used for new projects going forward. Very nice implementation in Go in the x library.  I don't speak Java so can't help you there.

[minf...@arcor.de]

Yes, thanks for the refresher.  ;-)

But as I said, for non-crypto requirements weak data (or password) obfuscation can be sufficient.

For such weak purposes an FNV-1 code 3-liner may be adequate.

For comparison: The Argon-2 github shows about 2000 lines of C code.

[Pat Farrell]

On Friday, December 4, 2015 at 5:33:45 PM UTC-5, Jeff wrote:

"My question for the original poster is whether he needs to maintain compatibility with a legacy system, or whether he is looking for a good system when starting from scratch."

it will be a new system that will import existing records, which will have already hashed user passwords.

Unless you are forced to use SHA1, don't use it. Plan a transition from the legacy system, or legacy hash. Such as implement a better, more modern and more secure hash in the legacy system and prompt the users to change their password.

When the NIST says "use a better cipher" (or hash or whatever) listen to them and don't use the old one anymore. 

No software written in 2019 should use things like MD5, SHA1, DES and all that similar stuff that was probably OK in 1975. Computers are faster and attacks are smarter.

[Dan Kortschak]

The problem with this approach is that something that's good enough for
This Use™ by the owner of the code will be seen by another person and
then used by someone else with less understanding. The world of
cryptography implementations is already contaminated enough with badly
implemented Correct™ systems, let's not add more choices for weak and
intrinsically broken systems.

[anggi nugroho]

hai..
is the issue solved?