![]() |
| ||
| Best practices for storing password? 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 :) |
| ||
| Re: Best practices for storing password? 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 |
| ||
| Re: Best practices for storing password? 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. |
| ||
| Re: Best practices for storing password? 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. |
| ||
| Re: Best practices for storing password? 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. |
| All times are GMT -4. The time now is 8:52 pm. |
Forum system based on vBulletin Copyright ©2000 - 2009, Jelsoft Enterprises Ltd.
©2003 - 2009 DaniWeb® LLC