"being able to encrypt a message is proof that they are who they say they are"
Not true. All that that proves is that whoever is on the other end knows the secret.
In that sense the title ("Security on an untrusted client") is misleading. The only way anyone's going to secure an untrusted client to a point where the system gains my trust is by using:
- A one-time password [1] to mitgate MITM, key loggers and screen grabbers.
- Identity federation (not OpenId or OAuth) that means I can use credentials other than the credentials I use from a trusted client.
- An application firewall [2] that redacts HTML on the fly so that the disclosure impact of a single GET request is reduced.
- Ideally (although this is taking things to a whole new level of paranoia) a data diode [3] that protects my server.
[Edit] The use case will obviously drive out the requirements, and the shopping list above is for a basic web application that only goes as far as form data. If you're looking to work with files you'd have to write up some code that ensures files don't contain nasties. While AV will go some way to doing that, the only way to really get around that is through conversion. I.e. .DOCX is converted to .PDF, .PNG to .JPG, and so forth. Yes, that limits the file types you can deal with, but if you're this far down your requirements aren't exactly main stream.
[3] Tenix is a high-end solution used by governments. The old Whale Commuications Intelligent Application Gateway used to be a cheap but very effective alternative (http://en.wikipedia.org/wiki/Unidirectional_network).
Correct. I was not careful enough with all the steps of my logic here.
Being able to encrypt the message proves that the party knows the secret, which if they are the only one who knows it, proves that they are who they say they are.
Indeed, the part about "which if they are the only one who knows it" is important. If you can't trust that, then security starts to break down.
You can sidestep it by instead trusting that they own a device that no one else has, like an one time password. Now, the statement gets a bit longer:
Being able to encrypt the message =>
the party knows the secret =>
(If you ask for multiple one, you can beter trust that)=>
they have the otp =>
they are the only one who has it =>
they are who they say they are.
You can never trust a client you don't have absolute control of. Unless you have such control, you can only assume the client is compromised.
I understand that your scenario calls for trust where none is warranted†. That's risk. And your mitigation is to be clear how you handle a compromise (likelyhood).
† As does probably 99.9% of sites on the Internet.
Comments
"being able to encrypt a message is proof that they are who they say they are"
Not true. All that that proves is that whoever is on the other end knows the secret.
In that sense the title ("Security on an untrusted client") is misleading. The only way anyone's going to secure an untrusted client to a point where the system gains my trust is by using:
- A one-time password [1] to mitgate MITM, key loggers and screen grabbers.
- Identity federation (not OpenId or OAuth) that means I can use credentials other than the credentials I use from a trusted client.
- An application firewall [2] that redacts HTML on the fly so that the disclosure impact of a single GET request is reduced.
- Ideally (although this is taking things to a whole new level of paranoia) a data diode [3] that protects my server.
[Edit] The use case will obviously drive out the requirements, and the shopping list above is for a basic web application that only goes as far as form data. If you're looking to work with files you'd have to write up some code that ensures files don't contain nasties. While AV will go some way to doing that, the only way to really get around that is through conversion. I.e. .DOCX is converted to .PDF, .PNG to .JPG, and so forth. Yes, that limits the file types you can deal with, but if you're this far down your requirements aren't exactly main stream.
[1] RSA SecureId (http://en.wikipedia.org/wiki/RSA_SecurID)or Chip & PIN challenge/response (https://en.wikipedia.org/wiki/Chip_Authentication_Program)
[2] Eg. F5 Big-Ip app security manager (http://www.f5.com/products/big-ip/big-ip-application-securit...) or Microsoft's Unified Access Gateway (http://www.microsoft.com/en-us/server-cloud/forefront/unifie...).
[3] Tenix is a high-end solution used by governments. The old Whale Commuications Intelligent Application Gateway used to be a cheap but very effective alternative (http://en.wikipedia.org/wiki/Unidirectional_network).
Correct. I was not careful enough with all the steps of my logic here.
Being able to encrypt the message proves that the party knows the secret, which if they are the only one who knows it, proves that they are who they say they are.
Indeed, the part about "which if they are the only one who knows it" is important. If you can't trust that, then security starts to break down.
You can sidestep it by instead trusting that they own a device that no one else has, like an one time password. Now, the statement gets a bit longer:
Being able to encrypt the message => the party knows the secret => (If you ask for multiple one, you can beter trust that)=> they have the otp => they are the only one who has it => they are who they say they are.
You can never trust a client you don't have absolute control of. Unless you have such control, you can only assume the client is compromised.
I understand that your scenario calls for trust where none is warranted†. That's risk. And your mitigation is to be clear how you handle a compromise (likelyhood).
† As does probably 99.9% of sites on the Internet.