Consider and client server scenario and you got two options:
You can include Server's Public Key
in Client and perform the exchange.
You can use Diffie Hellman
KeyExchange Algorithm to handshake
and then exchange the key.
Which one is more secure way?
also if public key will come from store say from Client CA store? would it be more secure instead of binding it in Client app?
The deployment will be done via an installer, verifying the version on each run.
With (only) DH key exchange, the client has no way to know that it is really the server he is talking to.
So the conversation would be secure from eavesdroppers, but someone could pretend to be the server and compromise the client.
Don't.
If you need to solve this kind of problem in production code, have an expert do it. There are so many subtle pitfalls in cryptography that chances are you will come a cropper.
An embedded key can be replaced. Generally speaking, if the client's machine is not secured by non-software means, you cannot prevent hacking of your client by a sufficiently motivated attacker. Even a TPM is no panacea. The question becomes one of trade-off: attackers' man-hours vs. utility (profit, fame &c) gained. The only really secure way to license a program which does computations is to perform all licensable computations on a server you physically control; https or SSL can be made sufficiently secure by choosing appropriate key lengths, hashing schemes, ciphers &c (a subject of which I know little).
The principle here is actually rather simple: you need to engineer a situation in which it will be in your clients' best interests to protect their passwords/license keys/data/whatever. E.g. if you have a computation server and charge your clients for server time, client keys are proxies to owners' bank accounts.
With the public key scenario the client must be generating the key, there is no way you can have any confidence this key is securely generated (someone could get access to the system and change the key generator to always use the same value, increment the previous value by one, whatever, said attacker can then eves drop on your communications for ever more). Public key crypto was not designed for this purpose.
Diffie-Hellman would be better but as Tobias said if you roll your own you'll probably leave an attack.
Well private key algorithms usually offers better performances (by an order of magnitude or more as far as I can remember) then their public key counterpart. In that sense Diffie-Hellman would be more efficient then say RSA for a client-server architecture.
If you have far far more clients then servers, you could implement a public-key algorithm to reduce the exchanges between them.
Still, like many people said, you should consider asking/hiring an expert on the matter as there is many different types of attacks (most of them targeting only the implementation and not the algorithm per se). If you still want to proceed, I can only wish you best of luck and point you to this resources you should very carefully read.
Diffie-Hellman Key agreement method
As Tobias mentioned above it is better if you don't roll your own protocol. I would suggest to use an implementation of TLS, or at least model your protocol on TLS. TLS provides options for both Diffie-Hellman and Certificate based key exchange.
Take a look at: http://en.wikipedia.org/wiki/Secure_Sockets_Layer
Related
I am new to WebServices and RESTful web services.
QUESTION: How can one quickly discover trust worthy web-service providers in absence of UDDI registry? I am asking from a network/systems/soa security-reliability perspective.
Aside from UDDI, there's a few other options for web service discovery. The "trustworthiness" of the search results depends on your definition of the word.
For proving that the search results weren't modified in transit and proof of origin, you can use digital signatures.
[WS-Discovery] http://specs.xmlsoap.org/ws/2005/04/discovery/ws-discovery.pdf is a UDP multicast based xml/soap solution that can probably be digitally signed.
[UPnP] is also udp multicast based xml/soap and may be signable
Multicast DNS
Roll your own solution
All of these assume you're on the same network, so there's a certain level of "trust" associated with that, assuming a certain level of network boundary security.
Other's have had luck using non http transports for all their transactions, such as OMG DDS, jGroups, or 0MQ. All of which support a certain degree of a peer authentication and/or encryption and are basically mutlicast based solutions (which usually don't go through firewalls). Hope this helps
I am building a client/server application in C++ and need each client to provide a password. Obviously I want this to be secure during transport so I have been looking into a way of encrypting the password; so that only the server application can decrypt it again.
The problem I am having is not necessarily getting the functions to work, but rather understanding what it is I need to do in order to relate that into code. I am trying to understand and have read MSDN (feels like it) but still I am only learning so really need some clear and accurate guidance on my implementation.
Does this sound right?
I aquire a context to the CSP on both server and client.
I generate a key on the server, or load one (whatever).
and then I
export a public key from the server and send it to the client, the client imports the key and then encrypts the password and returns it so that only the server can decrypt it again.
(Fails when I try).
OR, do I then
export a session key, or an exchange key pair ( single public) which is encrypted with the exchange key pair?
Oh I am so lost, I cannot even explain clearly.
Please help me to understand this...
It really depends on what sort of authentication solution you want to be based one. The options are varied.
You could, for example, rely on the underlying OS authentication. You wouldn't need to manage passwords at all. But this requires a somewhat tighter integration with the domain in which your application is running.
Another option is to use HTTPS and simple authentication. It basically uses SSL to encrypt communication and then sends a username/password pair. Pretty simple, and supported by all web servers. You could probably find C++ code quite easily that takes care of this for you (search StackOverflow for such a question) if you don't want to rely on an existing web server like IIS being installed.
If you do not need the encrypted Communication for other things like data transfer, you can use Challenge-Response for password verification. The Password does not need to be transferred over the network and there is no risk of a replay attack in wich a third party just resends some packets. On the downside, a man in the middle (MITM) attack is possible.
If you need protection from MITM or need an encrypted channel for other communication, you should use TLS with certificates or Public-Key-Encryption with two keypairs.
Do not do anything.
This is very important. Do not implement this yourself.
Repeat do not do anything you will get it wrong.
You should use what is already available. Simply open a connection to an SSL socket and the content of the stream will be automatically encrypted and de-crypted at the other end.
Your application should simply take a username/password tupple and validate if they are correct. Do not attempt to implement the cryptographic part.
I'm building a Login Service for an open source MMO game. I do not know much on the side of security/encryption and I am looking for a solution that will provide good protection against hackers and must not be too costly to generate.
Our old system used a very simple system of authentication by storing the password as SHA1 in the database. For our new service we want to authenticate this through an auth token that is generate when the user logs in for the first time and is valid throughout the session. Would a simple randomly generated string suffice for this or should I be looking at something more complicated to keep it secure?
Don't reinvent the wheel. The biggest problem with modern cryptography is when people want to roll their own, use SSL/TLS or HTTPS. This can be done safely without buying a certificate if you hard-code a self-singed certificate. Although each server should have its own certificate, or you run this risk Of MITM.
What you are looking for is a Session Handler, and ideally you would use the witty library. However this library may or may not be appropriate. In short a session handler uses a Cryptographic Nonce as a key, and this key is used to look up session state in a persistent data store. Each time a user authenticates he is given a new Cryptographic Nonce, and this value expires after a set amount of time of inactivity. For nonce generation I would use the openssl library, and 256 bytes in size should be plenty. A timeout depends on your application, but it should be no more than 1 day.
Rule 1: don't try to build your own single sign on.
Rule 2: If tempted, refer to Rule 1.
There are lots of freely available systems. Consider using OpenID. It's simple, pretty strong, and free.
PS. Have a look at the Wiki article.
Well there are so many vectors of attack in a system. These sorts of problems are quite complicated to solve properly. First step would definately be to make sure you're not re-inventing the wheel, it will save you time and probably prevent a host of mistakes.
I did build a system recently. In my case I didn't need secrecy I just needed authenticity. I built my system on top of openssl's crypto library. I used predominantly the DSA algorthim. Communication was autheticated with signatures attached to all comms. It's not particularly efficient to do it that way but for my purposes communication was irregular and as such it was fine. The relevant key was distributed with the software for generating DSA signed comms.
Inside of large companies, is it standard practice to use SSL (e.g. https) for running corporate apps over the LAN. I am thinking of ERP systems, SFA systems, HR systems, etc. But I am also thinking of SOA...web service providers and consumers.
In other words, is there any concern that something on the LAN could be sniffing plaintext info going around? If not SSL, how is this security threat dealt with?
What's your experience?
Inside of large companies, is it standard practice to use SSL (e.g. https) for running corporate apps over the LAN.
Generally SSL for LAN only internal applications is not common practice. Historically the LAN has been viewed as a "trusted" network, and so SSL for LAN apps hasn't been a priority.
Also, connection to internal application servers is usually via an authenticated proxy, which in itself mitigates some of the risk.
This is, slowly, changing however as organisations (generally) increasingly treat the LAN with less trust.
If not SSL, how is this security threat dealt with?
Most enterprises do monitor what is attached to their LAN and record events when new devices are added.
If the device doesn't correspond to something planned (i.e a new desktop or printer) - then it is investigated.
Unauthorised devices are seen as a much greater risk (than not using SSL) because they pose additional threats, like introducing a virus, an external network connection, or some other kind of attack vector.
It really depends on what you consider a "large company". The company I work at has over 50,000 employees; thus our corporate network is really not a great deal more trustable than the Internet.
We do use SSL on corporate Intranet web applications. We have our own internal CA certificate installed on all corporate PCs, so we can issue our own internal SSL certificates in-house.
Unfortunately, no it's not standard practice.
What's done and what should be done are not necessarily the same here...
Without a doubt any system with confidential information should be secured, especially on a LAN, as that's where most attacks originate - disgruntles employees etc etc.
unfortunately, it's often not the case.
Yep, pretty standard practice in a lot of places I've seen.
I think the reasons why should be obvious:
Extra security against common attacks
Pretty much no reason not to
Inside of large companies, is it standard practice to use SSL (e.g. https) for running corporate apps over the LAN. I am thinking of ERP systems, SFA systems, HR systems, etc. But I am also thinking of SOA...web service providers and consumers.
I would feel very uncomfortable if such apps weren't secured. In many place I've worked, they were. In some other, they weren't and I consider this as unprofessional.
In other words, is there any concern that something on the LAN could be sniffing plaintext info going around?
For me, the answer is obviously YES.
If not SSL, how is this security threat dealt with?
One Time Password (with RSA SecureID).
I wonder if one of the problems is that going to SSL always seems just a bit more complicated than it should be. If one could enable SSL with a single switch without having to worry about certificates perhaps at least the encryption part could become default.
Obviously you wouldn't get endpoint authentication without taking the extra step of setting up certificates, but then at least there would be truly no reason to go without encryption.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'm not a security expert by any means, but I favor creating REST-style web services.
In creating a new service which needs to have the data it transmits secure. We've entered a debate over which approach is more secure - REST with HTTPS or a SOAP WS with WS-Security.
I am under the impression we could use HTTPS for all the web service calls and this approach would be secure. The way I look at it is, "if HTTPS is good enough for bank and financial web sites, it's good enough for me". Again, I'm not expert in this space, but I'd think that these people have thought considerably hard about this problem and are comfortable with HTTPS.
A coworker disagrees and says SOAP and WS-Security is the only way to go.
The web seems all over the board on this.
Maybe the community here could weigh in on the pros and cons of each? Thanks!
HTTPS secures the transmission of the message over the network and provides some assurance to the client about the identity of the server. This is what's important to your bank or online stock broker. Their interest in authenticating the client is not in the identity of the computer, but in your identity. So card numbers, user names, passwords etc. are used to authenticate you. Some precautions are then usually taken to ensure that submissions haven't been tampered with, but on the whole whatever happens over in the session is regarded as having been initiated by you.
WS-Security offers confidentiality and integrity protection from the creation of the message to it's consumption. So instead of ensuring that the content of the communications can only be read by the right server it ensures that it can only be read by the right process on the server. Instead of assuming that all the communications in the securely initiated session are from the authenticated user each one has to be signed.
There's an amusing explanation involving naked motorcyclists here:
https://learn.microsoft.com/archive/blogs/vbertocci/end-to-end-security-or-why-you-shouldnt-drive-your-motorcycle-naked
So WS-Security offers more protection than HTTPS would, and SOAP offers a richer API than REST. My opinion is that unless you really need the additional features or protection you should skip the overhead of SOAP and WS-Security. I know it's a bit of a cop-out but the decisions about how much protection is actually justified (not just what would be cool to build) need to be made by those who know the problem intimately.
REST security is transport dependent while SOAP security is not.
REST inherits security measures from the underlying transport while SOAP defines its own via WS-Security.
When we talk about REST, over HTTP - all security measures applied HTTP are inherited and this is known as transport level security.
Transport level security, secures your message only while its on the wire - as soon as it leaves the wire, the message is no more secured.
But, with WS-Security, its message level security - even though the message leaves the transport channel it will be still protected. Also - with message level security you can partly encrypt the message [not the entire message, but only the parts you want] - but with transport level security you can't do it.
WS-Security has measures for authentication, integrity, confidentiality and non-repudiation while SSL doesn't support non repudiation [with 2-legged OAuth it does].
In performance-wise SSL is very much faster than WS-Security.
Thanks...
Technically, the way you have it worded, neither is correct, because the SOAP method's communication isn't secure, and the REST method didn't say anything about authenticating legitimate users.
HTTPS prevents attackers from eavesdropping on the communication between two systems. It also verifies that the host system (server) is actually the host system the user intends to access.
WS-Security prevents unauthorized applications (users) from accessing the system.
If a RESTful system has a way of authenticating users and a SOAP application with WS-Security is using HTTPS, then really both are secure. It's just a different way of presenting and accessing data.
See the wiki article:
In point-to-point situations confidentiality and data integrity can also be enforced on Web services through the use of Transport Layer Security (TLS), for example, by sending messages over https.
WS-Security however addresses the wider problem of maintaining integrity and confidentiality of messages until after a message was sent from the originating node, providing so called end to end security.
That is:
HTTPS is a transport layer (point-to-point) security mechanism
WS-Security is an application layer (end-to-end) security mechanism.
As you say, REST is good enough for banks so should be good enough for you.
There are two main aspects to security: 1) encryption and 2) identity.
Transmitting in SSL/HTTPS provides encryption over the wire. But you'll also need to make sure that both servers can confirm that they know who they are speaking to. This can be via SSL client certificates, shares secrets, etc.
I'm sure one could make the case that SOAP is "more secure" but probably not in any significant way. The nude motorcyclist analogy is cute but if accurate would imply that the whole internet is insecure.
I don't yet have the rep needed to add a comment or I would have just added this to Bell's answer. I think Bell did a very good job of summing up the top level pros and cons of the two approaches. Just a few other factors that you might want to consider:
1) Do the requests between your clients and your service need to go through intermediaries that require access to the payload? If so then WS-Security might be a better fit.
2) It is actually possible to use SSL to provide the server with assurance as to the clients identity using a feature called mutual authentication. However, this doesn't get much use outside of some very specialized scenarios due to the complexity of configuring it. So Bell is right that WS-Sec is a much better fit here.
3) SSL in general can be a bit of a bear to setup and maintain (even in the simpler configuration) due largely to certificate management issues. Having someone who knows how to do this for your platform will be a big plus.
4) If you might need to do some form of credential mapping or identity federation then WS-Sec might be worth the overhead. Not that you can't do this with REST, you just have less structure to help you.
5) Getting all the WS-Security goop into the right places on the client side of things can be more of a pain than you would think it should.
In the end though it really does depend on a lot of things we're not likely to know. For most situations I would say that either approach will be "secure enough" and so that shouldn't be the main deciding factor.
Brace yourself, here there's another coming :-)
Today I had to explain to my girlfriend the difference between the expressive power of WS-Security as opposed to HTTPS. She's a computer scientist, so even if she doesn't know all the XML mumbo jumbo she understands (maybe better than me) what encryption or signature means. However I wanted a strong image, which could make her really understand what things are useful for, rather than how they are implemented (that came a bit later, she didn't escape it :-)).
So it goes like this. Suppose you are naked, and you have to drive your motorcycle to a certain destination.
In the (A) case you go through a transparent tunnel: your only hope of not being arrested for obscene behaviour is that nobody is looking. That is not exactly the most secure strategy you can come out with... (notice the sweat drop from the guy forehead :-)). That is equivalent to a POST in clear, and when I say "equivalent" I mean it.
In the (B) case, you are in a better situation. The tunnel is opaque, so as long as you travel into it your public record is safe. However, this is still not the best situation. You still have to leave home and reach the tunnel entrance, and once outside the tunnel probably you'll have to get off and walk somewhere... and that goes for HTTPS. True, your message is safe while it crosses the biggest chasm: but once you delivered it on the other side you don't really know how many stages it will have to go through before reaching the real point where the data will be processed. And of course all those stages could use something different than HTTP: a classical MSMQ which buffers requests which can't be served right away, for example. What happens if somebody lurks your data while they are in that preprocessing limbo? Hm. (read this "hm" as the one uttered by Morpheus at the end of the sentence "do you think it's air you are breathing?").
The complete solution (c) in this metaphor is painfully trivial: get some darn clothes on yourself, and especially the helmet while on the motorcycle!!! So you can safely go around without having to rely on opaqueness of the environments. The metaphor is hopefully clear: the clothes come with you regardless of the mean or the surrounding infrastructure, as the messsage level security does. Furthermore, you can decide to cover one part but reveal another (and you can do that on personal basis: airport security can get your jacket and shoes off, while your doctor may have a higher access level), but remember that short sleeves shirts are bad practice even if you are proud of your biceps :-) (better a polo, or a t-shirt).
I'm happy to say that she got the point! I have to say that the clothes metaphor is very powerful: I was tempted to use it for introducing the concept of policy (disco clubs won't let you in sport shoes; you can't go to withdraw money in a bank in your underwear, while this is perfectly acceptable look while balancing yourself on a surf; and so on) but I thought that for one afternoon it was enough ;-)
Architecture - WS, Wild Ideas
Courtesy : http://blogs.msdn.com/b/vbertocci/archive/2005/04/25/end-to-end-security-or-why-you-shouldn-t-drive-your-motorcycle-naked.aspx
I work in this space every day so I want to summarize the good comments on this in an effort to close this out:
SSL (HTTP/s) is only one layer ensuring:
The server being connected to presents a certificate proving its
identity (though this can be spoofed through DNS poisoning).
The communications layer is encrypted (no eavesdropping).
WS-Security and related standards/implementations use PKI that:
Prove the identity of the client.
Prove the message was not modified
in-transit (MITM).
Allows the server to authenticate/authorize the
client.
The last point is important for service requests when the identity of the client (caller) is paramount to knowing IF they should be authorized to receive such data from the service.
Standard SSL is one-way (server) authentication and does nothing to identify the client.
The answer actually depends on your specific requirements.
For instance, do you need to protect your web messages or confidentiality is not required and all you need is to authenticate end parties and ensure message integrity? If this is the case - and it often is with web services - HTTPS is probably the wrong hammer.
However - from my experience - do not overlook the complexity of the system you're building. Not only HTTPS is easier to deploy correctly, but an application that relies on the transport layer security is easier to debug (over plain HTTP).
Good luck.
REST Over HTTPS Should be a secure method as long as API provider implements authorization a server end. In a case of web application as well what we do is accessing a web application via HTTPS and some authentication/authorization, traditionally web applications did not have security issues then Restful API would also counter security issues without problem !
If your RESTFul call sends XML Messages back and forth embedded in the Html Body of the HTTP request, you should be able to have all the benefits of WS-Security such as XML encryption, Cerificates, etc in your XML messages while using whatever security features are available from http such as SSL/TLS encryption.