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

[scriptkiddy]

That is an interesting limitation. I'm sure there is some way to get around it. However, I'm not a network security expert. I just thought using SSL certs for authentication was an interesting idea.

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