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

61–70 of 80 posts

Re: Secure Your REST API

#61

Post by bradleyjg »

mcavage wrote: post #43

I expected something very different from this article based on the headline. Specifically, I completely disagree with the "leave it to industry standards" approach, as that doesn't help people understand what they should do, and more importantly, why. Request/response protocols (well, many things) really break down into 5 top-level categories (some sources will say the 6th is Audit): - Authentication - Authorization…

> Mutual-Auth SSL/TLS is a royal PITA, and is basically guaranteed to cause you grief. The client compatibility matrix might as well be considered an NP hard problem to assure yourself coverage, and failure modes of the different browsers/SDKs all differ. As a REST API should have maximum accessibility to clients (i.e., don't wed yourself to any one language/sdk), this is pretty much a non-starter.

Given the inconsistent support for mutual-auth TLS, which along with its direct ancestors has existed for a decade and a half, what makes you think they'll be widespread and correct support for SAS?

Re: Secure Your REST API

#62

Post by mcavage »

bradleyjg wrote: post #61
mcavage wrote: post #43

I expected something very different from this article based on the headline. Specifically, I completely disagree with the "leave it to industry standards" approach, as that doesn't help people understand what they should do, and more importantly, why. Request/response protocols (well, many things) really break down into 5 top-level categories (some sources will say the 6th is Audit): - Authentication - Authorization…

> Mutual-Auth SSL/TLS is a royal PITA, and is basically guaranteed to cause you grief. The client compatibility matrix might as well be considered an NP hard problem to assure yourself coverage, and failure modes of the different browsers/SDKs all differ. As a REST API should have maximum accessibility to clients (i.e., don't wed yourself to any one language/sdk), this is pretty much a non-starter. Given the inconsis…

If by SAS you mean SSH, then really it's that there's a much smaller client surface area (really, openssh), and the fallback is always "use a PKCS#8 private key", which is much more uniform than SSL. SSL mixes in x509, and protocol, and UX.

That said, you don't have to agree with it. My macro point was really assessing these things against basic security threat modeling, not whether or not you agree with our choices of using SSH.

Re: Secure Your REST API

#63

Post by bradleyjg »

mcavage wrote: post #62
bradleyjg wrote: post #61

Earlier quoted context omitted.

> Mutual-Auth SSL/TLS is a royal PITA, and is basically guaranteed to cause you grief. The client compatibility matrix might as well be considered an NP hard problem to assure yourself coverage, and failure modes of the different browsers/SDKs all differ. As a REST API should have maximum accessibility to clients (i.e., don't wed yourself to any one language/sdk), this is pretty much a non-starter. Given the inconsis…

If by SAS you mean SSH, then really it's that there's a much smaller client surface area (really, openssh), and the fallback is always "use a PKCS#8 private key", which is much more uniform than SSL. SSL mixes in x509, and protocol, and UX. That said, you don't have to agree with it. My macro point was really assessing these things against basic security threat modeling, not whether or not you agree with our choices…

Well it's more than SSH. The client library needs to to implement the headers and do the date signing. Sure it's easier than TLS, but the libraries suffers more from a lack of dedicated interest than insane complexity I would think.

But I do agree with your basic point that too many people stop at authentication, instead of considering the full range of concerns.

Re: Secure Your REST API

#64

Post by MattRogish »

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…

So let's say I have an iOS or Android app that needs to talk to my REST API. I have my user login in the app, which does Basic Auth over HTTPS.

Once they're authenticated, I generate a token and send it to them. They store it, and use that token from here on out (HTTPS only).

Perhaps I expire it after some time (hours or days, if I don't want my user to have to login all the time).

That's it? :D Seems like I'm missing something...

Re: Secure Your REST API

#65

Post by jimktrains2 »

tptacek wrote: post #45
dllthomas wrote: post #44

Earlier quoted context omitted.

Well, in this case (having gone back and actually checked the docs rather than relying on recollection roughly a decade old) you could store MD5(username:realm:password) rather than password, though that doesn't buy you all that much in a case like this where making the password a long, random string that's not reused is not only good practice but also easy and so likely to be general practice.

Stipulating all the other points you've made, exactly what is the purpose of hiding from a server a long random string generated by that server and useful only to that server?

Preventing someone else from getting that and using it on the server, especially if the service can rack up charges.

Re: Secure Your REST API

#66

Post by olivier1664 »

redblacktree wrote: post #28
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…

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?

Please correct me if I'm wrong. HTTPS will encrypt the URL, but the DNS lookup is in clear. So the "username:password@example.com" part will be sniffable/loggable.

http://stackoverflow.com/questions/499591/are-https-urls-enc...

Re: Secure Your REST API

#67

Post by jimktrains2 »

lhazlewood wrote: post #37
jimktrains2 wrote: post #33

Earlier quoted context omitted.

No. The UA strips those and puts them in an Auth header.

Depends on the UA (curl?)

OK, so it'll either add an auth header or not know what to do and refuse to do anything. Either way the password is not sent in the request url

Re: Secure Your REST API

#68

Post by dllthomas »

jimktrains2 wrote: post #65
tptacek wrote: post #45

Earlier quoted context omitted.

Stipulating all the other points you've made, exactly what is the purpose of hiding from a server a long random string generated by that server and useful only to that server?

Preventing someone else from getting that and using it on the server, especially if the service can rack up charges.

If you have the hash, you can log into the site (just not using the typical libraries), so it really doesn't add a lot of security. That's why I was wrong :-P

Re: Secure Your REST API

#69

Post by jewel »

olivier1664 wrote: post #66
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?

Please correct me if I'm wrong. HTTPS will encrypt the URL, but the DNS lookup is in clear. So the "username:password@example.com" part will be sniffable/loggable. http://stackoverflow.com/questions/499591/are-https-urls-enc...

That's incorrect. The URI library will parse the URL into a hostname, username, and password. Only the hostname is sent to the DNS server.

The username and password are sent in the "Authorization" HTTP header, which will be encrypted.

Re: Secure Your REST API

#70

Post by carbocation »

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…

Do you think there would be value in accepting HTTP requests and then automatically and immediately expiring every credential that ever gets passed over plain HTTP?
Post reply on HN