0

I am developing a RESTful API and have considered using OAuth for password flow-like authentication. However, I've decided to implement my own authentication mechanism because I don't want the overhead of utilising OAuth in my project.

Everything is working well, but at the moment I'm not using any form of auth token encryption. What should I be using? Could you provide some articles which could point me in the right direction? The API will be used through HTTPS.

EDIT:

I'm using the following function to generate an access token:

public function generateToken($user)
{
    return hash_hmac('sha256', Str::random(10), $user->id.time().uniqid(), false); 
}

Is this secure enough?

Onion
  • 1,714
  • 1
  • 23
  • 42
  • I suppose your auth token is a random session ID? If my assumptions about your system are correct you don't need to encrypt it at all (given it is always transmitted over HTTPS, as you have said and as you should). Why do you want to encrypt it? – Perseids Jun 30 '14 at 19:28
  • I'm generating the access token manually, using `str_random(40)`. To my knowledge this isn't secure enough. – Onion Jun 30 '14 at 19:49
  • In PHP you can get better random data: http://stackoverflow.com/a/1551064/371137 . There is also a build in session management system, as in most other languages/frameworks. – Perseids Jun 30 '14 at 21:26
  • I would probably still prefer to directly use a cryptographically secure random number generator instead of building a pseudo RNG yourself, but as long as `Str::random(10)` is sufficiently unlikely to repeat itself this should be good. Btw. I'm not sure the first parameter of random is supposed to be a number: http://fuelphp.com/docs/classes/str.html - this might be a problem. – Perseids Jun 30 '14 at 23:08
  • I'm using laravel's `Str` class. – Onion Jun 30 '14 at 23:17
  • I can't help but wonder why shouldn't we encrypt the token. Isn't this essentially the same as sending a user's password in plaintext? The following post suggessts encrypting it: http://security.stackexchange.com/questions/19676/token-based-authentication-securing-the-token – Onion Jul 01 '14 at 08:45
  • Thomas Pornin's answer does not suggest to use any encryption. In fact he recommends random tokens. His alternative MAC solution does not encrypt, but authenticate login data. The reason why you should not add superfluous encryption is because it makes the system as a whole more complex and sometimes adds the illusion of security if there are unrelated problems. – Perseids Jul 01 '14 at 10:43

1 Answers1

0

BCrypt-ruby has an explanation of why to use BCrypt to save secure passwords and has some simple examples of using BCrypt in an authorization scenario.

BCrypt is supported in a bunch of different languages so might be helpful. A simple approach if you are rolling your own Auth system.

doug
  • 1
  • 1
  • As far as I can tell doitmyway isn't asking about how to save the passwords, but what to do after he/she knows who the user is. – Perseids Jun 30 '14 at 21:19
  • In that case the token is really just a flag to say this session is secure. If doitmyway is using HTTPS then it should be no problem. On the other hand if the login is https and then the rest is plain http then he might want to switch to https all the time so the tokens are secure as you stated in your comment. Thanks for the clarification. – doug Jun 30 '14 at 21:53
  • So you're saying that it is okay to simply generate a random string using `str_random(40)` and store it in the database as the user's token (and then use it in requests)? – Onion Jun 30 '14 at 22:13
  • As long as you are using https everything should be encrypted. So if you have properly authorized the user (they have logged in with a password) and the token you are using is for subsequent access (after login so the user doesn't have to login between page refreshes) then the token is basically a lookup value to make sure the session is authorized. This is what I understand you are trying to do. Storing the token on the browser side you should use secure cookies: (http://blog.teamtreehouse.com/how-to-create-totally-secure-cookies) – doug Jun 30 '14 at 22:49
  • "In that case the token is really just a flag to say this session is secure." … "then the token is basically a lookup value to make sure the session is authorized." - Well, no, because if you can successfully guess the token then an attacker can insert the token in her https request and impersonate any user (without authentication) if that user's id is in the lookup table. – Perseids Jun 30 '14 at 23:15
  • To clarify the token on the browser should not be saved past a particular user session you'll have to manage that. Most people use the browser's session-id mechanism as it goes away when the browser is closed or changes if the user starts another session. And usually a session time-out as well. – doug Jun 30 '14 at 23:17
  • @Perseids Shouldn't tokens be used like that? The way I'm using them in my application is this: the user sends the access token through (for example) a POST request; I then check whether a row with such access token exists in the database and if it does, I retrieve the user with which the token is associated with. Is this the right approach? – Onion Jun 30 '14 at 23:21
  • Perseids is correct in that a token should not be easily guessed. I was speaking to mechanism the token is used for: lookup of auth state. The token as you are creating it in your edit would be hard to guess. – doug Jul 01 '14 at 00:04
  • So you're saying that my approach is correct? I'm using the token to find a row in the user tokens table. If the row with the token exists, I return the user_id from that row, which maps to the corresponding user. – Onion Jul 01 '14 at 04:54