Absolutely, Im not stating otherwise. Im saying you shouldnt have your authentication inside your business logic. It should be a separate service. Limited access, and transparent to the application that is calling on it.
If you want that to be a REST service, great.
If you want it to be another table/schema/database/server, great.
If you want it to be something else, great.
Just stop putting it right inside the application that is taking user input.
Don't roll your own hashing, use something solid, like Argon2, salt your stuff. Store your salt someplace secure, not in your frigging rails config.yml or inside env on your webservers or anything else that is publicly addressable.
> Im saying you shouldnt have your authentication inside your business logic. It should be a separate service.
And I am saying this is a wrong, counterproductive idea. It complicates your authetication for no substantial gain, and will only result in additional vulnerabilities.
> Store your salt someplace secure, not in your frigging rails config.yml or inside env on your webservers or anything else that is publicly addressable.
So you don't even understand how a salt works. Why should we take security advice from you again?
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.
He'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.
If you want that to be a REST service, great.
If you want it to be another table/schema/database/server, great.
If you want it to be something else, great.
Just stop putting it right inside the application that is taking user input.
Don't roll your own hashing, use something solid, like Argon2, salt your stuff. Store your salt someplace secure, not in your frigging rails config.yml or inside env on your webservers or anything else that is publicly addressable.