41–50 of 136 posts
Earlier quoted context omitted.
Great TL;DR. Is that algorithmically generated or by a human?
It's crowd-sourced from actual people using a browser extension. http://tldr.io/what-is-tldr (see how I gave you a tl;dr of the link explaining how the tl;dr is generated?)
Earlier quoted context omitted.
The main problem isn't the response, the problem is that on the initial request, the insecure password will be sent in plaintext.
But that's not the problem of the API provider. If you explain that you only allow HTTPS and someone makes an HTTP on an unsecured connection, well...
Sounds insecure.
Why the hell would you over complicate your API with things like s3 auth or other bs like oauth? HTTP Basic Auth works pretty well with SSL and should be enough for most cases. Also, it's dead simple for the API to return a token that can be used after authentication in non-SSL endpoints of the API.
The title is a little misleading as the author is talking about HTTP vs HTTPS rather than the HTTP auth specification vs oauth (et al). Essentially his whole blog post could be reduced to this: servers shouldn't open port 80 on auth API sub-domains. While he does have a point, I do think part of the blame lies with the client side as well. If you're dumb enough to transmit user details over clear text protocols then…
That just don't make any sense to me and implicitly suggests using other authentication methods.
HTTP basic auth over SSL seems like the way to go - and you need to use SSL on your API anyway to prevent hijacking. The points about not allowing HTTP access to the API make sense, but avoiding basic auth entirely isn't a good security tradeoff.
This is an important issue, but as the article says, Auth Basic over SSL is perfectly secure (if you don't redirect 80 to 443 of course). And since it is so simple to set up and use, I can see why some providers would use it (I do for example). Summary of the article: http://tldr.io/tldrs/516fc7e340d4a84c4100020e/why-the-hell-d...
Great TL;DR. Is that algorithmically generated or by a human?
Earlier quoted context omitted.
It's crowd-sourced from actual people using a browser extension. http://tldr.io/what-is-tldr (see how I gave you a tl;dr of the link explaining how the tl;dr is generated?)
Is there a tl;dr page for that page? :)
But this page is a bit outdated, this is what we use now: http://tldr.io/tldrs/514d1c2ec02bf6ba46001aba/more-on-the-tl...
Really, don't use HMAC-of-the password authentication tokens at all, though. They're not nearly as secure as TLS.
Better still, don't use passwords in your API at all. Passwords are for humans. APIs use keys.
There's a very good reason for using HTTP basic auth: if you want to store password hashes on your server using a modern scheme like bcrypt or PBKDF2, you can't use digest authentication. The author suggests rolling your own authentication scheme based on HMAC-SHA, but then all the clients need to implement this scheme whereas HTTP basic auth is already part of most HTTP libraries. And do you really trust yourself to…
There's a very good reason for using HTTP basic auth: if you want to store password hashes on your server using a modern scheme like bcrypt or PBKDF2, you can't use digest authentication. The author suggests rolling your own authentication scheme based on HMAC-SHA, but then all the clients need to implement this scheme whereas HTTP basic auth is already part of most HTTP libraries. And do you really trust yourself to…
or scrypt
There's a very good reason for using HTTP basic auth: if you want to store password hashes on your server using a modern scheme like bcrypt or PBKDF2, you can't use digest authentication. The author suggests rolling your own authentication scheme based on HMAC-SHA, but then all the clients need to implement this scheme whereas HTTP basic auth is already part of most HTTP libraries. And do you really trust yourself to…