"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.
~~~~