Question

I am building an application which requires the user to login at start-up.

The authentication process is as follows:

• User inputs username / password.
• client sends username + password to Web Service.
• Web Service authenticates the user with hashed password from the DB.

• Web Service returns a token to the client which contains one of those three values:

  1) Username is invalid.

  2) Password is invalid.

  3) User is authenticated.

• The token is used by the client to determine the next course of action.

• The token is passed to the service with every subsequent calls made by the client. The service rejects the call if the user is not authenticated.

The token is encapsulated within a DTO, which is a DataContract. The token itself is a DataMember. DataMembers require that the property have a setter and a getter. This means that clients are now able to set a value for the token, which is bad. Clients could now technically flag themselves as authenticated.

How would I go about preventing clients from modifying the value of the token ? Are there any patterns that could help me here ?

Answer 1

The server must ‘know’ the token and validate it.

There’s no way that you can restrict the client from changing the token. Think about it – I send you a DTO, basically a bundle of information. Later on, you send that bundle back to me. How could I possible stop you from changing what’s in the bundle? The only thing I can do is check that the bundle is valid, you haven’t changed anything that I don’t expect you to change, and so on.

If your token is a simple authenticated flag then that’s a bit of a disaster. Imagine a website that accepted a logged in parameter that just trusted me. You tell the webserver that you’re logged in and it believes you? www.visa.com/account.html?account=123456&loggedIn=true doesn’t seem very secure.

In platform agnostic world you can use encryption to create a secure token that can be validated. You already have a token, so perhaps you could add some encrypted content to the token that validates a user. The client doesn’t know what the data is, and can’t decrypt it easily. They need to return the token to the server on each request. The server can decrypt the token which confirms that the user is authenticated.

Of course the tokens need to expire, and need to be secure and un-guessable. In a Windows world it might be simpler to use Windows authentication, or one of the rolled-in .NET authentication patterns.