Re: Password storage facility exe - how safe is this idea?

"EDienske" <evadienske@xxxxxxxxxxx> wrote in message
news:1183025245.801326.78090@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
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).

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.

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.

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.

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.

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

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.

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.

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.

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" :)

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.

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.

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!

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


.

Relevant Pages

  • Re: Custom UsernameTokenManager
    ... sender needs to know the salt. ... encrypt it first with server's public key. ... authentication anyway so you can encrypt and sign future messages. ... This salts the pw and username and encrypts/signs everything so no ...
    (microsoft.public.dotnet.framework.webservices.enhancements)
  • Re: my KDF vs dictionary attacks
    ... When the OP wrote, "the salt has 1 requirement, it must encrypt into a 32 character string, no more and no less, this means that the salt has a minimum of 5 digits and a maximum of 20 digits," did you understand what ... DES is a 64-bit block cipher - 8 bytes at a time. ...
    (sci.crypt)
  • Default AES Salt in ASPNET2 Site
    ... and uses custom AES and SHA1 keys ... in Web.config to encrypt or hash password information. ... The ManagedRinjdael approach uses both a key and a salt in its operation. ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: my KDF vs dictionary attacks
    ... When the OP wrote, "the salt has 1 requirement, it must encrypt into a 32 character string, no more and no less, this means that the salt has a minimum of 5 digits and a maximum of 20 digits," did you understand what ... some encryption systems will give a larger output if the input is larger than a certain criteria, for example, twofish will encrypt a 5 character string into a 32 character output string, ...
    (sci.crypt)
  • Re: my KDF vs dictionary attacks
    ... does not need to be secret, with the sbox that i have, if the salt is known ... to the attacker, the encryption sequence becomes useless, i can elaborate on ... to the pass-phrase that induced it. ... within a dictionary table consisting of 2^512 entries of 512 bits, ...
    (sci.crypt)