Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Secure Your REST API

stormpath.com

Post reply on HN
Print view View original

51–60 of 80 posts

Re: Secure Your REST API

#51

Post by bradleyjg »

tptacek wrote: post #13

You 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…

The one true solution is client authenticated TLS. For the life of me I can't understand why 25 years later certificate management is still such a mess. 

We don't need some perfect universally recognized root trust system to get started. Why doesn't the sign up process for authenticated API access routinely include the issuance of a certificate signed by the API owner?

Unlike for interactive users there's no expectation that a customer will be accessing an API from some random computer where he might not have access to his certificate store. 

Re: Secure Your REST API

#52

Post by tptacek »

bradleyjg wrote: post #51
tptacek wrote: post #13

You 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…

The one true solution is client authenticated TLS. For the life of me I can't understand why 25 years later certificate management is still such a mess. We don't need some perfect universally recognized root trust system to get started. Why doesn't the sign up process for authenticated API access routinely include the issuance of a certificate signed by the API owner? Unlike for interactive users there's no expectati…

The user interface in browsers for client certificates is appalling.

The API support in client SSL libraries for managing multiple certificates, for applications with multiple API affiliations, is shaky.

I like TLS client authentication a lot, but it's hard to make it work.

Re: Secure Your REST API

#53

Post by veesahni »

tptacek wrote: post #13

You 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…

If you don't need delegation, there are a number of simple but secure methods: HTTPS + token via Basic auth seems quite popular.

What simple but secure methods are there where delegation is required? Is there something simpler than OAuth or AWS style signed HMAC?

Re: Secure Your REST API

#54

Post by CodeMage »

tptacek wrote: post #29
redblacktree wrote: post #28

Earlier quoted context omitted.

Even if you use HTTPS, aren't you vulnerable to lazy devs who put the password in the URL? If I use https://username:password@example.com/ , doesn't that URL show up in server logs all over the internet?

Don't ever use passwords for API authentication. It's an API, not a browser. The users of an API are other programs, not people. Issue single-purpose random credentials. I didn't think this was something I had to point out about API authentication, but apparently it is.

I have a stupid question: how do you do this with HTTP Basic auth?

Re: Secure Your REST API

#55

Post by bradleyjg »

tptacek wrote: post #52
bradleyjg wrote: post #51

Earlier quoted context omitted.

The one true solution is client authenticated TLS. For the life of me I can't understand why 25 years later certificate management is still such a mess. We don't need some perfect universally recognized root trust system to get started. Why doesn't the sign up process for authenticated API access routinely include the issuance of a certificate signed by the API owner? Unlike for interactive users there's no expectati…

The user interface in browsers for client certificates is appalling. The API support in client SSL libraries for managing multiple certificates, for applications with multiple API affiliations, is shaky. I like TLS client authentication a lot, but it's hard to make it work.

I agree it's awful to use, but what I don't understand is why no one has bothered to improve the tools.

It's one of those areas where the underlying tool (either a library like openssl or NSS, or an OS feature like SSPI) could do the hard work in one place and make it simple for downstream libraries to wrap the functionality.

In other, somewhat analogous, domains that happened, but for whatever reason not in this case.

Re: Secure Your REST API

#56

Post by tptacek »

CodeMage wrote: post #54
tptacek wrote: post #29

Earlier quoted context omitted.

Don't ever use passwords for API authentication. It's an API, not a browser. The users of an API are other programs, not people. Issue single-purpose random credentials. I didn't think this was something I had to point out about API authentication, but apparently it is.

I have a stupid question: how do you do this with HTTP Basic auth?

Generate random long passwords.

Re: Secure Your REST API

#57

Post by yoava »

knkella wrote: post #31

What are your thoughts on Amazon like security scheme? As far as there are no third party apps involved, I think OAuth is an overkill. What I mean by Amazon like securtiy is described in this article http://www.thebuzzmedia.com/designing-a-secure-rest-api-with...

Thanks for the pointer, I was looking for a sane explanation of the Amazon security and signature algorithm.

I have to disagree with the other comments here regarding the client library. I think that given the precedence of Amazon API, given that people understand how to sign APIs like amazon, this method will be accepted even without a client library.

Being a Java / Scala dev, I prefer that an API provider allow me to select the HTTP client libraries to use and prevent from forcing me to use a specific library & version via SDK transitive dependencies.

Re: Secure Your REST API

#58

Post by bct »

lhazlewood wrote: post #47
bct wrote: post #42

Earlier quoted context omitted.

I'm pretty sure he means RFC 2617 Digest authentication. There's nothing browser-specific about it.

I gathered as much. But in practice, how often do you see RFC 2617 Digest authc used in non-browser scenarios? (I'm genuinely curious. I haven't seen it used much at all outside of web browsers, so I'm curious what others may have come across).

I've written Atom Publishing Protocol servers that use it. It's not badly-suited for non-browser tasks (although yes, SSL and Basic is much simpler - if you don't mind paying for the certificate). It's unusual, but it's pretty unusual to use it (or Basic) for web browsers these days, too.

Re: Secure Your REST API

#59

Post by [deleted] »

lhazlewood wrote: post #47
bct wrote: post #42

Earlier quoted context omitted.

I'm pretty sure he means RFC 2617 Digest authentication. There's nothing browser-specific about it.

I gathered as much. But in practice, how often do you see RFC 2617 Digest authc used in non-browser scenarios? (I'm genuinely curious. I haven't seen it used much at all outside of web browsers, so I'm curious what others may have come across).

[deleted]

Re: Secure Your REST API

#60

Post by healsjnr1 »

tptacek wrote: post #13

You 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…

I also wouldn't put too much value in a security article served on page using mixed HTTP and HTTPS. This shows a distinct lack of regard for and understanding of security.
Post reply on HN