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

21–30 of 80 posts

Re: Secure Your REST API

#21

Post by tptacek »

tel wrote: post #17
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…

> 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.

You have one code path that authenticates web users through forms and sets cookies.

You have another code path that authenticates API callers.

You have code scattered through your whole application that makes authorization checks based on which user you're authenticated on.

Inconsistencies between the first two code paths often break that code.

Re: Secure Your REST API

#23

Post by danielweber »

pplante wrote: post #4

In my humble opinion, security through obscurity via UUIDS rather than sequential integers is not great advice. It merely masks the real problem.

Obscurity can be a fine part of being secure. You have to think carefully about what happens when it fails, and realize that automated bots will tend to find things humans would consider obscure, but don't let the usually-good heuristic become a straightjacket.

Re: Secure Your REST API

#24

Post by dllthomas »

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…

Shouldn't HTTP Digest still be preferred, so your server doesn't need to see the passwords?

Re: Secure Your REST API

#26

Post by dllthomas »

danielweber wrote: post #23
pplante wrote: post #4

In my humble opinion, security through obscurity via UUIDS rather than sequential integers is not great advice. It merely masks the real problem.

Obscurity can be a fine part of being secure. You have to think carefully about what happens when it fails, and realize that automated bots will tend to find things humans would consider obscure, but don't let the usually-good heuristic become a straightjacket.

Obscurity of the secret is a necessary part of being secure :-P

Security-through-obscurity refers to the notion that your algorithms are a meaningful part of the key.

Re: Secure Your REST API

#27

Post by tptacek »

dllthomas wrote: post #24
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…

Shouldn't HTTP Digest still be preferred, so your server doesn't need to see the passwords?

That's not how HTTP Digest auth works, and you should never, ever be using "passwords" for API authentication.

Re: Secure Your REST API

#28

Post by redblacktree »

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?

Re: Secure Your REST API

#29

Post by tptacek »

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?

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.

Re: Secure Your REST API

#30

Post by dllthomas »

tptacek wrote: post #27
dllthomas wrote: post #24

Earlier quoted context omitted.

Shouldn't HTTP Digest still be preferred, so your server doesn't need to see the passwords?

That's not how HTTP Digest auth works, and you should never, ever be using "passwords" for API authentication.

Are you saying the server sees the password in HTTP Digest authentication?
Post reply on HN