How does using bare api keys over TLS compare to these suggestions? It's less secure but is it still a recommended option?
Secure Your REST API
11–20 of 80 posts
Re: Secure Your REST API
#12> Best practices say to encrypt your passwords in the database to limit a potential data breach. This increases overhead for each request when authenticating a user. Unique API keys authentication skips the hashing step and therefore speeds up your calls.
Wait, why can you can skip the hashing step and still be secure? Because hashing is only neccesary if you call it a 'password', but not if you use it in the same way but call it an 'api key' instead?
I guess it depends on the purpose for hashing. If it's just about 'data breaches', then maybe it doesn't matter if your api keys get out... because they at least won't grant access to any _other_ systems, since they weren't manually entered by users and re-used accross systems. Is that what you're thinking?
But don't you still want to avoid a data breach like this for your _own_ service?
And, I think, isn't the other reason hashed passwords are used, to make it harder to do a brute force attack? Ie, it's quite intentional and deliberate that it increases request overhead. And doesn't this still apply to an api key, possibly even MORE so when you have a single api key instead of a username/pass combo?
Re: Secure Your REST API
#13You should probably disregard this advice. Instead:
[Late addition:
* Do not use passwords as API authentication. The user of an API is a computer program, not a human. Issue single-purpose random credentials for API access.]
* Make sure that your API is accessible only over HTTPS; test the API endpoint to ensure requests aren't honored over unencrypted HTTP.
* Use the simplest API authentication mechanism that (a) works and (b) you understand. You should probably degrade the capabilities of your API before you try to adopt an authentication system that you don't completely, fully, absolutely grok.
This means, if you don't need delegation right away (for instance, if you don't have 3rd party applications making calls to your API on behalf of your users), don't bother with anything like OAuth.
Contrary to the implications in this article, HTTP Basic Auth is not less secure than OAuth if your endpoints all require HTTPS. If you allow HTTP calls to an API, you have bigger problems than your auth token scheme.
Semantic mismatches between API endpoints and web UI endpoints (ie, semantic differences between API auth and cookie-based authentication) are a classic, pervasive, hard- to- eradicate source of serious security flaws. Don't make things any more complicated than they need to be.
[Late edit: I didn't think I needed to make the first point, but I clearly did need to. Sorry.]
Re: Secure Your REST API
#14> Best practices say to encrypt your passwords in the database to limit a potential data breach. This increases overhead for each request when authenticating a user. Unique API keys authentication skips the hashing step and therefore speeds up your calls. Wait, why can you can skip the hashing step and still be secure? Because hashing is only neccesary if you call it a 'password', but not if you use it in the same wa…
If you lose the database for your own service, it does not matter how you authenticate to that service. Attackers have already fatally bypassed your credential system. At the same time, API credentials should by definition be single-use.
Re: Secure Your REST API
#15You should probably disregard this advice. Instead: [Late addition: * Do not use passwords as API authentication. The user of an API is a computer program, not a human. Issue single-purpose random credentials for API access.] * Make sure that your API is accessible only over HTTPS; test the API endpoint to ensure requests aren't honored over unencrypted HTTP. * Use the simplest API authentication mechanism that (a) w…
Wow, I don't think I've ever seen tptacek gray in a thread about security. I don't know why, you are absolutely right.
One neat variant on this is how GitHub uses HTTP Basic auth to give you an OAuth token... http://developer.github.com/v3/#authentication
Re: Secure Your REST API
#16In my humble opinion, security through obscurity via UUIDS rather than sequential integers is not great advice. It merely masks the real problem.
This isn't an instance of "security through obscurity". This is more akin to suggesting people use non dictionary passwords.
Re: Secure Your REST API
#17You should probably disregard this advice. Instead: [Late addition: * Do not use passwords as API authentication. The user of an API is a computer program, not a human. Issue single-purpose random credentials for API access.] * Make sure that your API is accessible only over HTTPS; test the API endpoint to ensure requests aren't honored over unencrypted HTTP. * Use the simplest API authentication mechanism that (a) w…
> Semantic mismatches between API endpoints and web UI endpoints (ie, semantic differences between API auth and cookie-based authentication) are a classic, pervasive, hard- to- eradicate source of serious security flaws. Don't make things any more complicated than they need to be.
Could you explain that one in more detail? I don't think I understand it.
Re: Secure Your REST API
#18> Best practices say to encrypt your passwords in the database to limit a potential data breach. This increases overhead for each request when authenticating a user. Unique API keys authentication skips the hashing step and therefore speeds up your calls. Wait, why can you can skip the hashing step and still be secure? Because hashing is only neccesary if you call it a 'password', but not if you use it in the same wa…
If you lose the database for your own service, it does not matter how you authenticate to that service. Attackers have already fatally bypassed your credential system. At the same time, API credentials should by definition be single-use.
> At the same time, API credentials should by definition be single-use.
Could you spell this one out a little bit more? Do you mean only a single session should be able to use an API credential?
Re: Secure Your REST API
#19Earlier quoted context omitted.
If you lose the database for your own service, it does not matter how you authenticate to that service. Attackers have already fatally bypassed your credential system. At the same time, API credentials should by definition be single-use.
> At the same time, API credentials should by definition be single-use. Could you spell this one out a little bit more? Do you mean only a single session should be able to use an API credential?
I mean the credential should only be relevant to the service, never shared across multiple services, because the API generates it for you.
Re: Secure Your REST API
#20How does using bare api keys over TLS compare to these suggestions? It's less secure but is it still a recommended option?
The advantage to OAuth over basic-auth is that you can delegate the credentials, which is to say you can set up your system so that users can give a limited-use credential to a 3rd party application to perform API calls on their behalf.
Some very large services have abused OAuth to "delegate" credentials to mobile devices, which has set up the expectation among developers that OAuth is the "sophisticated" way of doing all-around credential management of any sort. Not so. If you don't have delegation to third parties, don't use OAuth.
Most applications do not need delegation.
If you need delegation, there are simpler ways to do it than OAuth that won't meaningfully sacrifice the security of your controls. At the same time, using an OAuth solution you don't fully understand (for instance, using OAuth through a high-level library that hides the details from you) can damage the integrity of your whole application by creating new classes of mistakes for you to make.