Just because I just can't remember all those passwords for every site
I need to register for, I thought I'd try my hands on building a
windows exe in C# that I can safely store all that sensitive
information in. Obviously, just for fun, I'd like to try to make it as
secure as possible.

Here's what I thought of so far:

1. Upon startup no sensitive data is shown. User has to enter a pass-
phrase of at least 15 characters and a passcode (6 numbers). The pass-
phrase is then salt-hashed (using the passcode as salt) and compared
to the salt-hashed equivalent which is stored in a database (probably
just Access).

2. Once the user has logged in, the sensitive information is decrypted
(they are stored encrypted in the same database) using the entered
passphrase as key. User can now see this.

3. This means that no passwords or anything are stored in the actual
code which (presumably) makes this more safe should the exe be reverse-
engineered.

4. It also means that should some bad hacker person get a hold of my
database, they can't just change the pass-phrase in there and use the
application to get into my data, because the data is encrypted using
the old pass-phrase.

5. A logged in user should be able to change the pass-phrase and pass-
code, after which all the sensitive information is re-stored,
encrypted using the new pass-phrase.

My question is: how safe is this? Where are the gaping holes in this
logic? What kinds of attacks could get through this? Any suggestions
for improvement? I've found lots of information about securely storing
passwords in a web application. But not really very much about
executables.

PS: no comments about re-inventing the wheel - I'm sure there's lots
of great products out there that do all this and more - it's just a
pet project!

Cheers, Eva

Maybe you wanna have a look at this tool before you start coding

http://www.pluralsight.com/toolconte..._v_1_5_0_9.zip

Keith also wrote a series of articles on the inner working. You can find
them on MSDN.


-----
Dominick Baier (http://www.leastprivilege.com)

Developing More Secure Microsoft ASP.NET 2.0 Applications (http://www.microsoft.com/mspress/books/9989.asp)

Maybe you wanna have a look at this tool before you start coding

http://www.pluralsight.com/toolconte..._v_1_5_0_9.zip

Keith also wrote a series of articles on the inner working. You can find
them on MSDN.


-----
Dominick Baier (http://www.leastprivilege.com)

Developing More Secure Microsoft ASP.NET 2.0 Applications (http://www.microsoft.com/mspress/books/9989.asp)

Yes - cool tool, will have a look at that. But as I said, I'd like to
do this as a pet project - for educational value... I can always use
this one if mine doesn't work out.

So, I wouldn't mind knowing how safe my own ideas actually are!!

Yes - cool tool, will have a look at that. But as I said, I'd like to
do this as a pet project - for educational value... I can always use
this one if mine doesn't work out.

So, I wouldn't mind knowing how safe my own ideas actually are!!

ok. i don't have the time now to comment thoroughly on your ideas...regardless
- you may wanna have a look at this

http://msdn.microsoft.com/msdnmag/is...SecurityBriefs
http://msdn.microsoft.com/msdnmag/is...SecurityBriefs


-----
Dominick Baier (http://www.leastprivilege.com)

Developing More Secure Microsoft ASP.NET 2.0 Applications (http://www.microsoft.com/mspress/books/9989.asp)

ok. i don't have the time now to comment thoroughly on your ideas...regardless
- you may wanna have a look at this

http://msdn.microsoft.com/msdnmag/is...SecurityBriefs
http://msdn.microsoft.com/msdnmag/is...SecurityBriefs


-----
Dominick Baier (http://www.leastprivilege.com)

Developing More Secure Microsoft ASP.NET 2.0 Applications (http://www.microsoft.com/mspress/books/9989.asp)

Hi,
You may also look at Password Safe that was originally created by
Bruce Schneier and now is living its life as an open source project
here: http://passwordsafe.sourceforge.net/
Bruce has also wrote a couple of articles regarding Password Safe that
you can easily find on Google.

-Valery

Hi,
You may also look at Password Safe that was originally created by
Bruce Schneier and now is living its life as an open source project
here: http://passwordsafe.sourceforge.net/
Bruce has also wrote a couple of articles regarding Password Safe that
you can easily find on Google.

-Valery

"EDienske" <evadienske (AT) hotmail (DOT) com> wrote

A salt doesn't have to be secret, and should not be created by the user. The
point of a salt (equivalent in many ways to an initialisation vector) is to
make sure that if two users have the same password, by accident or
collusion, it is not revealed to the hacker by virtue of having the same
hash.

The salt may safely be stored along with the hash of the password. It should
be randomly generated (with a strong random number source), and should be
significantly different for each time a password is hashed.

Or, you could always call out to DPAPI, to encrypt the password data using
the user's own key and an initialisation vector unique for each password, so
that they don't need to enter another identifier, if they've identified
themselves to Windows.

Always a good idea - secrets should not be stored in code, because code is
by its very nature public.

That certainly does make good logical sense, but again, there are easier
ways - using the DPAPI avoids any requirement for the user to have an extra
pass-phrase above and beyond their Windows logon.

It certainly makes sense to provide an ability to re-encrypt, so as to hide
information such as "this password hasn't changed in six years"

Users don't like entering passwords; don't make them enter another password.

Here's a question - what does your solution provide that isn't solved by a
text file that's encrypted using EFS? What would EFS protection provide that
your solution doesn't?

Thinking on that will allow you to consider how your application's security
might want to work.

So go find some of those other wheels, especially those with good
documentation and/or source code, and read up on why the application was
designed that way.

Alun.
~~~~