3 ms·
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
by scjody 13y ago
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 get the crypto right?
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.
- tptacek 13y agoWhat he's saying is, don't use HTTP basic auth, as in, get it, use HTTPS basic auth instead.
- jimktrains2 13y ago> using a modern scheme like bcrypt or PBKDF2 or scrypt
- sjtgraham 13y agoI did not suggest "rolling your own crypto". HMAC is detailed in an RFC (http://tools.ietf.org/html/rfc2104 http://tools.ietf.org/html/rfc2104), is widely used, e.g. Amazon AWS, and is part of OpenSSL. At no point do you have to "roll your own". If you don't implement this correctly the request will simply fail, the credentials won't be exposed at any point. Please spare me the FUD.
- mdellabitta 13y agoYou are suggesting 'roll your own auth,' though. Which is more difficult to get right than most people think.