9

I'm using play-framework 2.0 (java web-framework) with postgresql.

  1. what encryption type for a user's password is the most common today? I understood that MD5 has been abounded in the last few years.
  2. what is the right data-type for field "password" in User class (and therefore, in the postgresql DB)?

thanks

socksocket
  • 4,271
  • 11
  • 45
  • 70

3 Answers3

9

You want to hash the password, not encrypt it (See this question for more details). The current recommended approach is to use an adaptive hashing algorithm, like bcrypt. jBcrypt is a solid Java implementation that you can use.

As for DB type, you can safely just treat it as a string.

Community
  • 1
  • 1
Oleksi
  • 12,947
  • 4
  • 56
  • 80
  • doesn't java supply a native solution for hashing a password? why should I use jBcrypt (3rd party lib) over native solution? – socksocket Aug 20 '12 at 16:41
  • I don't know what hash methods Java supports. In any case, you should jBcrypt because it is more secure than the "traditional" hashing algorithms that Java implements. I'd only use the native Java hashing algorithm if it was also an adaptive hash algorithm. – Oleksi Aug 20 '12 at 16:43
2

I used jBcrypt together with Play framework internal Crypto ( got idea from here: https://groups.google.com/forum/?fromgroups#!topic/play-framework/9KIUwWBjudQ[1-25] )

Also when I added registration for users I made sure that password has some level of complexity (at least 8 marks of miminum, big letter, one number). etc. you name it basically? But just wanted to point out that security is not just about encrypting, half of the cake is making sure that users will use complex passwords :)

Mauno Vähä
  • 9,688
  • 3
  • 33
  • 54
0

You should use the SHA-x algorithm to hash the password. This is more or less the replacement hash function of MD5. 

MessageDigest.getInstance("SHA-512").digest(toBytes(toDigest)))

But be careful, add a salt to the password before hashing it to avoid an hash table attack.

The DB column should be a varchar. The length depends on the version you use of the SHA algorithm

HIH

poussma
  • 7,033
  • 3
  • 43
  • 68
  • This is not secure. See [this question](http://security.stackexchange.com/questions/211/how-to-securely-hash-passwords) for details. – Oleksi Aug 20 '12 at 15:53
  • if you add a salt to the password, you cannot use brute force, neither dictionary (hash tables)... and as far a I know the SHA-512 hash function cannot be reversed... – poussma Aug 20 '12 at 15:56
  • You can, in fact, brute force it with modern GPU hardware. Even if you hash with a salt. The problem is that hashing functions are designed to be fast. This is not what you want when hashing passwords. You want it to be slow. This is what bcrypt helps you do. Take a look at this [question](http://security.stackexchange.com/questions/3272/password-hashing-add-salt-pepper-or-is-salt-enough) as well. – Oleksi Aug 20 '12 at 15:59
  • Well, I agree but a sha-512 with a salt, a pepper, and any kind of condiment cannot be found as simply as you tell... Try to find the password hidden in this hash: f4c9f678aa36069e364107e8c08b00950e9d32bc084dc4d043cfc344fc6edb30974a5da5be977320f787f55c5b8b248d53ec66c65ee68bb682f1b59789316632 it is almost impossible as it requires dozen of decades to find it... – poussma Aug 20 '12 at 16:12
  • Agree, google recently broke sha-1, with huge amount of power. So breaking sha-256 will require way more power. Even with modern GPU hardware... So a sea-256 with a salt is suffisant. Not every hacker have the resource to brute force a hashed DB with sha-256 – RomOne Jul 02 '17 at 10:48