API key and API secret?

Why is there only an API key, and not an API Key and an API Secret?

I’ve given this some thought, and I couldn’t find the answer anywhere. I’d feel more secure as a user knowing that there’s at least a more than one factor.

What you are suggesting is still single factor authentication. Remember the three factors of authentication are: Something you know (usernames, passwords), Something you have (auth tokens, physical keys) and something you are (fingerprints, iris images). an API Key and API Secret are both things that you know so its only a single factor of authentication. We haven’t included any other factors in our API because it is intended to be a system-to-system automated API that can perform actions on your bulbs without user intervention. Requiring a second factor would require a human to intervene.

However, you rightly suggest that using an API Key and Secret is more secure. The reasons for this is that systems that use these usually make you calculate a HMAC signature for your message using these tokens. What makes this more secure is that none of the tokens are ever transmitted across the connection. Of course the cost of this is that your API becomes more complicated to use and rules out making requests with curl or tools like Tasker.

When talking about security things often come down to a tradeoff between security and complexity. In this case given that:

  • Our tokens are large enough not to be easily brute forcable
  • We use A Grade SSL security on our connections
  • We refuse requests to our HTTP endpoints
  • We want our API to be usable easily across as many platforms as possible
  • Our API is versioned and authentication options can be changed in the future

We have instead elected to use a single token that is transmitted to the remote host over a HTTP connection. We believe that this give the best balance of usability and security for our systems and our users.

Thank you for asking this question. I believe it is important that we constantly review our decisions in the security space, but more importantly that we are open and honest with our users and developers.

1 Like

Thanks for the reply and the thorough explanation. I understand the logic behind your decisions. Sorry for the mix up of definitions; I agree with your definition that an API Key and a Secret are both the same kind of factor, something you know.

Before diving into my own project that I’m developing for LIFX, I checked out some other stuff that’s our there and I came to the realization that one single token is all that’s required to control all of one users lights. The token might not be easy to guess, but it doesn’t feel secure enough, so I still call for two tokens (albeit they are the same factor).

How is two tokens going to help? What kind of attack will it prevent? How likely is that attack?

Unless you are talking about moving the authentication to HMAC signing, adding more tokens does not provide any perceivable security benefit over a single token. You could even represent two tokens in our current system by cutting the current token in half and pretending it was two tokens.

Two tokens together seems far less likely to be gussed than just one. If my lights can be controlled by the token “AD” and someone randomly sends a turn off all lights to token “AA”, “AB”, “AC”, …, and finally to “AD” my light would turn off right? This would be less likely if there were a combination of two tokens.

The tokens are 64 hex characters long. The chance of someone brute forcing them is extremely unlikely and we would almost certainly notice and block their IP address. On average they would need to send 2147483648 requests to break a single token. If they could make ten requests in a second it would take them 2485 days to crack a token. This would be extremely obvious on our system and they would likely be blocked.

If we used two tokens of 32 hex characters the chance of brute forcing them would be the same.

Okay, someone pointed out my maths is wrong, so I’m going to show the correct numbers, and show my working this time.

So we have a 32 byte token, which has 2^(32*8) or 115792089237316195423570985008687907853269984665640564039457584007913129639936 possible values. The average number you would have to try to crack for a brute force it is half of that so 2^(32*8)/2.

Then assume then that you can try 1,000,000 different tokens a second (Hint: You can’t, we would block you long before that). It’ll take 2^(32*8)/2/1000000 seconds to crack an average token.

That is about 1835871531540401373407708412745559168145452572704854199002054 millenniums, or as I like to call it … ‘never’. Why do I call that never? Because our sun will die in 2.8 billion years.

At 1.8E63 years, that’s not just past the lifetime of our sun, it’s also well beyond the projected lifetime of our Milkyway galaxy.

You haven’t reached theoretical heat death of the universe as a whole, but I guess you have to leave something for the next iteration of the API… :stuck_out_tongue_closed_eyes:


Hehe, okay, point taken! :slight_smile: