0

If I'm creating an authorization service for my application, why can't I just hash the password and save the the username and hashed password in my User table? Why should I use a token authentication service like JWT? I don't think I'm right but I feel like I'm missing something here.

2 Answers 2

2

Well, for starters, a token can be expired in a relatively short period of time, forcing a user to re-authenticate. A password is generally has a much longer life. Thus, if a token is stolen by an attacker it is useful for a relatively short period of time (this is one reason that when you have to change a password a good system will force you to enter the current password).

In addition, if you put a hashed password on the client then it can be stolen and used by an attacker in "pass the hash" attacks, which have been around for over twenty years now. It'd be nice to get rid of them :-)

0

Sure your backend can store hashed passwords in a table. This is how Linux does authentication, for example. But..

Implementing your own security is discouraged, because there are notoriously many common subtle pitfalls that require specialised expertise to avoid. For example, if you choose a weak or broken hashing algorithm, or neglect to salt users individually, or concatenate the password and the salt in the wrong order, or (as Swashbuckler pointed out) if your client interface transmits credentials in the same form as your backend server stores them, etc. Any of these unnecessarily increases the severity if you do have a security incident. But even if you get everything right..

That approach isn't scalable. You might need to distribute load over multiple backend servers. (Furthermore, you might want the authenticated user session not to be tied to a specific server, so that you can reboot servers without disrupting users.) Alternatively, you might want multiple applications to share the same pool of user accounts. Now, you could try to engineer a complicated way of reliably syncing the user tables between multiple servers, but that approach is vulnerable to having any single component instance compromise everything else (so every application has to be hardened to the highest level, which for monolithic applications will be very onerous to maintain). Alternatively, you set up a central authentication microservice for your application servers to rely on. In that case, you're practically reimplementing OpenID Connect. Again there are subtle pitfalls in the flows/protocols (thwarting various attacks, controlling which applications are authorised to use which resources on the user's behalf, etc) that can be avoided by just adopting the standard.

Lastly, your potential users may find there is less friction to use social (federated) logins rather than filling out a signup form, verifying their details, and managing separate credentials for every new service provider they interact with.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .