hashing passwords atm.

i have a java backend, should i look into bcrypt or just use a loop?

also how many times would you recommend i hash passwords?

and should i look into hardware acceleration?

import java.security.MessageDigest;

MessageDigest messageDigest = MessageDigest.getInstance("SHA-256"); //or whatever you want

messageDigest.update(stringToEncrypt.getBytes());

String encryptedString = new String(messageDigest.digest());

@sharktits

1. Hashing is very different from encryption.

2. SHA-256 is extremely insecure for passwords (far too fast to compute).

BCrypt/Argon2/Scrypt would be far more appropriate for passwords.

@AndSoWeCode was 37 seconds faster ;)

@AndSoWeCode hashing is not there to be uncrackable, its there to dont store plaintext passwords.

@systemctl literally the first line of this post is 'hashing passwords atm' which part do you fail to understand

@sharktits (Cryptographic) Hashing was created, to make it extremely hard to get back the byte sequence used to create the hash. It wasn't made to not store passwords in plaintext, as they wouldn't be in plaontext when the Caesar Cypher (rot (13, but it doesn't have to be always 13)) would be applied, or when the password would be properly encrypted (properly = AES/Serpent/RC6/RSA/EC/Threefish, etc), but these methods would still be considered extremely insecure.

After talking so long about algos...please don't forget using a user-specific salt😅

@AndSoWeCode Scrypt is applied with different arguments for the algorithm (Passphrase, Salt (protect against rainbow table attacks), N (CPU/Memory cost), r (Add. Memory cost), p (Parallelization parameter), dkLen (Intended output length))

(Similar things for Argon2)

When computers get faster, these parameters just need to be incremented, instead of having to find a new hashing algorithm.

When a (bigger) user database get's breached, and the hashes of the passwords get leaked, it would be extremely costly to compute every single one of them, for both bcrypt and scrypt, although bcrypt doesn't have any additional parameters you can apply (afaik). If you are already using bcrypt (it's used a lot in PHP applications), it's not that bad to just stay using it to hash passwords. But when creating newer applications, it would be pretty good to use a password hashing algorithm, which you can supply parameters to, so that when cracking power increases, you can increase cracking cost too.

@systemctl I think bcrypt also supports a cost parameter

BCrypt.

@sharktits I see your point. But you better learn it good thr first time. You don't wanna hash your passwords without salting.