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
Related
I started learning c# two days ago so I don't have much experience with the .net framework. I want to create an application where the user can input a username/password combination and the login information will be sent to the server for verification. I thought of doing it in the following way by using a PHP script but its not really efficient/secure since everyone will have access to the script.
1) client->Get username/password from user and send the username to the server
2) server->Find out if the user is in the database and send a random number back
3) client->Create an MD5 hash out of the number then create an MD5 out of the passwordMD5+numberMD5\ and send it back to the server with the number
4) server->Create and MD5 hash from the numberHash+passwordHash and compare it the hash received by the client
The other problem with the authentication above is that I want to periodically check if the user is authorized to access the application after it has sign in and I don't want to keep asking for numbers from the website every time the user wants to access something in the application. I did some research and found out about JWT authentication, but the issue I'm having now is implementing JWT authentication in an efficient way. If the user signs into the application it will send the username/password to the server but it doesn't seem safe to send plain passwords the the server. I also want the tokens to have a time limit after it is created. I was thinking about creating a new database for expired tokens and another one for valid tokens and check those database every time the user tries to access information from the site. I was about implementing some kind of API with asp.net core but I found out the host I'm currently using does not support .net. Now I'm thinking about using a server(maybe azure but I'm not familiar with it) just for generating the keys and when the client tries to contact my website I check if the key exist in the invalid key database and block the connection otherwise if its not in the valid key database insert it.
My questions:
1) I there a better way of achieving this other than the way above.
2) If not then what would be the best way of checking the keys to give client access the website database.
Have you possibly looked into using Auth0 for protecting your server and your WPF application? Check out https://auth0.com/docs/quickstart/native/wpf-winforms for more information as you can probably implement this using the free tier they offer.
I'm working on a couple of projects that need to store user credentials for third-party applications, such as Paypal, Facebook developer creds etc. I've read a few books about different kinds of coding, including ASP.NET, WPF, jQuery, and all have nice examples on how to access the preceding services with own secrets, and also all of them use the exact phrase "in a real project you would store these in an encrypted file". None, however, give an example how to do so.
I have little (read: none) experience in encryption, but based on my understanding, I would need to encrypt a username and a password using some sort of key (salt?) and save them in a file. I would also want to be able to use these credentials on my apps so I would need to store the key (salt?) in my code.
Now my question is: How is it safer to store the decryption key, which is still plain text, in the program code, than the actual credentials?
Wouldn't the malicious user be able to decrypt my password-file as soon as he gets the key?
--EDIT--
I really mean my own credentials I need to store to log in to third party applications, not credentials of my users. For example I need to identify my self and/or my app to Google, so that users can log in to my app using their own Google account.
--EDIT 2--
To clarify, this is what I'm talking about. This screenshot is from asp.net PayPal tutorial:
Any quick pointers on good practises here?
You misunderstood the part about storing encrypted password* + salt: this is done when your system needs to validate someone else's credentials. In this situation storing password hash and the salt is more secure than storing the credentials, encrypted or not, because an attacker would have no way of getting the password back, even if he manages to get his hands on both the hash and the salt.
Storing decryption key in plain text is never a good option, because an attacker would get your users' passwords as soon as he gets access to the key.
There is no good solution to persisting your own credentials, encrypted or not. Your component that talks to 3-rd party services should use developer APIs from these providers. For example, PayPal provides two sets of APIs which you can use to access your account without having to store your password.
If you need to store a small amount of secret information in an encrypted form, use registry APIs to store the data in a key known to your application, and accessible from the user running your server-side component. This secret would be safe, as long as hackers do not hack the password for the account under which your service is running.
* Technically, password is not encrypted, it's hashed, i.e. there is no reliable way to turn the result of conversion back to the original value.
Your suspicions are correct. If the user has access to the key they can just go and decrypt the username and passwords themselves.
The two options you have are
Make it difficult enough to get the password that the reword of getting the password is not worth the effort to find it. This approach is done via things like Code Obfuscateors, I would not recommend this to someone starting out. Its not easy to get it right and it only takes one person who things it is "worth the effort" for it to break.
Don't give the user the information ever. Instead of storing the usernames and passwords in the program have your program call out to a server you own, then that server is what makes the request using the credentials. This approach is the more reliable one and is "unbreakable" (as long as your server is secure) but costs more because you now need to keep a server up and running that can handle the load of your entire userbase.
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.
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.