Modern client/server authentication techniques

Question

I'm building a non-browser client-server (XULRunner-CherryPy) application using HTTP for communication. The area I'm pondering now is user authentication. Since I don't have substantial knowledge in security I would much prefer using tried-and-tested approaches and ready-made libraries over trying to invent and/or build something myself.

I've been reading a lot of articles lately and I can say all I have been left with is a lot of frustration, most of which contributed by this and this blog posts.

What I think I need is:

• Secure storage of passwords in the database (adaptive hashing?)
• Secure wire transmission of user credentials (digest authentication? SSL?)
• Secure token authentication for subsequent requests (not sure about this)

So the question is: what are the modern (headache-free preferrably) techniques and/or libraries that implement this? (No sensitive information, like credit card numbers, will be stored).

I've been looking at OAuth and they have a new revision which they strongly recommend to use. The problem is the docs are still in development and there are no libraries implementing the new revision (?).

Answer 1

This may not be a complete answer, but I would like to offer some reassuring news about rainbow tables and the web. I wouldn't worry too much about Rainbow Tables with regards to the web for the following reasons:

(1) Rainbow table cracks work by examining the hashed password. On the web, the hashed password is stored on your database so to even consider using rainbow tables one would first need to hack your entire database.

(2) If you use a salt as most password storage systems do, then rainbow tables rapidly become unfeasible. Basically a salt adds a series of extra bits to the end of a given password. In order to use a rainbow table, it would need to accommodate the extra bits in each plaintext password. For example the first link you showed us had a rainbow table implementation that could crack up to 14 characters in a password. Therefore if you had more than 14 bytes of a salt that system would be useless.

Answer 2

Amazon Web Services, OpenID, and OAuth have examples of request signing. Amazon Web Services is an easy example to follow because there isn't a more complex protocol around the interactions. They basically involve having the client or server sign a request by hashing all of its fields with a previously set up key (or keypair), and having the other end verify the signature by doing the same. Replaying the hash is prevented by including a nonce or timestamp in the fields.

Setting up keys or other credentials to allow this can be done over SSL, and it should be noted that one of the motivation of OAuth WRAP is to replace some or all of this request signing with SSL, for ease of implementation.

Answer 3

After a lot of poking around and trying to write my own prototype based on Amazon S3 design which (I thought) was pretty secure, I found this excellent website which has answers to all my questions, an Enterprise Security API Toolkit, and much, much more: OWASP.