2

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?

2

A couple things worth noting:

  • IP's change -- probably more often than you expect
  • You're screwed no matter what if someone is able to listen in
  • Any code executed in-browser can by bypassed if someone is listening in

What you're describing is what's known as a bearer token: whoever bears the token has the power of the token. This is exactly how most websites work, except they often just call them session cookies.

There are a couple things you can do to protect this token.

  1. Enforce HTTPS using a real trusted certificate -- this is all an exercise in futility if you don't use HTTPS.
  2. Enable HTTP Strict Transport Security; this'll signal to the browser that all requests to site must be over HTTPS, and therefore any man in the middle will probably be noticed because of an invalid certificate. This has limited effectiveness though because an attacker might strip the HSTS header before the browser sees it.
  3. Consider public key pinning; this'll make it more difficult for someone to use a trusted but fake certificate while doing a MiTM. This is extremely effective if you're using a non-browser app because you can control the channel validation.

If you're still concerned about someone intercepting the request then you need something like a client certificate, so you can do mutual authentication. This will guarantee protection against interception because the key exchange can only occur between trusted parties.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.