Re: Newbie Salt and Pass Phrase Question.



Descartys@xxxxxxxxx wrote:
Larry Lindstrom wrote:
<snip>
If that's the case, will it be secure to generate one
salt for my application and use the same salt for every
user?

That would solve the problem.

This has already been answered in brief, but remembering the
¨newbie¨ in the subject line i´ll expand a little bit ;)

The basic purpose of a salt, is, as has been mentioned, to make
pre-computing simple passwords (such as dictionary words) and then
comparing them to the hashes stored in your database much more
difficult. Say twenty of your users choose the password ¨password¨
(just for an example, anything common really). Without salts it is
trivial for the attacker to compare these hashes to his precomputed
list, which is sure to contain such a simple word, and suddenly he has
their passwords. On the other hand, with unique salts, all of those
twenty hashes would be different, and the attacker would have to
individually attack each hash instead of whipping up a quick program to
do it to millions while he watches Star Trek re-runs (and this is even
if the salts are not secret...secret salts could even further
complicate individual hash cracking). So having unique salts is crucial
to the entire thing.

You could, of course, just remind your users to choose complex
alphanumeric passwords that bear no relation to words in any language,
but I would advice against leaving that in the hands of the users, and
really try to generate good unique salts for each user.

Thanks Descartys, and all who have responded in this thead:

I'll try to be brief, something I'm not good at. This
application will be used by clubs, and similar businesses.
The data will contain personal information of members of the
club, among other things. The personal information is not
financial, for this version of the program, but I'd like to
have that as an option. "Users" are people who have licensed
this program, or work for someone who has. Users are people
who query and update the data. For now, this is a database
application. Communication may be addressed in future
versions of the program, but not now.

Speed isn't much of an issue, so I'm planning to use ASE 256
with the CTR mode, SHA 256 and Fortuna.

I won't dictate policy, a business may tell all users to use
a common pass phrase, which will allow this information to be
shared through the organization, or each user may have their own
pass phrase, and not share.

My original plan was to have no user names, no table of users
in the database. Just start the program, enter your pass phrase,
and records you can read are available to you. I was thinking
of saving a hash of the pass phrase hash with each member record,
to test if this record was encrypted by the user. If the two
hashes don't agree, I'd display some text, like "Encrypted",
rather than the improperly decrypted text. I think this is
similar to a known plain text vulnerability, but I believe, with
a proper cypher, that's not considered much of a vulnerability.
Is a hash of the pass phrase hash offering an attacker too juicy
a target? What if I I salt this hash?

Now it looks like I'll need a table of users, which isn't
a bad thing. This will allow proper user name password logins.
This table will include user names and salt values, and those
will now be encrypted.

But how do I decrypt these salt values for each user?

Where is the key, or hash, or whatever, stored to decrypt
them? Or is this a case for non-encrypted salts?

I've wondered if there is a secure method to store keys
inside a program's executable.

Can I double duty my pass phrase as a password? Or is it
better to separate these two jobs into two values?

As I've stated so often in the last several weeks. I
appreciate all of the good advice I've been receiving.

Thanks
Larry

.



Relevant Pages

  • Re: SHA-1 vs. triple-DES for password encryption?
    ... crypt() and md5 crypt. ... several ways to turn a block cipher into a non-reversible hash ... You *need* to make sure to have reasonable salts. ... Store the salt and the derived key, ...
    (SecProg)
  • Re: SQL Storing Passwords?
    ... "...so the hashing is done like this SSHA" ... Keys are private parameters and salts are public parameters. ... First of all, storing salts next to a hash is not bad design, it ... The PWD in the table should be the actual hash of your password, ...
    (Security-Basics)
  • Re: What is md5sum?
    ... and what were the salts? ... Otherwise this is another urban ... one of my friends once found two passwords which had the same hash ...
    (comp.os.linux.setup)
  • RE: Rainbow Tables
    ... Fortunatly for this project we are only doing LM passwords, all on Windows machines. ... > the hashes and the cracked clear text and merge them into a table? ... have 4096 salts that are possible per password. ...
    (Pen-Test)
  • Re: Pass Phrase
    ... When I try to explain to my clients how to remember Pass Phrase, ... Total length of pass phrase is 18 characters. ... Account Passwords and Policies ... Do not store LAN Manager hash value on next password change ...
    (microsoft.public.security)