Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

We are working on a new project, we are two lead developers and got on a cross road on how to use a token to secure the communication between the server and the client :

First Suggestion : (The one time token AKA Static Token)

Step one) the client requests a primary token, by sending the username and password and the current_time (this variable will be saved in the server's database and the client side too) to the api, the server interprets the input, and renders a hashed token (e.g. : 58f52c075aca5d3e07869598c4d66648) saves it in the database and returns it to the client.

Step Two) The client now saves the primary token, and creates new hashed token using the primary token + the current_time variable sent in the authentication request (lets call this new token, main_token) also the server does the same and create the same token using the same algorithm.

Step Three) Each time the client queries the server API, it sends the main_token to the server, now the server compares the token generated in it, with the main_token sent by the client, if it matches, it means the user is real

Second Suggestion : (Dynamic Token)

Step One) The client generates two random keys ($key1 = rand(10000,90000); $key2 = rand(10000,90000);) On each request on the API, the client creates a hash using the query type, and the two keys with a complex algorithm, and sends these two keys + the hash to the server

Step Two) The server, using the same Algorithm used in the client, creates a hash, and compares is to the one sent by the client, if it matches, the server proceeds to deal with the query


Now, the question is, Which one is the most logical, and secure way to use for securing the api requests

Best Regards

share|improve this question
    
How is the second one even an authentication medium? There must be something originating from the server which the client uses in the auth technique, otherwise there's no way to know if the client just made up the key. In the second technique, what does the server originate when the login completes that it gives to the client to guarantee the client is the same one it gave that to? –  Jimmy Hoffa Jul 19 '13 at 1:48

1 Answer 1

up vote 6 down vote accepted

I really like the first approach in general.

  • it's simple to understand and implement
  • it's secure (to my knowledge)
  • it's a not uncommon approach which I've seen used in the past

One thing I don't see mentioned about the first that you should keep in mind, the timestamp used to hash the token needs to have a TTL expiry that's exceedingly short (like 1 second) so you verify the message wasn't sent with the same timestamp and token from a message 12 hours earlier; obviously it would calculate as legit but is not in this case.

If these are the only two options you're considering though I'd just like to make sure you've looked at other approaches too, as there are many. More than I'm going to list in fact. These are some common auth approaches which are worth studying just to see if they might fit your purpose better, and if nothing else understanding them may give you some ideas to help tighten up whichever approach you do go with.

Do note, I am not a security expert.


OAuth/Federated

In this approach you have a 3rd party guarantor where the consuming code requests the token/cert/what have you from them and passes that to you, at this point all you need to do is ask the 3rd party if the key you were given is legit.

Pro:

  • Standards based
  • Issues will be found by others on other people's systems so you will find out if insecurity happens
  • Much less auth work will be needed by you

Con:

  • You have to deal with a 3rd party servicer and their API, or create and host your own "3rd party" to segregate the auth out of your main service.
  • For many services overkill, but conceptually worth considering

Asynchronous Certificates

Here you would have your clients encrypt their communications with a public cert you have shared with them when they created a user. On your side you would decrypt using the private key associated with there user. Generally you would initiate the communication with a challenge-response to show they can encrypt/decrypt as you expect identifying them as who they claim to be. Though "synchronous" approaches are possible which don't use the challenge-response, they have slightly less security and some time synchronization issues which can make them trickier.

from Novell (yeah I know, novell? really?)

Tokens use a variable as the basis to generate the one-time password. This variable is called the challenge. The two main methods for determining the variable used to generate the password are asynchronous or synchronous.

With the asynchronous or challenge-response method, the server software sends the token an external challenge---a randomly generated variable--- for the token device to encrypt. The token uses this challenge variable, the encryption algorithm, and the shared secret to generate the response---the correctly encrypted password.

With the synchronous method, the challenge variable used to generate the password is determined internally by the token and the server. A time counter, event counter, or time and event counter combination within each device is used as the basis for the challenge variable. Because the token and the server each separately and internally determine the challenge variable from their own counters, it is very important for their time counters and the event counters to stay synchronized. Because it is so easy for the server and the token to get out of sync, most implementations allow for a certain amount of drift between the counters. Usually, a small range or window of these counter values is used to compute the password. However, if the token and server get out of sync beyond this window, a special procedure is necessary to synchronize them.

Pro:

  • Certificates have CA roots which make them trustworthy and difficult to forge
  • There are standard facilities in operating systems for managing and maintaining cert stores easily
  • Well-studied approach, lots of information available on it
  • Expiry along with a variety of other things are in-built facilities of standard certificates, they are generally robust

Con:

  • Certificates can be tricky to work with programmatically
  • Depending on if you require an external CA, may not be free
  • May need to maintain cert stores manually to ensure expected root trusts are configured

NTLM

Don't laugh, if this is a smaller or internal only service and you're in a windows environment, there is nothing wrong with using standard NTLM authentication to guarantee access. Especially if you're working with IIS this is hands down the simplest approach. Easy to maintain and configure as well in a web.config.

Pro:

  • Extremely easy to configure, implement, and maintain

Con:

  • Minimal interoperability
  • Not sufficient for public facing authentication

Nonces

When working with nonces in your authentication approach, you supply a method to get a nonce on the service. This method returns a unique arbitrary string or piece of data ("a nonce") on each request. Every request to other methods now require a nonce to be retrieved, and used in the crypto algorithm for the request. The value here is that the server keeps track of the nonces used, and never allows reuse of a nonce, this completely prevents replay attacks because once a request with one nonce is made, a request with that nonce can never be made again. As nonces are requested they're added to a list of available nonces, as they're used they're moved from the available list to the used list. When generating a nonce you ensure what you generate is not on the used list and the available list will never again have one of the old ones and therefore no repeats can be made.

Pro:

  • Thwarts replay attacks quite well
  • Not altogether difficult to implement or understand

Con:

  • Requires clients make two requests for each one request (though may be lessened by requiring nonces for only certain requests)
  • Requires management of nonces, which should be transactional
  • Negatively affects performance by requiring the extra requests for nonces (transactionality further increases resource cost of working with nonces)
share|improve this answer
    
I suspect the TTL might need to be longer than a second, though shorter than a minute (assuming HTTP/HTTPS as the transport). The TTL depends on the time-lag of the transport (i.e., much longer for email than for direct connection). –  Donal Fellows Jul 19 '13 at 6:00
1  
You forgot kerberos. And I'd put an exceptionally strong warning against rolling your own authentication / token package like the question suggests. RYO auth is very easy to get wrong; an example would be using a seeding key space of only 80,000 5 digit numeric values (from OP's 2nd case). You also have to be careful in what hashes you use (from 1st case). Many are now trivially broken from rainbow table lookups. –  GlenH7 Jul 19 '13 at 11:12
1  
Thank you very much with the answer, I've moved from that project, but I will keep this Question in my favourites. Sorry that I didn't accept your answer as it is very thorough. But, whats up with novell being bad? :( –  SAFAD Jan 13 at 21:07
    
@SAFAD nothing bad about Novell, I was just thrown when looking for resources on security details that I found something modern from Novell, I thought that company died out ages back.. Granted they were ahead of the game in their day but that was a long time ago now. I appreciate the accept all the same, as Glen above mentions it could be more thorough but I tried to give a simplistic overview of normal approaches. Kerberos is a pretty big oversight and good choice..perhaps I'll add it now.. –  Jimmy Hoffa Jan 13 at 21:35

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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