[LandR]

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.

[MaxBarraclough]

> 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.

[Fredej]

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]

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]

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.

[scriptkiddy]

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/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.

[newscracker]

This brings in the question of how long the client certificate would be valid for and how it would be renewed before expiry. If sending a tech costs a good sum of money, one may be tempted to use certificates that are valid for decades, which may or may not be a good idea depending on the client environment, advances in cracking some algorithms or proving collisions in hashing, and business related factors.

[scriptkiddy]

Cert renewal can be automated the same way letsencrypt does it for instance.

[icebraining]

Let's Encrypt validates during each renewal if the server still controls the DNS and/or HTTP endpoint. The point of the limited duration is to ensure that an attacker who got a copy of the certificate, but who doesn't control the DNS or HTTP endpoint, can't keep using it for long.

In this case, I don't see any automated check that can verify that the client trying to renew the cert is the original device, so there's no point in limiting the lifetime of the certificate, unless you send a person to do that verification manually.

[icebraining]

SSL client certs are useful, but they don't fix the problem feared by LandR: like a password, they too can be copied and used by someone who controls the machine.

[scriptkiddy]

Well, I mean that's true of almost every authentication method. If I have 2FA set up and someone knows my password and has access to my phone, of course they get into my account. I have a pentester friend who told me once: "Nothing is unbreakable or un-exploitable." I tend to believe that. Things like social engineering can always be applied to get the information you need to spoof credentials or gain access to critical systems. If someone is motivated and has enough resources, there's no amount of security methods that can stop them.

[brianshaler]

> 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.

[icebraining]

I'm not sure if that would be a good solution, or is it just as insecure as having password in the code.

It's just as insecure, as the software would need to store the decryption key itself in plain-text.

But why are you so concerned about keeping the password secret? As long as each device has a different password, you can identify abusive uses (too many requests, or from multiple sources, etc) and block that account.

What do you fear that the client could do with the device password?

[syrgian]

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

Which obviously can be cracked, but it takes a long time.

[perlgeek]

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.

[dmichulke]

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]

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.