Best practices for storing password?

[david.1982]

Hi Everyone,

Fairly new C# coder here. I'm currently writing a small application that will be deployed on several computers, each of which will need to connect to a remote SQL server. I'm wondering what the best way to store a username and password for this would be?

Each deployment will have a different username/pass (each performs a different function), but obviously I can't just 1-way encrypt and store the pass, since I need to use it each time to connect to the server.

Any help would be appreciated :)

[ddanbe]

You could type in a key and xor it with a username password.
You could look at this snippet for encryption http://www.daniweb.com/code/snippet1009.html

[Ramy Mahrous]

hmmm, default scenario is to encrypt username and password in .config file, and just decrypt them while application is running. you'll just decrypt 1 time.

[LizR]

The usual answer is you *dont* be able to decrypt them, you have a one way encryption and the only way to match them is you redo the encryption algorithum, and if it matches, then it must have.

[Rashakil Fol]

1. The typical practice is to store the password in plaintext. And this is okay, frequently.

1a. Store the password in plaintext on a usb drive.

2. A better practice is to store the password encrypted and have the encryption key hardcoded into the application -- this is not cryptographically secure by any means, but it would stop unknowledgeable disgruntled employees, which are the primary threat. It's better than 1a because somebody who copies your hard drive needs a short amount of time to get the true password, which might give you a chance to react.

2a. Store the encrypted password on a usb drive.
2b. Store the encrypted password on a network drive.

With 2a and 2b, somebody who gets access to backup tapes will not be able to see your password. 2a has the advantage of not relying on the accessibility of some thing on the network.

3. An even better practice is to store the encryption key locally and store the encrypted password on a network drive that lives far away. Use the password to login and clear it from memory. That way, somebody who steals or sniffs backup tapes for one of the drives doesn't have the means to acquire the password.

4. Alternately, you could have a human type in the password whenever the program starts, or a password from which an encryption key used in #2 or #3 is used.

5. Whatever you do, don't rely on shitty Daniweb code snippets for your encryption algorithm, and don't use anything named "xor" for encryption, unless you're xoring against a one-time pad (which would suffice for paragraphs 2 and 3). But don't do that. Use the stuff in System.Security.Cryptography if you actually do any encryption for anything.

6. Of the solutions listed above, I recommend solution 1, unless your information is really sensitive (such that people could make a business out of stealing that information). It isn't. If it were, you shouldn't be asking people on a forum.

[twentytwo]

Hi , can someone help me with this c# programming for password management with this basic requirements.

-Be able to search for the accounts that are added using this program.
-Prompt user to key in account, website, username and password.
-Be able to add, edit and delete the accounts when selected.
-Be able to view the account information when selected.

Thank you (:

[RichardGalaviz]

A password key is intended to secure a benefit against unapproved access from an aggressor. Keeping in mind the end goal to keep somebody from getting access get to, the secret key must be difficult to figure, and that implies that it must be solid enough to abstain from speculating based assaults . A few heuristics to keep a feeble watchword are a blending of:
numbers, exceptional characters,upper and lower case characters,a least of 8 characters in length.

[JOSheaIV]

Why not use a 1 way?

You can HASH the password, when it's initally entered and store that value. Then every time the user tries to log in, in the future, hash that value and compare it to what you have on record. If they match up, the hashed password values (along with the username), then you have a match. Don't forget to include a SALT.

If I totally lost you, hashing is a way to storing values in an almost unreversible state. It's a safe way to store passwords, especially when you use a SALT which is used to make your hashes vary even more, so people who run these database (known as for instance rainbow tables) that contain a collection of hash code values and their plain text equivlance, are a lot less effective.

Here's a snippet of some code I wrote to do SHA256 hash values

using System.Security.Cryptography;

public static string Generate_SHA256 (string input) //Generates a SHA-256 hash for a provided string
{
    byte [] bytes = Encoding.UTF8.GetBytes(input.ToString()); //begins the creation of the SHA256 hash code

    SHA256 SHA_Value = SHA256.Create();
    byte [] HashedBytes = SHA_Value.ComputeHash(bytes);

    return Convert.ToBase64String(HashedBytes);
}

That make sense? I hope this didn't get to confusing

(there are of course other ways such as AES and RSA encrpytion, or DSA (which shouldn't be used), but those invovles store a key in some manner to encrypt and decrypt values)