10 ms·

Ask HN: How are you authenticating rest service clients

14 points by devb0x 13y ago

I've been playing with asp.net webapi and basic auth header (with user:pass in base 64). If you have a angular or knockout front end, are you storing the login details in a cookie and passing in the header, or via a token? Where are you storing that token? I am new to this sort of api / javascript front end and want to deal with security according to best practice. What do you recommend?

jo_ 13y ago
Speaking purely from the backend, our login function takes the IP address of the requester, the login name, and password, then checks the password against the database. If the password matches up, the current date and time, the current IP, the current time, the session expiration date, and a buttload of details about the host machine are hashed together and encrypted with the system's public key before being sent back as a token. It's up to the client to store the token however it likes, but our reference implementation stores it as a cookie on the local machine. If a new request comes from an IP address which doesn't match the encrypted token, or if there are system details in the encrypted token which don't match up with the one on file (we restrict sessions to single instances), then the request is rejected.
- devb0x 13y ago
  thanks, so basically you're hashing a token a each time a request comes in you decode.. do you increase the session expiration date or keep it as is?
junto 13y ago
We use ServiceStack with .NET and love it. ServiceStack uses a HTTP cookie and supports a variety of authentication options out of the box, including basic auth. https://github.com/ServiceStack/ServiceStack/wiki/Authentication-and-authorization https://github.com/ServiceStack/ServiceStack/wiki/Authentica... We also use the easy hooks that ServiceStack offers to validate API developer / app tokens as well. Social Bootstrap API is a backbone example: https://github.com/ServiceStack/SocialBootstrapApi https://github.com/ServiceStack/SocialBootstrapApi https://github.com/ServiceStack/ServiceStack.Examples https://github.com/ServiceStack/ServiceStack.Examples http://stackoverflow.com/questions/15862634/in-what-order-are-the-servicestack-examples-supposed-to-be-grokked/15869816#15869816 http://stackoverflow.com/questions/15862634/in-what-order-ar... It also has various other goodies, such as: https://github.com/ServiceStack/ServiceStack/wiki/Metadata-page https://github.com/ServiceStack/ServiceStack/wiki/Metadata-p... https://github.com/ServiceStack/ServiceStack/wiki/The-IoC-container https://github.com/ServiceStack/ServiceStack/wiki/The-IoC-co... https://github.com/ServiceStack/ServiceStack/wiki/Plugins https://github.com/ServiceStack/ServiceStack/wiki/Plugins https://github.com/ServiceStack/ServiceStack/wiki/Clients-overview https://github.com/ServiceStack/ServiceStack/wiki/Clients-ov... It also doesn't require ASP.NET and can run on Unix under Mono. Try it, you won't go back to WebAPI is guarantee it!
- devb0x 13y ago
  gees thank you for all that Junto!
tptacek 13y ago
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.
- bmelton 13y ago
  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.
  - BillinghamJ 13y ago
    The token is held by the client using the API.
    - bmelton 13y ago
      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."
      - BillinghamJ 13y ago
        I actually just wrote a bit about that :) https://news.ycombinator.com/item?id=6858572 https://news.ycombinator.com/item?id=6858572 > is SSL good enough 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.

14 points by devb0x 13y ago

jo_ 13y ago

Speaking purely from the backend, our login function takes the IP address of the requester, the login name, and password, then checks the password against the database. If the password matches up, the current date and time, the current IP, the current time, the session expiration date, and a buttload of details about the host machine are hashed together and encrypted with the system's public key before being sent back as a token. It's up to the client to store the token however it likes, but our reference implementation stores it as a cookie on the local machine. If a new request comes from an IP address which doesn't match the encrypted token, or if there are system details in the encrypted token which don't match up with the one on file (we restrict sessions to single instances), then the request is rejected.

devb0x 13y ago
thanks, so basically you're hashing a token a each time a request comes in you decode.. do you increase the session expiration date or keep it as is?

junto 13y ago

We use ServiceStack with .NET and love it. ServiceStack uses a HTTP cookie and supports a variety of authentication options out of the box, including basic auth. https://github.com/ServiceStack/ServiceStack/wiki/Authentication-and-authorization https://github.com/ServiceStack/ServiceStack/wiki/Authentica... We also use the easy hooks that ServiceStack offers to validate API developer / app tokens as well. Social Bootstrap API is a backbone example: https://github.com/ServiceStack/SocialBootstrapApi https://github.com/ServiceStack/SocialBootstrapApi https://github.com/ServiceStack/ServiceStack.Examples https://github.com/ServiceStack/ServiceStack.Examples http://stackoverflow.com/questions/15862634/in-what-order-are-the-servicestack-examples-supposed-to-be-grokked/15869816#15869816 http://stackoverflow.com/questions/15862634/in-what-order-ar... It also has various other goodies, such as: https://github.com/ServiceStack/ServiceStack/wiki/Metadata-page https://github.com/ServiceStack/ServiceStack/wiki/Metadata-p... https://github.com/ServiceStack/ServiceStack/wiki/The-IoC-container https://github.com/ServiceStack/ServiceStack/wiki/The-IoC-co... https://github.com/ServiceStack/ServiceStack/wiki/Plugins https://github.com/ServiceStack/ServiceStack/wiki/Plugins https://github.com/ServiceStack/ServiceStack/wiki/Clients-overview https://github.com/ServiceStack/ServiceStack/wiki/Clients-ov... It also doesn't require ASP.NET and can run on Unix under Mono. Try it, you won't go back to WebAPI is guarantee it!

devb0x 13y ago
gees thank you for all that Junto!

tptacek 13y ago

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.

bmelton 13y ago
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.
- BillinghamJ 13y ago
  The token is held by the client using the API.
  - bmelton 13y ago
    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."
    - BillinghamJ 13y ago
      I actually just wrote a bit about that :) https://news.ycombinator.com/item?id=6858572 https://news.ycombinator.com/item?id=6858572 > is SSL good enough 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.