2

I would like to implement a REST API with Basic Authentication which relies on username and password. Because REST is stateless the user would have to reenter username and password for every request without storing them in a cookie. As storing username and password in a cookie is not an option another solution is needed.

The scenario I’m thinking of will be as follows:

  1. User navigates to https://www.myapi.com/login
  2. User enters username and password (encrypted with SSL).
  3. System checks if provided credentials are correct.
  4. If correct: System generates a GUID, encrypts the GUID with password of user and sends it to the user.
  5. If not correct: Increase FailedPasswordAttemptCounter and check if login should be locked for the user.

As the response of the server to the client is not encrypted the GUID is encrypted with the password of the user. Only the user is able to decrypt the GUID.

The user provides the GUID for all other resources which needs authentication instead of username and password.

Is this approach better compared to providing username & password for each request?

I’m aware of the fact that someone is able to generate GUIDs and tries to authenticate with them. But a targeted attack on a specific user is nearly impossible as the login resource provides a lock mechanism.

My question is somehow related to this one: https://stackoverflow.com/questions/290405/is-using-a-guid-security-though-obscurity

1 Answer 1

5

Because REST is stateless the user would have to reenter username and password for every request

Is directly contradictory to

The user provides the GUID for all other resources which needs authentication instead of username and password.

You can either:

A. send the password with every request, or
B. don't send the password with every request.

But you will have to pick one.

Here's the ideal scenario. It's close to what you're describing:

  1. The user logs in. Username, password, authentication token, whatever.
  2. The server stores that authentication event server-side and creates a random token (GUID or whatever you want) to give to the client
  3. When the client want to send his request, he also sends the token which identifies him to the server. It could be in a cookie, in the URL, in a form variable, in a separate header. Doesn't matter. Anywhere in the request is fine.
  4. The server expires the token after it's no longer supposed to be used. Perhaps it's good for 5 minutes, perhaps it's good until it's been used for one operation. Perhaps it's good until it goes unused for 5 minutes. Whatever you want.
4
  • is it not necessary to encrypt the random token given to the client such as I have suggested?
    – niklr
    Aug 3, 2013 at 20:29
  • The token is random. Encrypting it doesn't make it any more random.
    – tylerl
    Aug 3, 2013 at 21:16
  • This is true to some extent but if I'm able to intercept the message I can use the token. Encrypted it would be useless.
    – niklr
    Aug 3, 2013 at 21:35
  • 1
    If the attacker is able to intercept the traffic, then why not just intercept the user/password phase? If the client sends the password unencrypted to the server, then an attacker can read it there. If the client sends the token encrypted, then the the attacker doesn't need to be able to decrypt it.
    – tylerl
    Aug 3, 2013 at 21:40

You must log in to answer this question.

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