Consider the following authentication flow.
- User sends in their username and an RSA encrypted password
- The password is decrypted and hashed with a salt (and possibly a pepper) and verified
- If the hash matches a GUID is generated as a token and the token is given a TTL and expiration date and returned to the user. In addition the IP address of the caller is saved
- That username with the token is then used for any future interaction with the DB (Any time the token is used its expiration date is extended). Only the IP which created the token can use the token.
- Logging in from a new IP must first be verified using a second form of authentication (ex. a code sent to the users email)
What are the security concerns of such an authentication system?
I feel like such a system would be using tokens incorrectly as from what I've read it seems that the purpose of tokens are meant to be for authorization and not authentication. I feel as though the only benefit of using the token is that a password can be used to log in anytime and the token eventually expires so if it becomes expired it will eventually become useless.
One of my concerns would be if someone is constantly listening in and intercepting the token that would essentially mean they could use it to access the database whenever there is an active token (and can indefinitely refresh a token to keep it active). This is why the IP address would be stored and access would only be given to that IP address. Would this minimize the risk of the token being misused.
In general a token can't be passed back encrypted, how can anyone prevent a token from being intercepted and misused?