Best place to store passwords?

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi,

My application uses passwords to limit access to certain parts of the app. I
was considering storing these in my database but have heard that there can be
problems with this. I have heard using the Global Assembly Cache (GAC) would
be a good place.

Does anyone have any opinions on this and how would I implement the GAC
scenario?

Thanks In Advance
Macca
 
Hi,

You can stored it in the DB encripted.

No idea how to store it in the GAC , AFAIK the GAC is only for assemblies,
how you think to store a password there?
 
Er... the Global Assembly Cache is just that, a cache of your
assemblies, i.e. your .DLL and .EXE files. If you hard-code your
passwords into your program, and you store your program in the GAC,
then, yes, you'd be storing your passwords in the GAC, albeit
vicariously.

I wonder if perhaps you mean Isolated Storage? That's where each
program gets a special unique location where it can read and write
internal (i.e. hidden from the user) data files, like application
settings, user settings, and the like. It's a much better way of doing
things than the registry, IMO. If that's what you mean, check out this:

http://www.dotnetdevs.com/articles/IsolatedStorage.aspx

But you should note that Isolated Storage is just a file system, so
unless you encrypt your password file somehow, anyone who understands
how your program is designed and .NET in general will be able to read
those passwords.

If this is a web application or an N-Tier application, I would suggest
that you follow Ignacio's suggestion -- store the passwords encrypted
on the database. That will allow you to keep the required passwords
identical no matter where the program is being used. If you stored the
passwords in Isolated Storage, and later changed them somehow, you'd
have to change the password for every installation of your application.
Big mess there.
 
Er... the Global Assembly Cache is just that, a cache of your
assemblies, i.e. your .DLL and .EXE files. If you hard-code your
passwords into your program, and you store your program in the GAC,
then, yes, you'd be storing your passwords in the GAC, albeit
vicariously.

I wonder if perhaps you mean Isolated Storage? That's where each
program gets a special unique location where it can read and write
internal (i.e. hidden from the user) data files, like application
settings, user settings, and the like. It's a much better way of doing
things than the registry, IMO. If that's what you mean, check out this:

http://www.dotnetdevs.com/articles/IsolatedStorage.aspx

But you should note that Isolated Storage is just a file system, so
unless you encrypt your password file somehow, anyone who understands
how your program is designed and .NET in general will be able to read
those passwords.

If this is a web application or an N-Tier application, I would suggest
that you follow Ignacio's suggestion -- store the passwords encrypted
on the database. That will allow you to keep the required passwords
identical no matter where the program is being used. If you stored the
passwords in Isolated Storage, and later changed them somehow, you'd
have to change the password for every installation of your application.
Big mess there.
 
You shouldn't store passwords anywhere unless you absolutely have to (which
should be never). Instead, store a salted hash for each user's password
which can be verified by the app when the user types in their password. I
recommend Googling "C# salt hash" and reading through some of the many
articles out there on this common technique.

You can see the different hash functions inside the
System.Security.Cryptography namespace.

-sb
 
Store the (encrypted) passwords in a database, or store them
(encrypted, again) in a .config file, depending upon the application.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Back
Top