| Advice on how to handle application key [message #1800161] |
Thu, 20 December 2018 16:47  |
 Mark Hilbush
Messages: 4
Registered: November 2018 |
Junior Member |
|
|
I'm working on a binding for receiving personal weather station (PWS) data from ambientweather.net, an online service provided by Ambient Weather for hosting PWS data, as well as allowing access to that data through an API.
Use of the Ambient Weather API requires two keys. It requires:
- an Application key, provided to the developer of the application (i.e. me) by Ambient Weather, and
- an API key, provided to the end user by Ambient Weather.
I've looked around for other bindings that have a similar multiple-key model, but I've not found any.
I currently have the Application and API keys defined as configuration parameters on the bridge Thing. The Application key config parameter is defaulted to the key provided to me by Ambient Weather.
I'm interested in getting some advice on whether I should handle the Application key differently. Here are sone things I've considered:
- The Application and API keys are system-generated, relatively long, and not easily guessed.
- However, being open source, the Application key in the repo is visible to anyone.
- Other than the temporary inconvenience to users of my binding, there's no real downside to the Application key being disabled due to abuse.
- The likelihood of abuse is relatively low, given the Application key is not a high-value target. It's also not of any use without an API key.
I've considered a simple obfuscation of the key in the source code, populating the Application key config parameter only at binding initialization time. Obviously, this would not deter someone who's intent on getting the key (which is likely no one). Any protection of the key beyond a simple obfuscation seems like overkill to me.
Are there any other approaches I'm missing?
Am I overthinking this?
|
|
|
| Re: Advice on how to handle application key [message #1800170 is a reply to message #1800161] |
Thu, 20 December 2018 19:51  |
John Cocula
Messages: 21
Registered: June 2015 |
Junior Member |
|
|
Open source code should not contain obfuscation, or embedded secrets that are assigned to private entities (IMHO). This existed with the openHAB Twitter action and ended up being a problem that led to downtime outside the control of the user, when for various reasons the API key became invalid. You could argue that the key should never have been embedded in the code, even as a default fallback, since the validity of the key is outside the control of the end user.
I had an analogous issue with an Ecobee integration for the Vera smart home controller, where there was no strict open source license model, and the possibility existed to ship a built, encrypted component that contained my secret API key. Since this allowed much simpler deployment of the integration without risk of revealing the secret developer API key, I opted for that route with no issues. By contrast, there was no reasonable or practical approach for my Ecobee binding for openHAB, so the configuration required the user of the binding to become a "developer" for the purpose of obtaining his or her own private API key. In the end, it was just a few more steps and it never presented a problem that I was aware of.
If your API provider has a more burdensome process to become a "developer," explain to them that their assumption about your being able to obscure your own private API key is impractical in the open source model, and try to encourage them to allow any openHAB user to easily enough become a developer for the purpose of obtaining the necessary keys.
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.03029 seconds
] 
Search
Help
Register
Login
Home
