So I want to have a play with making a tokenised login system but wanted to get my head around some of the nitty gritty. Please don't go and tell me to use OAuth etc as that isn't what I'm trying to achieve.. I want to understand the best way of how they work.
So this is the basic understanding of how I'd see the system working:
User registers on their phone application, which sends the username and password to a server via HTTPS. The server then generates two tokens, a public token and a private token which are both returned to the client.
The client then stores both of these tokens locally using localstorage.
So for subsequent page requests that need authentication, the client will send the public token and a hashed version of the private token to the server.
The server checks the database for the public token, unhashes the hash that was sent to the server, using something like timestamp and compares them. If both match, then the user is authenticated.
Now this fine, I understand that this should in theory be pretty secure from the point of view that the private token is only transmitted the once, ever over HTTPS so the chances of someone getting hold of it and authenticating as the user are minimal.
Now comes my real question on security... how can you protect user authentication if someone were to hack access to your database only (assuming the database isn't on the same server as the server side code). If I were to login and get the database then I'd have username,encrypted password,public and private tokens. I could technically then use these two tokens to authenticate myself as the user. What's the way to avoid this?
Hope that made sense!
Update
Okay, so is this process secure enough:
- User registers by sending username and password over HTTPS.
The password uses bcrypt and is stored in the database
User comes to login and enters their username and password
- The password is checked throug bcrypt against the one stored in the database
- If there is a match, a JWT is generated using a secret key and sent back to the client
- All future authentications that contain this token are verified against the secret key and if they match, the user is authenticated.
All of the above would be over HTTPS.
Is that secure enough? Cuts out the issue of having the token stored on the server as it would only be stored on the clients system and also the passwords are hashed in the database if that were to be leaked.