I have N- Tier application Which consist of three parts:
1. Client (WPF)
2. WebService (Java web service) (Business logic)
3. Database (Oracle)
I store my password in md5 in oracle database but send password from from client to web service in not encrypted state just like a simple string. Which technic I have to use to secure password in network?
I would really recommend using SSL unless you want to go through caring about a lot of security concerns. Kerberos solve those pretty nicely as well but it is not that straightforward to use.
I've get some insights about secure authentication problems by reading Designing an Authentication System:
a Dialogue in Four Scenes (it is about designing Kerberos, but a lot applies to all authentication systems in general).
I think SSL is your friend as suggested by others. But whatever you do, I would not send the MD5 hash over the network. Part of the point of hashing (with MD5 or else) is to avoid storing a value that can be used 'as such' to authenticate a user. If any attacker gets access to the DB, he only sees the hashed password, but would still need to use the original password - which he can't decrypt from the hash - to access the web service. If your web service, instead of asking for the original pwd and hashing it itself before comparing it with the value stored in the DB, decides to let the client do the hashing, the aforementioned attacker needs only to send the compromised hash to be authenticated.
If you're worried about the requests being intercepted then you could use SSL to communicate between the client and the WS. Even if you encode the real password inside the client before sending it to the webservice, if the encoded form is somehow disclosed it could be used 'as is' to formulate a request to the webservice from any HTTP client. Alternatively you could encrypt the message content itself using an algorithm stored solely in the client so you can ensure that all WS requests come only from your client.
You could send password MD5 from client to web service. Even better, salted MD5 (and in DB you should keep also salted MD5). Then just compare what is received from client with what is in DB.
Related
We are currently developing a web application in .Net which will also have Android, iPhone and Windows Mobile 8 apps to occupancy it. All of these applications need to have a unified login system. Our site and web services will be using SSL but obviously we want to do all we can to make sure user passwords stay safe. As such we are looking for a common password hashing function that can be used throughout the platforms outlined above.
Currently the only common one we have found is SAH256 however I would like to use something a little stronger. C# has the Rfc2898DeriveBytes class which I would like to use (and can be used in the website and Win8 Mobile) but are there any implementations of this for Android/Java and iOS/Objective C? If this can’t be used what would be our next best option?
The password hashing function should be used on your back-end when storing the user's password and comparing during a login attempt.
Login scenerio:
User sends password over SSL via one of the versions of your app.
The back-end server hashes the password that was sent from the user, retreives the stored hash from the data store, compares the hash of the password sent with the stored hash.
Hashes match, user is allowed access, otherwise access is denied.
The SSL encryption prevents exposure of the password during transmission from the client, storing passwords as hashes prevents exposure of user passwords if your database is breached.
Using this scenerio, since the hashing is all done at the back-end server, only one implementation of the hash algorithm is required.
PBKDF2 is not something that fits well in your situation. It is mainly intended to prevent attacks when the attacker already has your data (ie. an encrypted file). It does this by eating up CPU to force a delay during brute-forcing. Because you're performing auth server-side, you can easily save some CPU and just wait a second or two to send an response to the client if they get the password wrong. Just use a salted hash (like HMAC), and you'll be fine.
If you're using SSL, then your passwords are secure. The only way you can do any better is to implement full public-key crypto, which can prevent MITM attacks. SSL even has this built in.
Sending password hashes over a network is not really more secure than sending passwords. Yes, the password text is hidden from attackers, but they've still got the hash and if they have that, they don't need the password. In the case of SSL, your plain text is also protected.
While I've never used it personally, bcrypt appears to have all the implementations you are looking for.
http://en.wikipedia.org/wiki/Bcrypt#See_also
Hope that helps.
I want to create new WCF service and client. The 2 parties will communicate using 2-way SSL.
I want to use the SSL only for the authentication phase. After this authentication, the encryption is not necessary. Can I configure my service (and client) to use SSL only for authentication and leave the connection unencrypted (performance issue)?
Why would you want to leave the connection unencrypted after authentication?
The username and password will be passed via the network one way or another so you should consider encrypting the connection all the time to avoid leaking that information.
Edit:
If you are using a certificate it has to be encrypted all the time, since I know you can't do authentication with a certificate and then get back to simple HTTP.
WCF need to authenticate the client for every request (if it wasn't like that client could get a certificate for a moment then delete it and use your WCF service like nothing happened because authentication will not be needed anymore which is abnormal in your situation).
If you want to perform authentication with a client certificate (what I presume you mean with "2-way" SSL), you could use a cipher suite with NULL encryption, e.g. TLS_RSA_WITH_NULL_SHA.
Otherwise, if your authentication scheme is part of the application layer on top of SSL/TLS, you should certainly consider using encryption.
Note that using TLS_RSA_WITH_NULL_SHA will still proceed with the RSA key exchange in the handshake (even if no shared encryption key is actually used in the end). The SSL/TLS handshake is the most computationally intensive part of using SSL/TLS. The actual encryption shouldn't impact the performance nearly as much, so you might as well leave it on.
I am working on the web service. A user is going to be able to create a user account using a form on different asp.net project. So when the user enters the password information I need to store that encrpted in a database. But now when the user sends the user credentials through for a web services then I need to the user to send that password encrpted for security purposes.
Now how can we both have the same ecrption procedure so that I will be able to validate the request.
What you want is to use HTTPS connection to transfer the password from the user to the server safely. Here is the explanation on how to set up the development environment with IIS for HTTPS - scottgu link.
HTTPS protocol will handle the encryption and decryption and you just deal with the plain-text password on the server-side.
After that, on the server side, you compute the hash of the password and compare it to the hash stored in the database. Standard ASP.NET SQL membership provider can be used for this.
There is a good explanation from Jeff Atwood on the problems behind storing and hashing passwords - coding horror link.
If the user's browser in any way knows how to encrypt your password then you kind of lose the point and a smart hacker could extract that encryption.
Using SSL to pass information directly to your application is essentially doing what you're asking and is the accepted secure way to receive the password. You will just have to check against your encrypted version in the database.
Your app receives the password raw (browser and server have taken care of encrypt/decrypt), then your app encrypts it and looks in the database for a match.
The other way this is done with web services is using a single login step that returns an expiring token which is used for further communication. OAuth is the most popular so do some googling on that.
You can encrypt the info you need using System.Security.Cryptography;
have a look at the below:
http://jakkaj.wordpress.com/2007/10/27/encrypting-and-securing-web-service-traffic-without-ssl/
Bear in mind that anything you do to provide "encryption" that isn't using SSL/TLS is likely to be vulnerable
I have made a WCF REST service which consumes data from an OLAP database and it is not Microsoft technology, ultimately, I would like to connect many other OLAP database to a single platform.
And after a lot of reading, the security for WCF REST is very discouraging, in summary, I have 2 choices, one is to use the Basic Authentication which expose username and password over the wire, or maybe a bit better, using Basic Authentication with SSL, now I need to get different certificates from the webserver. Or using Digest Authentication, which use an encrypted password and authenticate against the database, that's the best option, but in my case, it is not possible as I am not using Microsoft technology, the security is on different platform and I cannot encrypt my password using MD5 because the database cannot read the encrypted password.
That concludes me only be able to use Basic Authentication with SSL, but is this the correct way of doing? I see many products out there doing something similar to what I do, when they login, I do not see https, but only http, are they not secure and easy to hack?
I am not trying to make a bullet proof website, but a simple website, using Basic Authentication is too simple, or in fact it's almost like giving away the password, but using https, is that overkill?
So, after REST being that discouraging, let's not use REST, use the normal WCF, from what I have read, they shares the same problem.
Please give me some guidance. I think I have lost.
Many Thanks
PlayKid
Often, basic authentication is used for regular websites and yes, the username and password often go over the line readable if used with http. Https is already better, because the information is send encrypted over the line. But in practice, you only see this in place for commercial or banking applications. You cannot use MD5, which is a pitty, because that would be sort of middle-of-the-road approach.
So, depending on the application you will expose, use http for simplicity or https with a bit more complexity and safety.
By the way, big safety problems often have to do with SQL injection or a hacker being able to get some admin level privileges on your site. That way they get acess to a lot of info, while sniffing your line and getting a single user password combination is relatively harmless, if you take the needed precautions and counter measures.
Basically, Basic authentication with SSL is really very secure and shoul be used if its going to be exposed to outside world.
One easiest hack approach I have seen before and if you just want to authenticate (not authorize a endpoint) clients which are known set of clients use:
OperationContext.Current.ServiceSecurityContext.WindowsIdentity.Name
This will provide username accessing the service, Authenticate this usern with your DB or AD using LDAP if a valid user is accessing the service and with every request add a encrypted key that user needs to send as part of request. This way you know the username and encrypted key from the request.
You can also use this along with Basic authentication to be sure its not insecure.
I am developing web services using the servicestack.net library.
In my scenario, the web services will be called from a WPF application. I need the ability to authenticate that only an approved client app is calling my service.
Is this as simple as hardcoding a "username" and "password" in the client application? This certainly does not seem like the proper approach. Is there a better way?
EDIT
In addition, on the client end, Users themselves will be able to login with a username/password and initiate requests to the service(not sure if this effects anything, so I thought I would mention it),
For more background information about Authentication in ServiceStack see this question.
Normally you would authenticate users not clients which you seem to be doing in addition. But if you're trying to lock down services so their only accessible via a specific set of clients you should look into employing some PKI into your client and server.
Basically something along the lines of: the client sends an additional token at login with an encrypted version of the user:password together with a private key embedded in the app. The server has the client public key and so would do un extra validation step on Login to unencrypt the user:pass token and compare it with the validated user credentials.
If a PKI solution is too heavy, an alternate strategy without using encryption could be for clients to ship with a secret Guid which when they login which will send an MD5 hash version of the Guid and the current time, as well as the unhashed version of the time. If the time is within a specified threshold and the MD5 hash is valid then their using an authenticated client.