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?
Related
I have two questions.
How to decide which one of the following is best for me to choose as my authentication method?
Sign Message with X509 Certificate
Require Mutual TLS
How to implement the two authentication methods?
I am using a Rails 4 app as my Connect API endpoint.
What's best for you will depend on your situation and priorities.
Sign Message with X509 Certificate
This can be used to verify or prove the source of the message. In this case DocuSign. This could be useful for auditing purposes.
Require Mutual TLS
With Mutual Auth TLS both the sender and the receiver verify each other using certificates. So the receiver knows the communication has been initiated by DocuSign, and the DocuSign service verifies that the certificate used by the receiver is as per configuration settings in the DocuSign console. The aim here is to prevent a Man-in-the-middle type attack where the communication could be intercepted and modified/recorded by an attacker.
This answer talks about the differences in more detail.
I think the key point is both approaches solve different problems, depending on your situation you may require one, both or neither.
Regarding implementation, TLS is typically done at a server level, so may require only configuration and no application code. XML signing on the other hand is typically done within the application itself.
This is a similar situation to the one raised in this question:
Javascript Calling a Rest API with App Name and App Password - How Can i Secure it
Here is the architecture overview:
The site is Html5/jquerymobile
It contacts what I call a "Wrapper" service.... This is a REST API I wrote in C#, to contact another 3rd party REST API. I do this because there are credentials in the Header and the API uses Basic Authentication. Credentials are therefore not publicized as they are only known server-side.
My "Wrapper" service does not currently implement any additional security. It is currently accessible from anywhere. The easiest and quickest way to lock it down is to restrict by IP, so no other IP anywhere except the server can actually contact my wrapper service.
The questions:
Is the locking by IP the only way to ensure that the API won't get hammered if it was otherwise accessible from anywhere?
If I convert this using Phonegap (which I have... and deployed successfully on Android), obviously the native app won't work if the web service is restricted.
Is there a way around this so I can allow traffic only from the mobile app, and not from any other source? I'm thinking along the lines of MD5 hash or something that could be sent to the wrapper API.. but unfortunately I'm thinking that info can easily be "sniffed".
Is my only viable option here to release the app as a web app, forcing browser use, thereby removing any concerns about allowing my web service to be hammered??
I believe the answer to this is a combination of a user token and encrypting the message through SSL.
The server can issue a valid user a token so we can identify him in future requests.
Encrypting it via SSL will ensure that this token cannot be sniffed.
https://security.stackexchange.com/questions/12531/ssl-with-get-and-post
I am developing a REST web service with Scala and LIFT and nave hardly any good idea on how to authenticate a client. I was thinking about a standard HTTP authentication, but found out it is very insecure as it passes passwords over a network in b64-encoded plain text. So how do I better do it?
If you want authentication to be secure against being observed in transit, your only realistic option is HTTPS. Technically, there are key-exchange protocols like Diffie-Hellman, but they aren't widely supported.
But the problem of observing packets in flight is almost a nonexistent one. In a shared LAN, it is possible, though not necessarily easy, to use a tap like FireSheep -- but it typically would be easier and more effective to walk over to the guy's computer and install a key-logger.
Basic authentication will pass password and user name in (nearly) clear text. If you use digest authentication instead it will still be prone to man-in-the-middle eavesdropping, but you should be safer from password theft and session takeover. This chapter in Exploring Lift have some information about digest authentication in lift: http://exploring.liftweb.net/master/index-9.html
I'm currently working on an application consisting both of a webapplication and client software. The client communicates via webservices, supporting both a SOAP and Protobuffer implementation.
The initial registration is done via the webapplication, which relies on username + password authentication later on.
After finishing the registration process, all features are also available via the client, which will only communicate via HTTPS. For authenticating webservice calls, I'm currently thinking about three possible approaches:
Including the username and password in every message. But is it really a good practice to include the credentials in every request, even though secured by HTTPS?
Providing the username and password in the first webservice request. The client then gets a token which is used for all future requests. (Note: It's not deemed acceptable to force the user to copy a server-generated token to the client application.) Only if the user revokes the token, he needs to send his username and password again for getting a new token. Such token based approaches seem to be quite common, for example Google, AWS and Rackspace are using them a lot. But does it really pay off in this scenario?
Hashing the password on the client sounds like a good solution. However I'd like to salt the encrypted passwords on the server-side. Adding requests only for fetching salts doesn't sound like an optimal solution or is it?
Are there any best practices or tips? I couldn't find too much information exactly for these requirements.
Currently I'd go with 2), but I'm not really convinced yet.
The project is based on Java, Apache CXF, Protobuffers and Shiro, but shouldn't have too much of an impact for the general question...
If you're only concerned by authentification and neither by confidentiality nor integrity, you can handle it by securing:
HTTP transport level, using HTTP BasicAuth (user+password on each message) + eventually HTTPS for confidentiality, however as you noticed (solution 1) it it is kind of old school and keeping user/password in local cache is not a big deal but cannot be advised.
Message level (the soap message) using Security Token for instance but I do not know Protobuffer
Application level (solution 2 and 3), that is the way Google, Amazon, Ebay and others are working. You will not ask the user to copy/paste his token, you will generate one from user/password
I would securing the application level using a token, since getting a salt from the server is almost like getting a token and does not add more security (a secured salt should be known from only you, and if channel is protected it mean getting the token from given password and username is secured as well).
A better but more complex solution would be usage of SSL certificates, available both in browser and client software.
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.