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


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


  • 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


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.
  • 1
    Unless you use HTTPS this is most likely vulnerable against various attacks at least from within the same network (especially public wifi access points). From other posts it looks like you use Rails, there are many gems that handle user authentication like AuthLogic or Devise. Using those would protect you against a few problems you may easily overlook when implementing your own solution (and maybe offer some functionality you didn't even consider yet) Oct 28, 2013 at 19:22
  • Yep, it'll be over HTTPS, and I'm using Sinatra for the API. Oct 28, 2013 at 19:25
  • 2
    If you've already got a secure channel, why use such a complex mechanism? What are you defending against? Oct 29, 2013 at 19:23
  • @Donal That's true...maybe this is overkill. How would you do it? If using SSL, would you keep it simple and 1) send passwords via REST POST in plain text (encrypted via SSL) and 2) just assign a token for each user account and send that in each user's API request? Oct 29, 2013 at 19:30

2 Answers 2


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


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...

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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