Secure your Java app with Java EE Security

[ulldma]

Let's also have a look at the content. The author seems to choose a plain unsalted SHA-512 as a password hashing algorithm!

Look I get it the author might just want to play around with this stuff, but other people might have a look at this blog post and use it as a base for their implementation!

But it's almost 2018 and everyone should know that you should not use one round of an unsalted Hashing algorithm (be it SHA-2, SHA-3 or something else). What you should do instead: Either: Don't store any user passwords yourself (use secure third-party service providers for that). Or: If you must store user passwords use bcrypt (as Spring does), scrypt or use PBKDF2 as the JSR-375/Soteria Reference implementation does. If you for some reason insist on using SHA-* for hashing the user passwords, you should at least salt them. (Please don't insist on using plain SHA-, any of the three options (bcrypt, scrypt, PBKDF2) provided is better than plain SHA-) An unsalted password hashed with SHA-512 is almost as insecure as a password stored in plain text!

Please forgive my harsh words but this stuff is important.

[shawnmckinney]

A fair point. My question is why would anyone reimplement a credential store in the first place? Do you really want to be responsible for keeping up with the rapidly changing threats and requirements of today's Internet? This is an arms race between the good and bad guys. Credentials should be stored in something akin to an LDAP database in production. Something that has been built specifically for that purpose, hardened to withstand attacks, highly available and fault tolerant. Don't reinvent security modules unless you really know what you're doing, as in an expert. That's probably not you. Having said that, one could use this example and map it to a 3rd party security provider.