943,097 Members | Top Members by Rank

Ad:
  • C# Discussion Thread
  • Unsolved
  • Views: 4321
  • C# RSS
Jan 9th, 2009
0

Best practices for storing password?

Expand Post »
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
Reputation Points: 10
Solved Threads: 0
Light Poster
david.1982 is offline Offline
28 posts
since Mar 2008
Jan 9th, 2009
1

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
Reputation Points: 2023
Solved Threads: 642
Senior Poster
ddanbe is offline Offline
3,733 posts
since Oct 2008
Jan 9th, 2009
0

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.
Featured Poster
Reputation Points: 480
Solved Threads: 276
Postaholic
Ramy Mahrous is offline Offline
2,189 posts
since Aug 2006
Jan 9th, 2009
0

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.
Reputation Points: 196
Solved Threads: 190
Posting Virtuoso
LizR is offline Offline
1,735 posts
since Aug 2008
Jan 10th, 2009
2

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.
Team Colleague
Reputation Points: 1133
Solved Threads: 171
Super Senior Demiposter
Rashakil Fol is offline Offline
2,474 posts
since Jun 2005

This thread is more than three months old

No one has posted to this discussion for at least three months. Please let old threads die and do not reply to them unless you feel you have something new and valuable to contribute that absolutely must be added to make the discussion complete. Otherwise, please start a new thread in this forum instead.
Message:
Previous Thread in C# Forum Timeline: C# console applications & highlighting output to screen
Next Thread in C# Forum Timeline: Substring in C#





About Us | Contact Us | Advertise | Acceptable Use Policy
Forum Index | Build Custom RSS Feed


Follow us on Twitter


© 2011 DaniWeb® LLC