A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
I need to secure a web service. It's not SOAP, but it's a basic RPC situation.
Since it's meant to be consumed by a rich-client unattended, I thought of using a "Passive" security model:
When Client "signs-up" the server generates an encryption key and sends it to the client.
The client uses this secret key to encrypt all RPC requests. The request also includes a userID number.
The Server pulls the key identified by the UserID and decrypts the message. If the result is valid code, then execute. If not, error.
The biggest thing I can think of is protecting from a Man-In-The-Middle attack during the inital key exchange. Assuming this isn't a problem (i've got some ideas) what do you think about this security model?
The only fear I would have with what you are doing is that the client has to keep the key protected, which depending on the application could be a problem.
No matter what you do, if you do not have a user-entered key of some sort then you have (more) physical security risk. Not necessarily a lot, but some. Physical security in this case meaning that if someone wanted to break in, all they would need is access to the client software (with generated key) and time. Of course, that only applies to that one customer key, but once they know how...
In the end, it is a trade off. For your application, you need to weigh how important the data is to you client, and if they woud be willing to go through that extra step of entering a pass phrase or not.
I should note that passphrases are no panacea either, they could actually be easier than the other attack thanks to social engineering and other various tools in the hacker's toolbox.
Thursday, April 27, 2006
Why not use SSL/TLS? It provides for transport level security and that seems the only security you are looking for. You don't seem to need client authentication nor server authentication. Go to http://www.openssl.org/ for an open source implementation.
Thursday, April 27, 2006
For what definition of "secure" do you need to secure this service? Your scheme doesn't protect against someone reading all the traffic, much less the MITM you mention. Reading the initial exchange allows an attacker to impersonate a user. And how is encrypting the traffic supposed to secure the service?
Use SSL. Under no circumstances should you attempt to roll your own scheme. And what does the thread subject ""Passive" Authentication" refer to, exactly?
Security protocols and implementations of same are hard to get right, so if I was you I would think long and hard before rolling your own. Read Bruce Schneier: "Applied Cryptography" if you have not done so already. Then look into existing implementations: GSSAPI and SASL in general, HMAC, and TLS (was SSL). And finally study the archives of security related mailing lists (bugtraq) as not to introduce know vulnerabilities.
You're kind of a prick, aren't you? No offense, just an observation. Maybe you should try to understand what you're talking about before replying?
You suggest SSL without really know what you're talking about.
You said my "scheme" doesn't protect against someoen reading all the traffic. Well, you're right. They could read all the ENCRYPTED traffic they want. And good luck to them in decrypting it.
You said my "scheme" doesn't secure the service. Then you go on to suggest SSL, which will essentially work the same way as I've proposed, implying that SSL would offer security.
And you warn against "rolling my own" as if i'm going to try to Bitwise my way into a new algorithm.
Here's the idea:
- Server creates PGP key for the client. Server then encrypts that key using a password.
- The encrypted key is sent to the client.
- The password is given to the customer thru other medium, like telephone or snail mail or even email.
- Customer enters password into client App, which decrypts the key
- The key is stored in the client application. This key is used to encrypt all the RPC traffic between the client/server.
In summary, this provides "passive" authentication because only one client has this encryption key. When the server selects the key based on the userID, if it can decrypt the message, it must have come from that user.
It's no different then storing a password and then using SSL for encryption. The only difference is the absence of a traditional "authentication device" with a usernaame/password.
As for the key exchange itself, the password is used to prevent a MITM attack. As for using SSL to protect the key exchange, it seems obvious but it won't work here. The client or the server might not be online when the client attempts to process the "invitation."
Sorry if I'm not being clear. Maybe its my fault, i might not be explaining myself properly.
I asked for opinions because this is a vital and complicated component.
First, I'm not attempting to "roll my own" anything.
I don't know what you mean by "Your scheme doesn't protect against someone reading all the traffic, much less the MITM you mention."
The data is encrypted on the client side, and transmitted. Any traffic that's read will be encrypted.
The only part that's not protected in this way is the initial key exchange. I'm sure the exchange won't be a problem.
"And how is encrypting the traffic supposed to secure the service?
Uhh... isn't "encrypting the traffic" what SSL does as well?
Thanks for your reply!
The complication here comes from the fact that a "timeshift" will occur. When an "invitation" is sent from the server, it will not be processed by the client immediately. The client PC might not even be online. The encrypted "invitation" will be delivered via Email or Instant Messenger.
Then, when the customer turns his PC on, he will execute the "invitation" and will use the password to decrypt its payload.
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz