3 ms·
Wow you’re aggressive. Using something like Hashi Vault, Gluu, or Shiro does not overly complicate things. They’re stable, trusted solutions. It can also grea
by odammit 9y ago
Wow you’re aggressive.
Using something like Hashi Vault, Gluu, or Shiro does not overly complicate things. They’re stable, trusted solutions.
It can also greatly simplify things. In the common scenario of having a web app for customers and a web app for admins, instead of them each having their own authentication baked in, you can choose an open source solution and deploy it twice, once for each service.
I know how salt works. Don't belittle me.
If someone gets into your web servers they’ve pretty much got carte blanche at your database the web server has access to. They also now have your code, which in a lot of cases is probably plainly readable. So they can see your salt, see how you salt and see the hashing algorithm you've chosen.
I’m saying don’t store the salt in your apps config right along with the credentials to access all of your login identifiers and hashed passwords.
You gave them a piece of the puzzle. If someone wants to grind through and crack all the salted/hashed passwords, I'd prefer them not to have the salt to help in that endeavor.
- path411 9y agoHe's talking about how each password should use a separate salt. This is normally stored next to the password hash. Many hashing algo implementations will even do this for you.
- etxm 9y agoCool. So if it’s in the same table, it’s just as secure as one salt sitting in a config file. When the table gets leaked, so does the salt. Also, is he? More than one salt sounds too complicated for him.