I am creating a web service for end users which will have a front-end in the form of an Adobe AIR desktop app but users will be able to access their data through the website too. User's data will be synchronized between the server and the local data store. The problem is that I cannot get an SSL certificate. Is there a way to make this more secure....
I think I can use something like two-legged oAuth or an Amazon S3 like authentication system?
What do you recommend in such a situation?
The first question is: why can you not get an SSL certificate? I can think of two reasons:
SSL certificates are too expensive
You don't want to have a certificate issued by a third party
If your problem is #1, StartSSL provides free certificates with a 1-year validity or charges $50 for unlimited certificates valid for 2 years (including wildcards). They are recognized by both Mozilla and the Microsoft trust store.
If the issue is #2, why not issue a self-signed certificate and hard-code it into your application? That does not compromise the security of the system at all (only your particular cert will be accepted by the app), but eliminates the need to "get" an SSL certificate from somewhere else.
If you really really can't use SSL, look at challenge-response systems such as Kerberos or anonymous key-material generators like Diffie-Hellman (with an asymmetric key for server identity validation). Many methods exist for secure two-party authentication over an insecure line. The key is that the ID verification step must be challenge-response instead of a "send me your secret" scheme.
Related
I have a client server based application where user is presented with login screen in the client. It then passes the credentials to the server which does the authentication. Client-server communication happens via a web service hosted on the server using https protocol (with TLS1.2 support). Client passes username and password to the web service. I am thinking of encrypting the password evethough I am using https based communication. My questions are:
Is it worthwhile to do a second level of encryption for password?
Is there any good practices to follow (like which algorithm to use etc)?
Its a MFC based application written in C++. Does windows provide any methods to do this?
I agree you should ask the first two question Information Security Stack Exchange.
Yes windows provides some methods to do encryption. There is a whole library called Microsoft CNG
Do not be tempted to use their obsolete "Cryptography API" - CAPI.
DO NOT be tempted to write crypto code yourself.
If you are using HTTPS/TLS1.2 and pin the certificate there is no reason to further encrypt the data.
https encrypt the entire transmission except for the URL address, thus the query string, etc is encrypted.
Encrypting the password just moves the problem to how will the encryption key be shared between the client and server?
I have an API endpoint which receives and sends sensitive data to a mobile SDK (that we created). The API lives in a Django Heroku app. I need to protect this information somehow, and I am a bit confused on where to start.
A friend of mine suggested provisioning HTTPS for my heroku app. After reading SSL Endpoints for Heroku, I couldn't be more confused. I read about buying a SSL certificate, yet their are so many different kinds, I don't know which one would fit my needs.
Mainly, my questions are:
What type of SSL certs do people get to protect APIs?
Would the mobile SDK require its own type of cert to interact safely with the web API?
Where can I buy/find a cert that fits my needs?
General question about HTTPS: Without HTTPS enabled, are logins able to be compromised on a heroku application with a custom domain?
Sorry if the questions are silly, I am new to SSL/HTTPS. Thanks!
The main thing that HTTPSprotects you from is man-in-the-middle attacks: that is, someone sitting between the client and the server who reads your web traffic, either copying important data or modifying what you send. In that sense, it gives some protection from compromised logins - in that no-one will be able to sniff your password from the data - but doesn't protect you from anything else, eg getting passwords from cracking, or social engineering (phishing) attacks, etc.
In terms of what to buy, the links on that documentation give you all you need to know, so it's hard to know what you mean by your first or third questions. For the second one, certificates are for the server, not the client, so unless you're serving your mobile API on a completely different domain from the rest, you don't need a separate one.
I've recently had to implement XML messaging with two large entities that required us to provide an SSL client certificate as well as sign the SOAP message body with a different signing certificate. Aside from redundancy, does the signing of the message body WITH A DIFFERENT CERTIFICATE provide any additional protection?
Edited to provide clarification of the question and point out the years-long misunderstanding between myself and EJP.
The value of signing the message in addition to using SSL with mutual auth (client cert) is that you get non-repudiation. However, you get that whether or not the client cert is used to sign the message or a different signing cert is used.
Signing the message provides legally enforceable non-repudiation over the transaction. You have proof that that client and only that client could have sent that message, and you can repeat the signature verification in court to demonstrate. SSL gives you the same thing technically at a lower level, but you don't have any way of getting the signature out, so you can't produce it in court: you are down to handwaving in evidence, as opposed to an actual digital signature, which is a legal signature and thus prima facie evidence.
I don't know that I'd term it "protection", but those are two different things. SSL certificates serve to verify your identity for encryption/transmission purposes.
SOAP signing allows the end user to verify that the XML has not been altered since the creator (you) signed it.
With transport-layer security, your security ends at the transport layer. By signing the SOAP message, you are providing end-to-end authentication for the application layer.
Without the SSL client certificate, anyone on the internet can talk to your back-end servers. That increases your attack surface.
Without application-layer security, imagine what could happen if an attacker gained control of an SSL load balancer / reverse proxy. (They could send any SOAP message they want to your back-end server with no authentication?!)
So it seems like they both do provide some value, yes.
The other question I would ask is, how are the keys (that is, SSL client certificate and SOAP signing certificate) secured? If it's trivial for an attacker to gain control of both keys, that would diminish the returns of this approach.
By using a different key to sign SOAP messages than to authenticate your connection, you also open up more flexibility around how you do your PKI. For example, your network administration team might want to issue one SSL client certificate per organization, but the application team might want one SOAP message signing certificate per entity in that organization.
I have been doing some research lately about best approaches to authenticating web services calls (REST SOAP or whatever). But none of the Approaches convinced me... But i still can't a make a choise...
Some talk about SSL and http basic authentication -login/password- which just seems weird for a machine (i mean having to assign a login/password to a machine, or is it not ?).
Some others say API keys (seems like these scheme is more used for tracking and not realy for securing).
Some say tokens (like session IDs) but shouldn't we stay stateless (especially if in REST style) ?
In my use case, when a remote app is calling one of our web services, i have to authenticate the calling application obviously, and the call must - if applicable - tell me which user it impersonates so i can deal with authorization later.
Any thoughts ?
So, you have User -> clientServer -> yourServer, yes?
You need to authenticate clientServer -> yourServer, to make sure not just anyone can talk to your server.
If this is an established trust relationship (i.e. you guys chat, sign documents, and do other things "out of band"), then you can simply use SSL certs, certs that you can sign.
Basically you set up your own Certificate Authority, create a root certificate, and then create a client certificate signed by that root certificate.
You then send that certificate to the clientServer, and don't let anyone connect to your service that doesn't have a certificate signed by your root certificate.
If the client ever ceases their relationship, you can revoke their cert and they can't talk to you any more.
As for identifying the User, that will need to be part of the API. The Client should authenticate them properly, and then forward any credentials to you that you require.
That can be a first class part of your web service (like a parameter), or if you use SOAP it can be passed along in a SAML attachment in the SOAP header, that you can then extract.
WS-Security has about 8000 ways of securing SOAP web services, as you may have discovered.
So, it kind of depends on what you want to do, and other requirements. But given what little you have, this should work peachy.
Don't know much about encryption...
Say I'm preparing a SAML request to submit to an identity provider. Why would I need to apply an x.509 certificate to this request? Is transmission over SSL alone not secure enough?
In the case of SAML, message-level security (i.e. the XML itself is signed and sometimes encrypted) because the communication involves parties that don't communicate directly. SSL/TLS is for transport-level security, only used between the two parties that are communicating directly and for the duration of this communication only.
Depending on which SAML binding you use, the dialog can look like this (e.g. along the lines of Shibboleth):
User's browser connects to Service Provider (SP)
SP gives the user a SAML request, not necessarily visible, but hidden within a form or equivalent.
User's browser (in a direct connection to the IdP) sends the SAML request to the IdP.
The user authenticates with it and gets a SAML response back.
The user's browser sends that SAML response to the SP.
In this scenario, there is no direct SSL/TLS connection between the SP and the IdP, although all 3 parties are involved. (Some variants of this involve a back-end communication between SP and IdP for attributes, but that's a different problem.)
An SSL/TLS connection wouldn't be sufficient for the IdP to know that the SAML request came from an SP for which it's allowed to authenticate and release attribute, since the connection to the IdP comes from the user's browser, not the SP itself. For this reason, the SP must sign the SAML request message before handing it to the user's browser.
An SSL/TLS connection wouldn't be sufficient for the SP to know the SAML response came from an IdP it trusts. Again, that's why the SAML response itself is also signed.
What applies to signing also applies to encryption, if the middle party, i.e. the user, isn't meant to see what's in the SAML message and/or if the connection between the user and the SP or IdP isn't over SSL/TLS (usually, it should be over HTTPS).
Yes - SSL is enough - but SSL is only point-to-point. You cannot secure your connection using SSL if there are a few intermediaries in the way between your source and your target machine.
In that case, e.g. when transmitting over the internet, you must safeguard the actual message, instead of the transport-level. That's why you need to encrypt the XML (or at least parts of it).
Marc
All that HTTPS will do is encrypt the communication between two points and prevent eavesdroppers -- it won't confirm who it was that sent the message. Neither will it assure secure communication if your message is then forwarded.
If you sign your request with the X.509 certificate you can be assured the decryptor has the shared secret contained in certificate. In other words, you can be assured the message can only be decrypted by the organisation you want it to be decrypted by.
In your case, the X.509 encryption requirement means that you should be assured that the identity provider is the only organisation that will receive your request.
A useful Wikipedia primer is here.
Most likely because they want to authenticate you (the client). HTTPS can be used for client authentication, but it rarely is in practice.
In practice, you could use HTTPS (SSL/TLS) to protect your SAML message. But you would want to use two-way SSL certificate verification/validation, meaning your client would need to verify the server's X.509 certificate and the server would need to be configured to perform client authentication, which would require it to check an X.509 certificate that the client presents. So, the client would need its own certificate anyway.
SSL/TLS is not really designed for this...it was/is designed to protect web traffic from being seen while in transport and for the client to be able to tell what server they are talking to and sending sensitive information to (it was really designed for e-commerce where the client (user buying something) knows who they are sending their credit card information to). In the case of SAML, the whole point is for the parties to know that the information they are exchanging has not been altered in transport and that each is talking to who they think they are. Using certificates to sign/encrypt that message itself accomplishes that.