We Keep Coding

WPF-Client for WebAPI - how to handle password for authentication

I'm developing a Client/Server-Application with ASP.Net WebAPI and WPF.
Right now I'm thinking of authenticating the client with basic authentication over https. You can suggest better solutions but windows authentication and server side sessions won't work for me.
For basic authentication I need the password on the client in plain text (base64) to send it over the wire on every request, right?
But i don't want the user to reenter the password on every request, so I have a Login-Window on the application start.
The WPF PasswordBox uses SecureString and is not bound to the viewmodel. But at least right before the request I have to get the password as normal string to encode it to base64.
So sooner or later the password is in RAM in plain text no matter what I do.
What are the best practices to hold the password for later requests?
cache the PasswordBox
cache the SecureString
cache a plain text string because it will be in RAM either way
cache the base64 encoded string because at least it is obscure ;)
...?
So how do I handle this in a reasonably secure way?
Other applications by big players (MS, Google, Apple, ...) don't request my password for every call, so there has to be a way.

You should read into authentication tokens, this is a commonly used method and the asp.net-web-api framework provides a lot of functionality provided by OWin.
Basically the flow is as follows:
Authenticate at your web-api.
Return a token
Use this token in the header of every following web-api/http request
The benefits:
Doesn't store the username and password in memory (well, just for a single call)
Token can be invalidated at server side
Functionality out of the box with web-api2
You can read about it here:
http://bitoftech.net/2014/06/01/token-based-authentication-asp-net-web-api-2-owin-asp-net-identity/
As for your WPF client:
You can create a .net client for your http/web-api requests by using the:
HttpClient https://msdn.microsoft.com/en-us/library/system.net.http.httpclient%28v=vs.118%29.aspx
Some psuedo code will look like this:
public async Task<IEnumerable<DataContainer>> GetDataForTarget(string id)
{
var requestMessage = new HttpRequestMessage(HttpMethod.Post, new Uri(new Uri(Host),
string.Format("api/Data?id={0}", id)));
var response = await Client.SendAsync(requestMessage);
//etc...
}
Note:
For the token based security to work you'll need https, otherwise the token can be intercepted. Everybody who knows the token can make calls to the web-api on behalf of the corresponding user. So, basically the problem shifts from securing the password to securing the token. The benefit of a token is that it should have a much shorter lifetime than a password, thats why it's more secure. Nevertheless it's arguable to store the token in a SecureString.
Meanwhile at the server side
It's is good practice (or even unethical if you don't) to, provided that users can pick their own passwords, you use a one-way encryption mechanism at your server to store the passwords.
This can be accomplished by using a (encryption-strong) random salt and a asymmetric-hash encryption using that salt.
To verify the user, just encrypt the incoming password with the stored salt and check if it gives you the stored hash value. In this case no actual passwords will be stored at your server and there is no way to retrieve the users password (.... well ehh excluded some technical details).

how to encrypt password at client side when implemented MD5halsh salted algorithm on server side

I have implemented an md5 hash salted algorithm.
Using this algorithm I have saved the hashed password and salt value to the database.
then on login page retrieved the salt value of login user, get the byte of password add the salt value and computed hash and matched the result with the saved password and it is working perfectly but I am still able to see my password value in clear text at client side.
How can I encrypt the password value at client side along with md5 hash salted algorithm?

You do it right way. You won't be able hash password on client-side without knowing salt (and passing salts to client is not a good idea). If you want that data sent by client was secure, use ssl.
Note: If you use ssl client will still be able to see my password value in clear text because data will be encrypted only before sending.

You can use data protection API (DPAPI) to store password on the client side securely. Use SafeString class, to store password in memory and, as #PLB already mentioned, use encrypted connection.

If you are worry for password which you are typing in text box.
Then change TextMode of textbox as Password
Like this
<asp:TextBox ID="txtPassword" runat="server" TextMode="Password"></asp:TextBox>

There are many different ways to solve this, the easiest I can come up with right now is to use some kind of challenge; the server sends a value the client has to use as a salt. The server ensures that the value is unique, hasn't expired, and only used once (this makes sure a replay attack isn't possible.)
This makes sure that a plain text password isn't sent, only a hashed one. The server can trust (trust as much as when doing plain text auth anyway) the client to not simply resend some old hash since the clear text password is needed to compute the hash with the "one-time-salt".
Another, more sophisticated (and secure) way is to generate a RSA-keypair from the password where the server has the public key, and the client the private. The client also has a copy of the servers public key. The user enters the password, and only the correct password will get the correct rsa-key.
The user then encrypts the requests with the server's public key, and then signs the requests with the user's private key. Only the server can then decrypt the requests, and the server can verify that the sender really is the right user by verifying the sign with the user's public key. And the opposite for the response. To add some security you should add some unique "salt" as I wrote earlier to ensure replay attacks are impossible.

Authenticaion, hash, salt, https process?

Hi I think I may have done this the wrong way round can anyone help explain how you hash/salt a password. Do you do it from the client or the webservice?
I have a datacontract which has a password datamember, in my service I do this to create a hash/salt of the password before it is saved:
So here is the process in which I was thinking.
Rest Service has https for secure connection
User creates account (along with password)
//to stop packet sniffing when user creates account https is used during POST so no one can see the password?
web service then creates a hash of the password to store it
//so if anyone did get access to the service/database they couldnt make much use of the data in terms of breaching accounts
Then some means to authenticate that user there after
Is this correct?

Sounds like you're on the right track. Hashing along with the salt value should never occur on client side, as attackers will have access to that code. And https would indeed secure the connection, disallowing others from reading the data.
During authentication you do the same thing: take the password the user entered via https, hash/salt that value, then compare the result hash with the value in the database. And of course if you ever return a Student object to the client, it should contain neither of the values.
It may be wise not to reuse the Password property of Student since now you can't tell whether it contains the plain password or the hashed value.

ASP.Net - How to Encrypt password before login while using Login Control

I'm using the ASP.Net Login control to login a web application. When the user submits the form, I want to call a function to encrypt the password before ASP.Net sends the information for authentication.
I tried to add a Customer Validator on the password field and if the password is not empty, the Password.Text will be replaced with the encrypted value. However, it seems ASP.Net still sent the original password for authentication.
I also tried adding a onClick event on the login button to encrypt the password but ASP.Net still sent the original password for authentication.
Is there a way to do this? Thank you!
UPDATE:
I'm sorry for not making this clear. What I need is to encrypt the password at Server Side.
I'm not using ASP.Net Membership to encrypt or hash the password while registering a user. The passwordFormat property has been set to "Clear".
What I am doing is:
While a new user registers, I use a customized function to encrypt the password and save it to database.
When a user tries to login, I want to use the same function to encrypt the password entered by the user and let ASP.Net to authenticate the user.
The problem I'm having is I can't find a way to call the encrypt function before ASP.Net initiate the authentication process.
Hope this makes sense. Thank you.
Allen

You were definitely on the right track with adding the OnClick event. If you are trying to do the encryption client-side then you will need to use the OnClientClick event instead (OnClick happens server-side and OnClientClick happens client-side). I initially assumed you were using it to call a client-side javascript function that does the encryption?
[EDIT]
However, if you are doing the encryption server-side, and using a Login control, then you might want to use the OnAuthenticate event:
<asp:Login id="Login1" runat="server" OnAuthenticate="OnAuthenticate">
</asp:Login>
Then do your encryption here:
private void OnAuthenticate(object sender, AuthenticateEventArgs e) {
bool authenticated = false;
String encryptedPassword = Encrypt(Login1.Password);
authenticated = YourAuthenticationMethod(Login1.UserName, encryptedPassword );
e.Authenticated = authenticated;
}
private bool YourAuthenticationMethod(String username, String encryptedPassword) {
//test the encrypted password against that retrieved from your database using the username
}

Why are you trying to encrypt the password client side before sending it to the server? That's really no more secure than sending the server your plain password. The code you write to encrypt this password is viewable by anyone.
On the server you should use something like this:
public static string createPasswordHash(string pwd)
{
return FormsAuthentication.HashPasswordForStoringInConfigFile(pwd, "md5");
}

Sorry if I misunderstood something about the ASP.NET technology, but it should provide server side application. Therefore, You should not be able to use any "c# code" to encrypt transferring password. If You cannot use secured HTTP (if You could, You wouldn't need to encrypt the password, because all communication would be encrypted), JavaScript is "only way". However, if Your project contains client-side application (the one that is really installed (or run) on client's computer), You can use full c# potential of course.
There is a discussion why would You need it at all. As I see no better explanation, I will try to provide my own: The encryption of password transferred via Internet is essential if you expect that someone will listen to the communication in between client's computer and the server. As I understand it, if user clicks on the log-in button at your site, the page he sees the form on is actually downloaded in his computer and the click only causes a transfer of data from client to server. The data is not encrypted at all and any evil Eve can listen to the transfer obtaining client's plain text password.
But You should be aware that even if You send encrypted password, the encryption covers only plain text password problem. If Your server-side application expects password encrypted with a static algorithm and my only goal (as evil Eve) is to successfully log into the system, I don't actually need to know the password itself, its encrypted form will be good enough. It is quite complex problem and it depends on how much security Your connection really needs - if the costs (or Your effort) are relevant to the risk. If You are really serious with as best as possible security, You should go through some security standards.
The point about seeing Your algorithm written in JavaScript is irrelevant as far as it is well implemented (RSA is both open and easily accessible algorithm, though safe enough).

C# Public Key verify Perl Private key and use as AES key ? Possible and/or viable?

i was thinking if it is possible and/or viable for obfuscation and security to do as the follow:
Client start session with Server (which means a valid login and password was sent and accepted)
Server encrypt a random password with it is Private Key that will then be used into a data encryption using Rijndael's method and send both back to the client (The password which is the encrypted random password and the Rijndael's encrypt data which is what we want for the client to work)
Client will receive both, verify the password to see wether it was encrypt with our pair of keys or not if so it will be used to decrypt the data.
From what i see, Rijndael has some restrictions as of the password size, so would this be even possible (considering the output of the encrypted random password) ??
Is there antoher approuch that would be close to what i was thinking or trying to describe here ?
Is this even worthed ?
The reason i wanted something like this is mostly to make it harder for anyone trying to reproduce what our server communicates with the client, aside from that we use Smart Assembly. I would like you guys to focus on the questions above and forget about packing my code etc. Think of this as a client / server communication security messure if possible.
Best regards.

I can address the first part. If the server encrypts a key with their private key, ANYONE with their public key will be able to decrypt it. This leaves a gaping hole open for a man-in-the-middle attack. In other words, if I intercept the same token you do, I now know the same key that you know. This means that I can see all the traffic that is going back and forth.
The crux of security has always been this initial key-exchange problem. You may want to employ an industry-standard approach, like Diffie-Hellman for the actual key exchange. Hope that helps