| | |
Best practices for storing password?
Please support our C# advertiser: Intel Parallel Studio Home
![]() |
•
•
Join Date: Mar 2008
Posts: 24
Reputation:
Solved Threads: 0
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
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
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
You could look at this snippet for encryption http://www.daniweb.com/code/snippet1009.html
Today is a gift, that's why it is called "The Present".
Make love, no war. Cave ab homine unius libri.
Danny
Make love, no war. Cave ab homine unius libri.
Danny
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.
BI Developer | LINKdotNET
B.Sc Computer Science, Helwan University
Technical blog | http://ramymahrous.wordpress.com
LinkedIn | http://www.linkedin.com/in/ramymahrous
B.Sc Computer Science, Helwan University
Technical blog | http://ramymahrous.wordpress.com
LinkedIn | http://www.linkedin.com/in/ramymahrous
•
•
Join Date: Aug 2008
Posts: 1,735
Reputation:
Solved Threads: 186
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.
Did I just hear "You gotta help us, Doc. We've tried nothin' and we're all out of ideas" ? Is this you? Dont let this be you! I will put in as much effort as you seem to.
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.
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.
![]() |
Other Threads in the C# Forum
- Previous Thread: C# console applications & highlighting output to screen
- Next Thread: Substring in C#
| Thread Tools | Search this Thread |
.net access algorithm array asp barchart bitmap box broadcast c# check checkbox client column combobox control conversion csharp custom database databasesearch datagrid datagridview datagridviewcheckbox dataset datetime degrees development display draganddrop drawing encryption enum equation excel file form format formatting formbox forms formupdate function gdi+ image index input install java label linux list listbox mandelbrot math mouseclick mysql namevaluepairs networking operator packaging path photoshop picturebox pixelinversion post powerpacks programming radians regex remoting reporting richtextbox robot server sleep socket sql statistics stream string table text textbox thread time timer transform treeview update usercontrol validation visualstudio wait webbrowser wfa windows winforms wpf xml






