deal with basic auth security issue about security-00002 HOT 13 CLOSED

What's the security issue? API keys are not unique?

from security-00002.

The issue is that the API key is both an identifier and a password, therefore with luck and brute-force you can find a valid API key and take control of the account of someone else. Right now it's not a big problem, but the probability of finding a good key increases with the number of users.

from security-00002.

How does gratipay/gratipay.com#3022 change this? So now you need a user id and an API key. We'd still be susceptible to brute force, no? We're always susceptible to brute-force. The questions therefore is how much entropy we have.

from security-00002.

3022 turns the user id into a secret. Are we confident that we don't leak user ids anywhere? Do we want the burden of not leaking user ids in the future?

from security-00002.

API key is a UUID4. 128 bits of entropy (am I saying that right?).

http://en.wikipedia.org/wiki/Universally_unique_identifier

from security-00002.

122 bits:

http://en.wikipedia.org/wiki/Universally_unique_identifier#Random_UUID_probability_of_duplicates

from security-00002.

Brute-force is indeed always possible, security is all about probability. By requiring the user ID, an attacker can only brute-force one account at a time, instead of being able to attack all accounts at the same time. That means the probability of success becomes lower and constant (it won't grow with the number of users).

User IDs aren't secret. The reason I'm using the ID here instead of the username is because Gratipay usernames can contain characters that aren't allowed in HTTP Basic auth.

from security-00002.

What is our entropy source when using uuid.uuid4()? Is it sufficiently random?

from security-00002.

I'm not worried about uuid.uuid4(), it's a standard function that probably relies on the OS for its randomness.

from security-00002.

That means the probability of success becomes lower and constant (it won't grow with the number of users).

Okay, fair enough.

The reason I'm using the ID here instead of the username is because Gratipay usernames can contain characters that aren't allowed in HTTP Basic auth.

What, specifically? Do we know whether anyone is actually using these characters? Can we tighten up our username requirements?

from security-00002.

@Changaco I think the probability of an attack based on this vulnerability is low enough that we can broach this conversation with the rest of the team in gratipay/gratipay.com#3022. You okay with that?

from security-00002.

The main one is :, which is used as the separator in basic auth. I don't see any reason to change what characters we allow in usernames, the user ID is better anyway since it can't be changed.

from security-00002.

Looks like Github uses API 40 char API tokens - https://developer.github.com/v3/oauth/#response - e72e16c7e42f292c6912e7710c838347ae178b4a which is 160 bits.

I don't think there is a need to complicate the API with usernames. Just increasing key length and providing throttling mechanisms should be sufficient.

from security-00002.