31–40 of 80 posts
What I mean by Amazon like securtiy is described in this article http://www.thebuzzmedia.com/designing-a-secure-rest-api-with...
Please stop using the term UUID when you mean 'random alphanumeric string'. Because UUIDs have a standardized format (it's not just a random string): http://en.wikipedia.org/wiki/Universally_unique_identifier
Its 'canonical' form uses HEX-only encoding. A 'Url62' can be another encoding. 'Url62' wouldn't be a canonical encoding, but it's still a 128 bit UUID number.
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?
Earlier quoted context omitted.
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?
Does anyone know of a good reason not to use TLS with client-side certificates (and you as the CA) for API authentication?
Shoots down Basic auth without SSL, without mentioning Digest auth, weird.
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?
No. The UA strips those and puts them in an Auth header.
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...
But per the blog article, you'd only want to do this if you are willing to support client libraries/sdks that implement it as well. No one wants to spend the time to implement non-standard custom HMAC algorithms.
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?
This is one of many benefits of using multiple (revokable) API Keys.
Earlier quoted context omitted.
Are you saying the server sees the password in HTTP Digest authentication?
How else would the server know what to check your response against? If you don't want to give the server a password, try SRP.