Why does your API still use HTTP Basic Auth? • Hacker News Board

Re: Why does your API still use HTTP Basic Auth?

#91

Post by tptacek » Thu, Apr 18, 2013, 3:51 PM UTC

poutine wrote: post #76

mechanical_fish wrote: post #64

Earlier quoted context omitted.

Nomenclature is important. As the joke says, naming things is one of the only two difficult problems in computing. [1] A good password is a long string of random characters, and an API key is a long string of random characters, but they are not the same because the semantics are different. Passwords are typically chosen by customers, changed (let's be honest) very rarely and on a haphazard schedule, often reused acro…

You also hash the two differently in your database. With passwords you want to bcrypt (or similar) them to protect against exposure of the DB and an attacker brute forcing the hashes. Since this is virtually impossible for long random strings you're able to just SHA2-256 the keys for DB storage. This becomes important because you're likely checking the key every API request and bcrypt would be a significant API rate…

Exactly what is the point of obfuscating single-purpose API keys at all?

Re: Why does your API still use HTTP Basic Auth?

#92

Post by gizzlon » Thu, Apr 18, 2013, 3:53 PM UTC

martin-adams wrote: post #55

If we're worried about a man-in-the-middle attack sniffing insecure credential on port 80. If the host closed port 80, couldn't the man in the middle just open it up again, you know, in the middle? Maybe one recommendation should be supported vendor supplied SDKs which don't touch HTTP, only HTTPS. Another option is to detect credentials being sent over HTTP and notifying the clients, maybe deactivating their key if…

Yeah, but then you have to do it in "real time".

The request won't go through and end up in a log somewhere if there's no MITM.

Re: Why does your API still use HTTP Basic Auth?

#93

Post by acqq » Thu, Apr 18, 2013, 3:59 PM UTC

poutine wrote: post #88

veesahni wrote: post #83

Earlier quoted context omitted.

Users should use "a long random key" But you should store "the key as SHA2-256 hash in your DB" why hash it?

Because if someone gets access to your database somehow you're not exposing all of the keys for all of your users. While you're likely in serious trouble if someone gets your DB this helps minimize damage. Besides to authenticate a request you dont need the plaintext of the key, a hash is fine.

Storing SHA in the database or anything not produced by PBKDF2, bcrypt or scrypt is wrong and doesn't help you much "minimizing damage." Advising SHA doesn't seem to come from a real professional.

Re: Why does your API still use HTTP Basic Auth?

#94

Post by corresation » Thu, Apr 18, 2013, 4:01 PM UTC

tptacek wrote: post #91

poutine wrote: post #76

Earlier quoted context omitted.

You also hash the two differently in your database. With passwords you want to bcrypt (or similar) them to protect against exposure of the DB and an attacker brute forcing the hashes. Since this is virtually impossible for long random strings you're able to just SHA2-256 the keys for DB storage. This becomes important because you're likely checking the key every API request and bcrypt would be a significant API rate…

Exactly what is the point of obfuscating single-purpose API keys at all?

Doesn't exactly the same concerns arise? A single purpose may be a major purpose, such as "transfer monies between accounts", and aren't exactly the same concerns relevant between passwords and keys?

If someone gets a list of unencrypted (or poorly encrypted) passwords, they have the rights of the user. If someone gets a list of unencrypted (or poorly encrypted) keys, they have the rights of the API caller. The concerns seem identical.

Re: Why does your API still use HTTP Basic Auth?

#95

Post by poutine » Thu, Apr 18, 2013, 4:02 PM UTC

tptacek wrote: post #91

poutine wrote: post #76

Earlier quoted context omitted.

You also hash the two differently in your database. With passwords you want to bcrypt (or similar) them to protect against exposure of the DB and an attacker brute forcing the hashes. Since this is virtually impossible for long random strings you're able to just SHA2-256 the keys for DB storage. This becomes important because you're likely checking the key every API request and bcrypt would be a significant API rate…

Exactly what is the point of obfuscating single-purpose API keys at all?

If you store keys plaintext in the DB then if someone gets your DB then they're able to perform API requests on behalf on any of your users.

Re: Why does your API still use HTTP Basic Auth?

#96

Post by corresation » Thu, Apr 18, 2013, 4:03 PM UTC

poutine wrote: post #82

Joeri wrote: post #77

Earlier quoted context omitted.

Arbitrary distinction. A password can be expired and forced to comply with complexity rules. A key is a server-side generated password, and therefore offers less ability for users to implement their own password policies. Good for users that don't care, bad for users that do care.

This is not arbitrary at all and has definition by industry standards. Passwords are used by people. Keys by machines. This requires different security policies. Passwords will have complexity rules and shorter expiration policies such as 90 days. Keys should have rollover policies around a year or so.

You say that it has definition by industry standards, but no such standards exist: There is no standard on the complexity or expiration policy of either passwords or keys. There is no standard on rollover policies.

Re: Why does your API still use HTTP Basic Auth?

#97

Post by poutine » Thu, Apr 18, 2013, 4:10 PM UTC

acqq wrote: post #93

poutine wrote: post #88

Earlier quoted context omitted.

Because if someone gets access to your database somehow you're not exposing all of the keys for all of your users. While you're likely in serious trouble if someone gets your DB this helps minimize damage. Besides to authenticate a request you dont need the plaintext of the key, a hash is fine.

Storing SHA in the database or anything not produced by PBKDF2, bcrypt or scrypt is wrong and doesn't help you much "minimizing damage." Advising SHA doesn't seem to come from a real professional.

I don't think you understand the distinction here, this is a random key, not a user generated password. The purpose of using something like bcrypt is to protect against brute forcing hashed passwords.

You cannot brute force search against a large random number that is hashed with unsalted SHA or the like. This would require you to guess the number, hash it and check to see if the hashes match. A large random number encoded as a 64 character string is simply too big to guess, even at millions of guesses per second.

Thus using bcrypt to protect your api keys does nothing but impose a serious bottleneck in how many api requests per second you may authenticate.

Re: Why does your API still use HTTP Basic Auth?

#98

Post by URSpider94 » Thu, Apr 18, 2013, 4:13 PM UTC

I agree that HTTP Basic over SSL is probably fine for requests from a server, in order to prevent sniffing of the connection.

However, I've recently been thinking about how to use a third-party API directly from client-side Javascript, or even from a resident application. If you're doing that, then you really need some way to use keys with validity that is limited by time or scope. In that case, HMAC offers some real advantages.

Re: Why does your API still use HTTP Basic Auth?

#99

Post by sgk284 » Thu, Apr 18, 2013, 4:16 PM UTC

acqq wrote: post #93

poutine wrote: post #88

Earlier quoted context omitted.

Because if someone gets access to your database somehow you're not exposing all of the keys for all of your users. While you're likely in serious trouble if someone gets your DB this helps minimize damage. Besides to authenticate a request you dont need the plaintext of the key, a hash is fine.

Storing SHA in the database or anything not produced by PBKDF2, bcrypt or scrypt is wrong and doesn't help you much "minimizing damage." Advising SHA doesn't seem to come from a real professional.

Storing the SHA-2 hash of a 256-bit random key obfuscates the API-key, so an attacker with access to the DB can't use it, but is fast to check so will remain performant.

It doesn't matter how many machines you have or how fast you can compute the SHA. An attacker will not find the API key (work out the math).

Re: Why does your API still use HTTP Basic Auth?

#100

Post by wisty » Thu, Apr 18, 2013, 4:24 PM UTC

acqq wrote: post #93

poutine wrote: post #88

Earlier quoted context omitted.

Because if someone gets access to your database somehow you're not exposing all of the keys for all of your users. While you're likely in serious trouble if someone gets your DB this helps minimize damage. Besides to authenticate a request you dont need the plaintext of the key, a hash is fine.

Storing SHA in the database or anything not produced by PBKDF2, bcrypt or scrypt is wrong and doesn't help you much "minimizing damage." Advising SHA doesn't seem to come from a real professional.

SHA is OK, if you have a long random key. I forget the numbers, but a decent random key (100 chars?) becomes impossible to crack before the heat death of the universe. The exponential growth of the password space eventually defeats the weakness of SHA.

The reason you need bcrypt is that user supplied passwords are crap, and can be cracked very quickly.