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.

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.
share|improve this question
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) –  thorsten müller Oct 28 '13 at 19:22
    
Yep, it'll be over HTTPS, and I'm using Sinatra for the API. –  Chad Johnson Oct 28 '13 at 19:25
1  
If you've already got a secure channel, why use such a complex mechanism? What are you defending against? –  Donal Fellows Oct 29 '13 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? –  Chad Johnson Oct 29 '13 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

share|improve this answer

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

share|improve this answer

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.