Is this a secure solution for RESTful authentication?

Question

I need to quickly implement a RESTful authentication system for my JavaScript application to use. I think I understand how it should work, but I just want to double check. Here's what I'm thinking -- what do you guys think?

Database schema

users

• id : integer
• first_name : varchar(50)
• last_name : varchar(50)
• password : varchar(32) (MD5 hashed)
• etc.

user_authentications

• id : integer
• user_id : integer
• auth_token : varchar(32) (AES encrypted, with keys outside database)
• access_token : varchar(32) (AES encrypted, with keys outside database)
• active : boolean

Steps

The following happens over SSL. I'm using Sinatra for the API.

1. JavaScript requests authentication via POST to /users/auth/token.
2. The /users/auth/token API method generates an auth_token hash, creates a record in user_authentications, and returns auth_token.
3. JavaScript hashes the user's password and then salts it with auth_token -- SHA(access_token + MD5(password))
4. POST the user's username and hashed+salted password to /users/auth/authenticate.
5. The /users/auth/authenticate API method will verify that SHA(AES.decrypt(access_token) + user.password) == what was received via POST.
6. The /users/auth/authenticate will generate, AES encrypt, store, and return an access token if verification is successful; otherwise, it will return 401 Unauthorized.
7. For any future requests against the API, JavaScript will include access_token, and the API will find the user account based on that.

Answer 1

No, it's not secure, and it seems unnecessary complex.

In particular:

• No reason to encrypt tokens on a database level. If an attacker can get password hash (has access to DB), he can get brand new tokens.
• No session expiration described.

This can help: OWASP REST Security Cheat Sheet, Authentication Cheat Sheet

Answer 2

As Donal Fellows said, this is just wasting time. If you don't have a secure channel, you should get one instead of reinventing the wheel. If you already have a secure channel, then you don't need another (inferior) encryption mechanism...