 |
lua-l archive |
|
|
||
|
PA wrote:
The current concoction involve 3 steps: (1) Upon connection, the server provide a random token to the client(2) The client sign the token with its private key and pass it back to the server (3) The server ask a directory service for the location of the client and ask that node to validate the token signature.And yes, each step can be compromised one way or another: the random token could not be that random. The signature could turn out to be quite predictable. The directory service could be compromised. The callback could be highjacked. Etc...I'm open to concrete and practical suggestions beside pointers to Mr Schneier's blog :)
Well, I don't want to stretch on the off-topic too long, but it seems to me that you need to have a think about just what it is you're trying to be secure against. Are you trying to identify or _authenticate_ client to server? If identify then just use UUIDs and be done with it. If authenticate then you'll need a lot more work. And as I said earlier, the problem with your solution is not necessarily in the cryptography; the protocol might have fundamental flaws in it. For instance, asking the client to validate its own signature.
Since you cited the WYTM post, you should answer it: what _is_ your threat model? You've given a solution but you've not specified what kind of attacks you're worried about. Your protocol as it stands might as well be clear-text identification, given how easily it could be hijacked at so many levels. The most salient flaw I see is signature checking. The client validates the signature, so it could sign the received token with gobbledegook and then, when challenged, simply say "yup, that's mine". What is the point of your validation step? I feel that you might be leaving out a lot; you say for instance that the server contacts a directory for the location of the client - which client? Where has the client given an identifier for itself?
Anyhow in order to judge your protocol, you need to specify what kind of attacks you're trying to protect against, if any, and what level of security failure is tolerable. You pointed out that security is always a compromise, but there's SSL's compromise and then there's this compromise. :-)
-- ~David-Haley http://david.the-haleys.org