5 ms·

Anyone know amy good resources for the following scenario: WEB API that a device needs to authenticate to. Can't store password on device (it's a device we don

by LandR 9y ago

Anyone know amy good resources for the following scenario: WEB API that a device needs to authenticate to. Can't store password on device (it's a device we don't control). No user, so authentication has to be all autommated. i.e. we need to run software on a clients machine, and it has to authenticate to our web api to send us data. We obviously don't want to hard code the credentials in the software as that can be trivially extracted.

dmichulke 9y ago
1. As secret, use encrypted(some internal device id, pregenerated-key) 2. Generate pregenerated-key upon first login (maybe based on email or tel no?). Just like, e.g., Signal does it 3. On your servers, check if pregenerated-key and/or email is used more than once at the same time, if so invalidate it and direct user to 2.
- LandR 9y ago
  We already do number 3 :) We monitor for the same login being used twice at the same time and disconnect both and delete the account.
perlgeek 9y ago
Ideally you use some kind of time-limited API tokens, and find a way to automatically distributed new API tokens, before the old ones expire. That way, the breach of a single device doesn't immediately give the attacker unlimited access to the API. You should also monitor for unusual activity, and blacklist API keys and devices with such activity.
Fredej 9y ago
Could it be a possibility to generate a keypair on the machine and then attempt to register itself to your webserver supplying client-name, IP and public-key. Then you would be able to see and OK any attempts to connect. Once you've OK'ed it, it would be able to authenticate and communicate normally as an authenticated device.
icebraining 9y ago
Can't store password on device (it's a device we don't control) Can you expand on this? Because storing a device-specific password (or api key, which is essentially the same) would be my first suggestion. If it's because you can't configure the device, then my suggestion would be to create a process that embeds the device key into the software before deploying to each particular device.
- LandR 9y ago
  We need to run software on clients machines, we need this software to be running as service (no UI). This service needs to communicate back to use securely via our Web API. We could have a password entered by our systems guys who deploy to a new machine for the first time, the service encrypts and stores that on disc, then each time it wants to talk to us it can decrypt its password. I'm not sure if that would be a good solution, or is it just as insecure as having password in the code.
  - syrgian 9y ago
    That sounds a lot like hardware-id based DRM, doesn't it? Kind of like the (in)famous Denuvo https://en.wikipedia.org/wiki/Denuvo https://en.wikipedia.org/wiki/Denuvo Which obviously can be cracked, but it takes a long time.
  - brianshaler 9y ago
    > password entered encrypts and stores that on disc, then each time it wants to talk to us it can decrypt its password. Is there a reason you don't want to use tokens? Upon authenticating once (admin, manually), the web service would generate a token, which it would store and potentially have to revoke. With something like OAuth, the token could be more temporary and automatically replaced during each use, to avoid having one secret (whether it be a password or token) that could be leaked and used by multiple clients.
  - scriptkiddy 9y ago
    I Found a somewhat interesting solution for this issue. I assume you know what an ssh public/private key is, correct? Well, apparently, there is a way to apply this concept of ssh public key authentication to the HTTP protocol. This technique is referred to as "Mutual Authentication": http://www.cafesoft.com/products/cams/ps/docs32/admin/SSLTLSPrimer.html http://www.cafesoft.com/products/cams/ps/docs32/admin/SSLTLS... Basically, it's 2-way SSL. You use signed SSL certs to authenticate the server to the client and the client to the server. You could use your own cert signing server or employ a third party cert signing service. Using this method, your techs would need to set up the SSL cert for the client machine when installing the software, or, the SSL setup procedure could be part of the software installation procedure. Interesting idea that may solve your problem. Hope this helps.
MaxBarraclough 9y ago
> Can't store password on device (it's a device we don't control). No user, so authentication has to be all autommated. Am I missing something, or have you painted a contradiction? * You want the device to hold some secret * You want the device to be able to prove that it holds the secret * You don't trust the device to hold a secret If I'm understanding this correctly, then you've left the realm of cryptography and entered the realm of obfuscation. Edit This isn't necessarily a losing battle, but it changes the way we need to think about the problem. Games consoles and DRM'ed video media (Blu-Ray and HDCP) do something similar in not trusting the end-user: they want to hold the key to the kingdom whilst ensuring the user never sees it. They've done this with varying levels of success.

by LandR 9y ago

dmichulke 9y ago

1. As secret, use encrypted(some internal device id, pregenerated-key) 2. Generate pregenerated-key upon first login (maybe based on email or tel no?). Just like, e.g., Signal does it 3. On your servers, check if pregenerated-key and/or email is used more than once at the same time, if so invalidate it and direct user to 2.

LandR 9y ago
We already do number 3 :) We monitor for the same login being used twice at the same time and disconnect both and delete the account.

perlgeek 9y ago

Ideally you use some kind of time-limited API tokens, and find a way to automatically distributed new API tokens, before the old ones expire. That way, the breach of a single device doesn't immediately give the attacker unlimited access to the API. You should also monitor for unusual activity, and blacklist API keys and devices with such activity.

Fredej 9y ago

Could it be a possibility to generate a keypair on the machine and then attempt to register itself to your webserver supplying client-name, IP and public-key. Then you would be able to see and OK any attempts to connect. Once you've OK'ed it, it would be able to authenticate and communicate normally as an authenticated device.

icebraining 9y ago

Can't store password on device (it's a device we don't control) Can you expand on this? Because storing a device-specific password (or api key, which is essentially the same) would be my first suggestion. If it's because you can't configure the device, then my suggestion would be to create a process that embeds the device key into the software before deploying to each particular device.

LandR 9y ago
We need to run software on clients machines, we need this software to be running as service (no UI). This service needs to communicate back to use securely via our Web API. We could have a password entered by our systems guys who deploy to a new machine for the first time, the service encrypts and stores that on disc, then each time it wants to talk to us it can decrypt its password. I'm not sure if that would be a good solution, or is it just as insecure as having password in the code.
- syrgian 9y ago
  That sounds a lot like hardware-id based DRM, doesn't it? Kind of like the (in)famous Denuvo https://en.wikipedia.org/wiki/Denuvo https://en.wikipedia.org/wiki/Denuvo Which obviously can be cracked, but it takes a long time.
- brianshaler 9y ago
  > password entered encrypts and stores that on disc, then each time it wants to talk to us it can decrypt its password. Is there a reason you don't want to use tokens? Upon authenticating once (admin, manually), the web service would generate a token, which it would store and potentially have to revoke. With something like OAuth, the token could be more temporary and automatically replaced during each use, to avoid having one secret (whether it be a password or token) that could be leaked and used by multiple clients.
- scriptkiddy 9y ago
  I Found a somewhat interesting solution for this issue. I assume you know what an ssh public/private key is, correct? Well, apparently, there is a way to apply this concept of ssh public key authentication to the HTTP protocol. This technique is referred to as "Mutual Authentication": http://www.cafesoft.com/products/cams/ps/docs32/admin/SSLTLSPrimer.html http://www.cafesoft.com/products/cams/ps/docs32/admin/SSLTLS... Basically, it's 2-way SSL. You use signed SSL certs to authenticate the server to the client and the client to the server. You could use your own cert signing server or employ a third party cert signing service. Using this method, your techs would need to set up the SSL cert for the client machine when installing the software, or, the SSL setup procedure could be part of the software installation procedure. Interesting idea that may solve your problem. Hope this helps.

MaxBarraclough 9y ago

> Can't store password on device (it's a device we don't control). No user, so authentication has to be all autommated. Am I missing something, or have you painted a contradiction? * You want the device to hold some secret * You want the device to be able to prove that it holds the secret * You don't trust the device to hold a secret If I'm understanding this correctly, then you've left the realm of cryptography and entered the realm of obfuscation. Edit This isn't necessarily a losing battle, but it changes the way we need to think about the problem. Games consoles and DRM'ed video media (Blu-Ray and HDCP) do something similar in not trusting the end-user: they want to hold the key to the kingdom whilst ensuring the user never sees it. They've done this with varying levels of success.