1

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 ?

Hussein Khalil
  • 1,585
  • 2
  • 25
  • 47
  • 1
    Just a note, you should combine 1 & 2. Since an attacker can detect from the message "Password is invalid" `OK, a valid username is found`. This is why most systems respond as "invalid username or password" – L.B Aug 19 '12 at 23:07
  • @L.B: Excellent argument, thank you I will do that. I learn something new everyday :) – Hussein Khalil Aug 19 '12 at 23:11

1 Answers1

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.

Kirk Broadhurst
  • 27,836
  • 16
  • 104
  • 169
  • You make excellent points, and you're right in saying that only having a flag is a recipe for disaster. Just to make sure I understood correctly, the token itself should be encrypted ? If so, the client should use something else than the token to determine if the authentication succeeded or not ? (since the token is encrypted). If so, what would be the most secure way of telling the client the authentication succeeded, without jeopardizing the security of the token ? (i.e.: client knows that the authentication succeeded, doesn't care that the token is encrypted anymore). – Hussein Khalil Aug 19 '12 at 23:22
  • 1
    How about `if (token != null) { authenticated = true; }`? Does the rest of the DTO contain some information? I assume if the client doesn't authenticate then you don't return any other information...? – Kirk Broadhurst Aug 19 '12 at 23:29
  • You're correct, this will do nicely. The DTO doesn't contain anything else than the token. If I understood correctly, this would deter attackers since they would have no idea what the token means, correct ? (i.e.: they won't know that token != null == authenticated) – Hussein Khalil Aug 20 '12 at 00:26
  • 1
    @HusseinKhalil if I were an attacker I'd assume that null means I wasn't authenticated, but the purpose of this exercise is to stop people from spoofing their own authentication. I don't know what type of hackers you have in mind, but that might be another question. – Kirk Broadhurst Aug 20 '12 at 00:37