Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I'm looking for a low CPU intensive encryption algorithm, to pass around session authentication tokens.

As an example:

  • The user will login in to the website (via OAuth, whether by the site as provider or an external provider)
  • Regardless of how they were originally authenticated, a new, randomly produced session token (in this case a 64 character length string) is associated with their account and is stored in a cookie.
  • On each new page request, the session token is taken from the cookie, encrypted with a time-based nonce (to prevent replay) and placed in the headers as a meta tag and rendered.
  • The user does something which fires off an javascript AJAX request to the site's API. The javascript picks up the encrypted token from the meta tag.
  • The API receives the params, takes out the encrypted info and decrypts it.
  • Stuff happens…

Obviously, this could end up in a lot of encryption. Granted, the data will only be small, but it's the volume that worries me. To that end I'm looking for an encryption algorithm that:

  • Is low on the CPU use
  • Widely available would be nice.
  • Easy to use would be nice.

I've had a look around, but the detail of some of the comparisons I've seen is beyond my knowledge to be entirely helpful. If anyone could give a suggestion, that would be helpful. Also, if anyone sees a glaring hole with the security in the above example, please let me know.


Extra info due to the comments:

  • SSL would be used for all communication.
  • The (whole) cookie is encrypted using AES. The specific key value pairs are not.
  • I don't wish to manipulate the value using the browser, I want the already encrypted value to be sent via AJAX and then decrypted server side in the data API.
  • I don't wish the user themselves to have access to an unencrypted session token.
  • Most state is kept in the database, the session token is just there to let the API know who's making requests. Barely anything else is kept client side.

The main reason for this kind of set up is to allow many different clients to access the API via HTTPS, whether it's web or mobile or whatever, so the data API server may not reside on the same box as the website, and the website has no direct access to the database.

share|improve this question
1  
What's wrong with standard block ciphers like AES? On modern CPUs the overhead is minuscule. –  Polynomial Feb 4 '13 at 13:20
    
@Polynomial I don't know, which is why I asked the question :) –  Iain Feb 4 '13 at 13:20
    
Beware : manipulating cookies with javascript will prevent you from using http only cookies, which increases the risk associated with cross-site scripting (XSS). Complexity is the ennemy of security. –  ixe013 Feb 4 '13 at 14:13
1  
Should you decide to do cryptography in the browser, you might want to look at the Stanford Javascript Crypto Library. –  ixe013 Feb 4 '13 at 14:14
1  
@ixe013 I don't wish to do any client side manipulation, but thanks for the link, very helpful. I've updated my question too to make it clearer. –  Iain Feb 4 '13 at 14:40

1 Answer 1

up vote 2 down vote accepted

Your use case is a bit strange. As a basic rule, you need SSL if the data you exchange between the server and the Ajax client is sensitive in any way; you need it both for confidentiality and for integrity. And if you have SSL, then you have all that you need; in particular, you defeat replay attacks (that's a feature of SSL).

You would have to fiddle with encryption only if you want to offload some of your storage on the client; that is, you maintain some user-specific state but do not want to pay for the corresponding database. Instead, you send that state to the client itself, to be stored either in a cookie or in the entrails of the RAM objects maintained by the Ajax code. In that specific scenario, the client is a potential attacker, and you want that storage to be protected with both encryption and integrity, and with an additional time stamp or counter. That's still a rather edge case and it is hard to get right; it is much easier to simply store the user state in the server's database.

share|improve this answer
    
Thanks for the answer. I've updated the question with a few things that may or may not clarify things. –  Iain Feb 4 '13 at 14:39
    
Having mulled it over I agree, there's no need to encrypt an identifier that is randomly generated and reasonably often regenerated. I suppose I'm just paranoid :) –  Iain Feb 6 '13 at 14:25

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.