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: http://stackoverflow.com/questions/290405/is-using-a-guid-security-though-obscurity

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