Don't use usernames and passwords as API authentication. Generate a random 128 bit token for each user (RNGCryptoServiceProvider, GetBytes on a 16-byte array) and pass that as a header (or as Authorization). Make sure your API endpoints require HTTPS.
If you have an API call for logging the user in with a username & password which only your app should use, and you're (very) paranoid about someone else using that call, consider using a client SSL certificate.
Securing the request via a client SSL certificate will prevent the replication of that request by another app unless they go to the lengths required to actually disassemble your app.
2 - token generation
In the OAuth implementation for the system I'm currently working on, we decided to simply encrypt the ID of the row (plus a salt) for that access token, rather than generating a random string.
This has two benefits:
- it is extremely fast to look up the access token in the database, since we're using the primary key, rather than searching for a string
- no possibility of collisions
If this is a flawed approach, please let me know. We're using AES & are encrypting "AccessToken" + ID, so replay attacks from other encrypted data aren't possible.
Let me explain a little better -- I completely get how to handle token based / API key authentication over REST. That's pretty straightforward... but in order for the client to get the API Key, they have to sign up, log in, potentially activate the token, or at least visit a page that gives them the token, and then they can use that token for subsequent API transactions.
My question revolves around how one secures the username/password authentication over REST for those initial phases.
I've been just handling traditional logins in the old client/server, non-REST model, and then, on login, setting a cookie with the token, that I then use to authenticate the other application interactions.
For username/password over REST, is SSL good enough? I don't know, and I've never wanted to guess and be wrong. I've looked it up a couple of times, but advice on the subject ranges broadly between "don't ever do that" and "sure, it's fine."
It will protect the password from potential MITM attack (assuming the user hasn't accepted a bad SSL certificate & you are checking that the cert is valid).
However, if someone MITMs your app for the purpose of reverse engineering, they will very easily see that the username/password API call is available & there will be nothing tangibly stopping them from using it.
By using a client SSL certificate in addition to the normal server-side SSL for 'restricted endpoints', other apps will not be able to replicate the request & it will also not be visible even in MITM attacks where the certificate is trusted.
If the private key for your client SSL certificate is leaked/found/reverse engineered/disassembled though, that protection is gone. Assuming it is actually compiled into your binary though, this is not trivial.
following on bmeltons question, the user must still log in, so the username / password is only entered once and this token is then returned? What about session expiration, how is that determined, and what about a user logging on from different devices - a token for each device ?
Comments
Don't use usernames and passwords as API authentication. Generate a random 128 bit token for each user (RNGCryptoServiceProvider, GetBytes on a 16-byte array) and pass that as a header (or as Authorization). Make sure your API endpoints require HTTPS.
Couple of additions:
1 - plain username/password
If you have an API call for logging the user in with a username & password which only your app should use, and you're (very) paranoid about someone else using that call, consider using a client SSL certificate.
Securing the request via a client SSL certificate will prevent the replication of that request by another app unless they go to the lengths required to actually disassemble your app.
2 - token generation
In the OAuth implementation for the system I'm currently working on, we decided to simply encrypt the ID of the row (plus a salt) for that access token, rather than generating a random string.
This has two benefits:
- it is extremely fast to look up the access token in the database, since we're using the primary key, rather than searching for a string
- no possibility of collisions
If this is a flawed approach, please let me know. We're using AES & are encrypting "AccessToken" + ID, so replay attacks from other encrypted data aren't possible.
I assume this is predicated on an initial username/password auth for identification? If not, how do you deal with token assignment?
E.g., if I log in today, then come back on a different computer, how do you know to give me the same token?
I've always copped out on REST auth and just gone client/server for authentication, with REST for everything else, for fear of fucking it up.
The token is held by the client using the API.
Let me explain a little better -- I completely get how to handle token based / API key authentication over REST. That's pretty straightforward... but in order for the client to get the API Key, they have to sign up, log in, potentially activate the token, or at least visit a page that gives them the token, and then they can use that token for subsequent API transactions.
My question revolves around how one secures the username/password authentication over REST for those initial phases.
I've been just handling traditional logins in the old client/server, non-REST model, and then, on login, setting a cookie with the token, that I then use to authenticate the other application interactions.
For username/password over REST, is SSL good enough? I don't know, and I've never wanted to guess and be wrong. I've looked it up a couple of times, but advice on the subject ranges broadly between "don't ever do that" and "sure, it's fine."
I actually just wrote a bit about that :)
https://news.ycombinator.com/item?id=6858572
In my opinion, no.
It will protect the password from potential MITM attack (assuming the user hasn't accepted a bad SSL certificate & you are checking that the cert is valid).
However, if someone MITMs your app for the purpose of reverse engineering, they will very easily see that the username/password API call is available & there will be nothing tangibly stopping them from using it.
By using a client SSL certificate in addition to the normal server-side SSL for 'restricted endpoints', other apps will not be able to replicate the request & it will also not be visible even in MITM attacks where the certificate is trusted.
If the private key for your client SSL certificate is leaked/found/reverse engineered/disassembled though, that protection is gone. Assuming it is actually compiled into your binary though, this is not trivial.
I like client certificates and use them myself, but be forewarned that requiring them is a good way to ensure that very few people use your API.
following on bmeltons question, the user must still log in, so the username / password is only entered once and this token is then returned? What about session expiration, how is that determined, and what about a user logging on from different devices - a token for each device ?