Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why does your API still use HTTP Basic Auth?

swaggadocio.com

Post reply on HN
Print view View original

101–110 of 136 posts

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

#101

Post by poutine »

corresation wrote: post #96
poutine wrote: post #82

Earlier quoted context omitted.

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.

Incorrect. The PCI-DSS is an industry standard that everyone who touches credit cards must adhere to, which I suspect is a good portion of the audience here.

https://www.pcisecuritystandards.org/documents/pci_dss_v2.pd...

See section 8.5.9 for the password change policy. Section 3.6.4 for the key rollover policy (which references NIST 800-57 that basically says 1-3 years for most keys.

There's other standards (such as the 1-5 years for an SSL certificate from the issuer) and tons of best practices out there. In short you should be rolling over keys and expiring passwords on some sort of schedule. My point was that because humans use passwords they are conventionally seen as needing quicker expiration than keys.

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

#102

Post by krallin »

poutine wrote: post #97
acqq wrote: post #93

Earlier quoted context omitted.

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 e…

Exactly!

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

#103

Post by zobzu »

http basic auth is implemented in the server, not in the webapp, that's one fine reason. redirecting from http to https is ALWAYS an issue, http basic auth or not. now then again it'd be nice to have a "better auth" than basic auth that is still not part of the web app.. but yeah.

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

#104

Post by awj »

Closing port 80, great suggestion.

Until you can point me to an alternative authentication scheme that I can expect api consumers to generally have ready-made support for, it's pretty well the only good suggestion in this article.

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

#105

Post by mechanical_fish »

corresation wrote: post #94
tptacek wrote: post #91

Earlier quoted context omitted.

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 conce…

I will state the argument as I understand it:

The difference is that you can, and should, rotate your API keys automatically and fairly frequently (I will leave it to experts to tell us how frequently is prudent.)

Moreover, when you think your DB has been compromised you can flush all the API keys and reissue them. Depending on the application this may be more or less of a pain for the customers, but at least it is possible, because the keys are random and generated by you and not shared across services.

These facts mean that API keys, properly implemented, have a much smaller attack surface. You need not worry, for example, that a three-year-old backup file that someone harvested out of the trash at your ISP has valid API keys on it. The window for attack is, in fact, limited to "someone has stolen a very fresh copy of my live DB, but I have not yet realized it, and there is still something valuable left to compromise other than the data in my app's live DB." And this window often isn't very important. Often, closing it is akin to reinforcing the barn door after the horse has bolted and the barn has burned to the ground.

Passwords, on the other hand, get reused. You are using bcrypt to hash passwords not just to protect your app, but to protect your customer Gmail accounts that share the same password.

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

#106

Post by tptacek »

corresation wrote: post #94
tptacek wrote: post #91

Earlier quoted context omitted.

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 conce…

You do not need to obfuscate your API keys if you're generating them properly.

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

#107

Post by Rygu »

poutine wrote: post #81

As an API and security professional I've found to be secure and performant one should do the following with APIs: - Dont listen on HTTP, force HTTPS (Tune your ciphers! see https://www.ssllabs.com/ssltest/index.html ) - Ensure that any client libraries you supply for API interaction must verify the server certificate - Only use the users password to obtain a long random key from the server either through an admin web…

Can you explain why one shouldn't use HMAC signatures to sign requests?

How else can you guard against replay attacks, and authenticate the request? Only a key isn't enough, you need secrets as well. Right?

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

#108

Post by corresation »

poutine wrote: post #101
corresation wrote: post #96

Earlier quoted context omitted.

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.

Incorrect. The PCI-DSS is an industry standard that everyone who touches credit cards must adhere to, which I suspect is a good portion of the audience here. https://www.pcisecuritystandards.org/documents/pci_dss_v2.pd... See section 8.5.9 for the password change policy. Section 3.6.4 for the key rollover policy (which references NIST 800-57 that basically says 1-3 years for most keys. There's other standards (such a…

The PCI-DSS deals specifically with cryptographic keys used to protect CC details. It is in no way a standard for API keys. Even then it is enormously vague in its rules.

There are lots of organizations with notions about passwords and keys and ciphers, etc. However in the context of this discussion I don't believe there is anything that could be considered a standard.

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

#109

Post by poutine »

mechanical_fish wrote: post #105
corresation wrote: post #94

Earlier quoted context omitted.

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 conce…

I will state the argument as I understand it: The difference is that you can, and should, rotate your API keys automatically and fairly frequently (I will leave it to experts to tell us how frequently is prudent.) Moreover, when you think your DB has been compromised you can flush all the API keys and reissue them. Depending on the application this may be more or less of a pain for the customers, but at least it is p…

In common usage the user will take an server generated API key and embed it within their application that makes API requests. Take a very typical example of a merchant selling snowboards and using Stripe to process the payments as an example.

Since this API key is embedded within their app it'll require a programmer to change (and customers often may be non technical with sites built on contract). These are things you dont want to force customers to change with any frequency as it can cause pain and expense. You dont want to ever be forced to flush all your API keys, it could be a serious disaster.

Now there's protocols that rollover access keys hourly or the like such as OAuth a but that's a complex and often unnecessary use case that's beyond most API implementors. See how Google does OAuth 2.0 with their APIs for an example.

Since it's secure, simple and performant to hash API keys stored in your DB and just compared hashed values for authentication why would you ever not want to do it?

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

#110

Post by tptacek »

corresation wrote: post #108
poutine wrote: post #101

Earlier quoted context omitted.

Incorrect. The PCI-DSS is an industry standard that everyone who touches credit cards must adhere to, which I suspect is a good portion of the audience here. https://www.pcisecuritystandards.org/documents/pci_dss_v2.pd... See section 8.5.9 for the password change policy. Section 3.6.4 for the key rollover policy (which references NIST 800-57 that basically says 1-3 years for most keys. There's other standards (such a…

The PCI-DSS deals specifically with cryptographic keys used to protect CC details. It is in no way a standard for API keys. Even then it is enormously vague in its rules. There are lots of organizations with notions about passwords and keys and ciphers, etc. However in the context of this discussion I don't believe there is anything that could be considered a standard.

API keys should be cryptographically strong. If yours aren't, you're using API passwords, not keys. Stop doing that.
Post reply on HN