Develop Reference

Is keeping encrypted password in memory for later use safe?

I am receiving username and password with which I am creating a connection to the web service and then consuming various functions using that service.
However I was thinking to storing username as plaintext and encrypted password for later auto-diagnosing purpose in which I may call a method in catch() which will re-initialize connection by using same username and decrypted password.
I dont have much experience in encryption and decryption but I may use methods as suggested here making them private.
Also, of course, I will blank out temporary variables where I stored password and even the TextBox text.
But I want to know if keeping encrypted password in memory is safe?

You should really hash the password, not encrypt it. That is, you (and by extension, attackers) should not be able to "decrypt" the password they give you if it is hashed.
Storing a hashed password in memory is reasonable. It will have to be in memory at some point anyway.

Just to make sure I understand your question correctly:
You are writing a client software
The user enters the password
You store the password in a variable for a short time to authenticate to a web service
You want to know whether you can store the password in memory (i.e. in a variable) for longer periods of time in order to authenticate to the web service again later
If these assumptions are correct: Don't worry too much about it, just keep it in a variable and that's it - preferably in a SecureString as suggested by Hans Passant. SecureString will do the work for you:
the value of a SecureString object is automatically encrypted, can be modified until your application marks it as read-only, and can be deleted from computer memory by either your application or the .NET Framework garbage collector.
Hashing makes sense on the server side where the password (or the hash) is stored on disk/in a database. On the client side, you cannot hash the password since you need it to authenticate to the web service.
If you wanted to store the password permanently (i.e. write it to a file), then you would need to worry about encryption/hashing.

Best Practice for Storing and Updating External API Passwords

I have a ASP.Net C# application that needs to connect to an external API using WebServices every 5 minutes.
The requirements of the External Webservice are as follows:
Username and Password are required
I must transmit the username and password with each webservice request
Passwords expire every 90 days and must be changed prior to the expiration date
Passwords cannot be changed manually (by human), my application must connect to a separate Password Change Webservice to change the password.
My application must generate each new password based on a set of rules.
Passwords can never be reused.
SSL, Certificates and Firewall IP restrictions are required
I have built all of the previous, but I currently have one issue. What is the best practice for storing the current and historical passwords?
Obviously storing the plaintext password is a bad solution. I need to be able to have my webservice read the password and transmit it with each request. I also need to be able to access all of the historical passwords to make sure that my newly generated password is not a duplicate.
Ideally, I would like to store each (encrypted) password in my database and decrypt it whenever I need to call the webservice. Is there a best practice I should be following? Should I encrypt each password using Microsoft.Practices.EnterpriseLibrary.Security.Cryptography.Cryptographer.EncryptSymmetric(..)?
Note: Unfortunately, I have no access to change the way the external API functions. I must follow the rules provided.

With regard to the password history I would go down one of two routes:
As per your current plan, store passwords in file/db/config - suggest you use a hashing algorithm (as opposed to encryption) to compare the new password with stored password hashes for "equality".
Don't bother storing password history at all - let the first attempt to the password change web service just fail if it chooses too, then resend with an alternative password. This way, you are not duplicating the business rules of the password change web service (for example, lets say they change it to allow you to re-use a password after 6 months time).
With regard to storing the current password: assuming you must send the password as plaintext, then yes, you should store it in encrypted form. There are many articles out there on how to do this. Or you could even encrypt a specific section of your config file such as seen here.

The easiest way... use the ProtectedData class:
http://msdn.microsoft.com/en-us/library/system.security.cryptography.protecteddata.aspx
byte[] bytes = System.Text.Encoding.UTF8.GetBytes(password);
byte[] cypher = ProtectedData.Protect(data, null, DataProtectionScope.CurrentUser);
//... reverse
byte[] bytes = ProtectedData.Unprotect(cypher, null, DataProtectionScope.CurrentUser);
string password = System.Text.Encoding.UTF8.GetString(bytes);

The ASP.NET IIS Registration Tool (Aspnet_regiis.exe) can encrypt and decrypt sections of web.config. There is no special code required in an application, as ASP.NET 2.0 will magically decrypt sections at runtime.
http://msdn2.microsoft.com/en-us/library/zhhddkxy.aspx

SQL query to create a encrypted password

I am trying to create a secure password login screen in c#.Right now i have just created the login screen and I am able to read the username and password from the database.But which i have designed does not have an encrypted password. Can any one help me out how to write a query to generate encrypted password and store the encrypted password value in a separate field.Thanks in advance.

Consider hashing the password that you currently store. SQL can hash a password as follows:
DECLARE #HashThisPassword nvarchar(4000);
SELECT #HashThisPassword = CONVERT(nvarchar(4000),'dslfdkjLK85kldhnv$n000#knf');
SELECT HashBytes('SHA1', #HashThisPassword);
... But SQL shouldn't even need to do this. You should hash the password as soon as your C# application receives it, and then only ever pass the hashed password into SQL to be saved. When checking if the user has provided the correct password for login, compare the hashes.

Your best bet is one way encryption.
What happens in this scenario is the user selects/is given a password. When that password is stored in the database it passes thorugh this one way encryption before it is stored. (You'll be doing this in your c# code)
Then when the user logs in, the entered password passes through this same one way encryption before it is compared with the password in the database.
This ensures that if a hacker gets into the database, it will be difficult to learn the password because they would have to determine the encryption type, and then devise a way to un-encrypt it which to my understanding is difficult at best, impossible at worst.
Here is a link to some code that may help. One Way Encryption
You don't want to do the encryption in sql itself, because if a hacker DOES access your database, they will be able to simply look at the procedure/function that you are using to do the encryption and they will have a much easier time.
And you don't want to store the password in the database unencrypted as well...
Your best bet is to write some code to read the password, encrypt it, and update the record, then all you have to do is continue to use the same encryption type and salt.
The c# cryptography library is very easy to use.

How to Manage Key in a Symmetric Algorithm

I am doing an AES encryption in my C# code, using a key which is generated using PasswordDerivedKey function by passing a password and a salt of 12 byte. I have implemented the logic in my application code and the "password" is the username of the logged in user and the salt is a static byte aray.
What is the best way of storing the password and the salt, as someone can easliy determine the salt (by reflecting my code) and the username of a person.
What are the alternatives I can adopt to store the password and the salt in a secure way. I dont think storing them in my application code is the best way of doing it.
Edit: By password, i meant the passkey used in the PBKDF function (to derive an encryption key) and its not the password provided by the user. I am using Windows Authentication

Why would you need to store password if it is merely an encrypted version of the windows username?
Anytime you need to encrypt/decrypt you know name of user thus can generate key dynamically.
Salt should never be considered a secure asset. No need to hide it. You should always assume attacker knows the salt. Salt is simply a mechanism to defeat rainbow tables and other fast lookups.
Is there something I am not seeing?
On Edit
The issue is misstated in the question. The issue isn't what/how should be stored. That answer is simple. Never store any of the cryptographic data (except salt).
The current implementation creates an encryption key from the username of logged in user. The problem is that is insecure as determining username is rather easy. To get around this one would need to either:
a) accept the implementation is insecure to someone willing to decompile app.
b) ... not a good idea ... hash can change based on groups/roles
c) use a unique secret password for each user.
c is the only secure implementation however it requires prompting the user for a passphrase when encrypting or decrypting.

Against whom must be the data be secure? If the currently logged in user is allowed access to the data, but other Windows Authentication users are not allowed access, what you really want is for the data to be encrypted for the particular logged in user. If you have access rights to configure the PC, you might be able to create an Encrypted folder with permissions only for the desired user. This is not 100% secure (you can still intercept the data at various places if you have root access), but your only other reasonable alternative is to add another password.
Alternately, you can simply accept that the protection is weak and provide minimal obfuscation. It depends on the value of the data and the capabilities of your possible attackers. If your attackers have sufficient privileges to Reflect over your assembly on the actual machine, then it's highly likely that they're also Administrator, which means you're pretty much screwed no matter what you do. There are tools that can connect to a running process and monitor its memory, which means they could simply wait until you've decrypted the data and read it from memory.

Best way to keep the salt is to generate it on runtime and keep it per session along with other user stuff such as username and password:
use signs in and provide username/password
hash with stored salt and check against password hash
create new salt and store it along with the hash
Symmetric encryption (or even asymmetric) is not at all recommended for passwords. You not to hash it which is just one-way.

I added this as an second answer because it is a different solution. I just thought of it tonight because I am working with this class (trying to reverse engineer kindle encryption).
You may want to look into the Protected Data Class
http://msdn.microsoft.com/en-us/library/2c64xe0y(v=VS.90).aspx
This is a class that allows you to store data in the windows cryptographic store.
By using the Protect and Unprotect function you can pass data into and pull data from the cryptographic store.
If you didn't want to force the user to create (and remember) an encryption key you could.
1) Check to see if current user has encryption key in the store.
1a) If not then create a random encryption key
2) Use key to encrypt file and store
3) To decrypt retrieve key from store.
4) Another user may be able to access the file but will be unable to get a copy of the key from the store.
A couple caveats. Only the windows user who stored the key can retreive the key. However this can be bypassed depending on environment. If the user has no windows password (or weak windows password) anyone w/ access to machine can run as the user and windows will gladly hand over the key. In a domain environment anyone (admin) who can impersonate the user and modify password can access they key. If user's windows profile is trashed so is the only copy of your encryption key.

C# and SQL Server: Passwords. Where to do what?

Ok, I have an application written in C#. We have data in an SQL Server. Among that data we have user accounts, which will give access to the application.
I've read around, and I know that you should salt and hash and possibly hash a bunch of times, etc. But, where do I do what? What do I send to and from the SQL Server? Exactly what do I store in the database? Do I hash it in SQL? (possibly a hash function there, like in mysql?) Do I hash and do the fancy stuff in my code? Do I send the hash to the server and compare, or do I get the hash from the server and compare in my application? What about the salt? Where do I make it? Where do I store it? How do I get it?
In other words, could someone give me a nice and clear walkthrough of a login scenario (and possibly a user add/reset password scenario). What goes where, what should be used where, etc.
Hope someone can clear these things up for me =)

For C# + SQL Server, you can just use the MembershipProvider model, which will take care of all this for you.
And IMO, the most important part of getting all this stuff right is not doing it yourself. Rather, rely on the mechanism provided by your platform. It's just so easy to get it wrong in a subtle way that appears to work. Then you deploy, and you don't even know anything is wrong until after you are hacked.

I agree with Joel Coehoorn completely, the best choice is to trust someone else's tried and true implementation. If, however, you're determined to roll your own security implementation, then my advice is the following:
Store the hash and salt in the database.
Generate the hash and the salt in your own code. That way you're not tying yourself to a specific database.
Never send the password over the wire as plaintext. I would recommend fetching the hash and the salt from the database and comparing it to the ones you calculated from the username and password supplied by the party that wishes to be authenticated.

If you are using ASP.NET, using the built in membership stuff is a cakewalk to implement I would recommend going that way.
However, as a general question, I would implement the hashing in your local code, then only send the hash values out to the database. For salts there is a number of ways to do it, you can create a random salt, or you can salt the value using the records id, or something else. Again, I would do it in the C# code. There is a helpful method in the framework for doing it.

I did this myself a number of years ago before the Membership Provider model was available.
We used the functions built-into ASP.NET to handle the hashing of the password; it's the static method HashPasswordForStoringInConfigFile in the FormsAuthentication namespace. You give it a password and an encryption choice and it returns the hashed password.
Our flow was:
- Get the hashed password from the database for hte entered user name.
- Hash the entered password.
- Do they match? If so, continue, else logon failed.
When changing the password, we sent the hash to the database for storing; we did not send the unencrypted password.
And, I believe, it is what the MembershipProvider is doing under the covers today.
To reiterate too, the most important piece when doing forms authentication regardless of how you are doing it, is to work over a secure (HTTPS) connection.