incorrect length

[Miquel 'Fire' Burns]

On that sample page I posted, look at the hex line and study the output, note how the repeat shows up in the output?

[David]

I don't understand, but it's okay :-)

My basic point is that giving PM 10,000 unique characters to choose from in composing the password should not make the outputted password less secure than if I gave it 100 unique characters to choose from. On the contrary, the opposite should be true.

However, it seems that's the way it works (10000 characters -> ~6? character password; 100 characters -> 40 character password), and, moreover, has to work. Rather unfortunate.

[Eric H. Jung]

I think the key piece of information you're not understanding is that hash functions -- the underlying core of password generation -- output a fixed length regardless of input size.

If the radix (character set) is too large, I would suggest, as before, selecting characters from the inputted character set to actually use.

Then not all of the characters have the potential to be in the generated password.

Example: User enters 10000 characters ($input). To get the desired password length, the character set needs to be 100 (say) ($maxinput). $input/$maxinput = $characterskipvalue (in this case, 100). PM will then use every $characterskipvalue'th character in the inputted set, setting the radix based on this limited set and using the characters in this limited set.

Again, this has the drawback that not all of the 10,000 characters have the potential to be in the generated password. I'd rather inform the user that the character set is too large than fool him into thinking all the specified characters can be used in the generated password.

[David]

Alright, here's another solution: multiple hashes.

"Because of the nature of hash functions, your requested hash+character set precludes a password of the desired length. The maximum password length possible with your chosen settings is ___. Please choose an additional hash or make a change in your existing hash/character set settings.

For additional information, please see the <link>Help Section</link> on this topic."

Example: User chooses SHA-1 and SHA-256, in that order. The generated password is a concatenation of the hashes->SHA-1.SHA-256.

I'm not sure how you would go about implementing this solution--it is likely that at some point someone would want three hashes, or four, or whatever.

It seems to me that one ought to be able to enter the Unicode character set and generate a password of at least 127 characters (your current windows max, likely to change). Am I crazy?

One problem with this solution is insecurity--I don't know enough to know if this is insecure. But I'm sure the answer to that is clear to people familiar with hashes.

[David]

Or, why not, another:

    "If the hash size is less than the key size, multiple instances of
    the hash context are created -- enough to produce the required key
    data. These instances are preloaded with 0, 1, 2, ... octets of
    zeros (that is to say, the first instance has no preloading, the
    second gets preloaded with 1 octet of zero, the third is preloaded
    with two octets of zeros, and so forth).

    As the data is hashed, it is given independently to each hash
    context. Since the contexts have been initialized differently, they
    will each produce different hash output.  Once the passphrase is
    hashed, the output data from the multiple hashes is concatenated,
    first hash leftmost, to produce the key data, with any excess octets
    on the right discarded."

    (http://www.ietf.org/internet-drafts/draft-ietf-openpgp-rfc2440bis-14.txt)

Here's a discussion on the insecurity of multiple hash concatenation: http://man.phpschool.com/manual/kr/function.md5.php. You can look at the regular php manual, but at least one of the responses has been deleted there.

[tanstaafl]

Or maybe PM should simply institute a sane limitation on the length of passwords?

Personally, I do not see the value in a 128 character password... I mean, its not like you're protecting the CIA NOC list, or the launch codes to the nations ballistic missile system or anything.

I see no reason to complicate the process. My suggestion is to simply limit the length of the passwords according to the inherent limitations of the hashes themselves.

[David]

Since we're on the topic, what about collisions?

Given a fixed character set output, the chance of collisions using a good hash is next to nothing.

Password generation using a variable character set, however, looks offhand to raise the probability of collisions significantly though.

(1) Obtain a 6 character output from a requested 20-character password with 400- character input.
(2) Obtain the same 6 character output from a requested 6-character password with 50-character input
etc.

I apologize if this is another dumb question.

Thanks everyone for helping me understand what's going on with the original issue here.

I think it's much clearer now. :)

[Eric H. Jung]

Hi David,

I'm not sure how you would go about implementing this solution--it is likely that at some point someone would want three hashes, or four, or whatever.

Right. Inherent problem with that solution.

Regarding your quote from the OpenPGP RFC, PasswordMaker only uses one-way, non-symmetric hashing for generated passwords... therefore, no keys, keyrings, or keystores are involved. Thanks for the link, but it's not really applicable.

Hi tanstaafl,

Or maybe PM should simply institute a sane limitation on the length of passwords?

I'd rather not when there is a decent solution. I've thought of one, I think: the hash value itself should be the input to iterative calls of the hash function. In pseudo-code:

Code: [Select]

output = "";  // the generated password
input = master_password + url + modifier + the_other_stuff;
while (length_of_output < desired_pw_length)  {
  temp = hash(input);
  output = output + temp;
  input = temp;
}


[David]

Regarding your quote from the OpenPGP RFC, PasswordMaker only uses one-way, non-symmetric hashing for generated passwords... therefore, no keys, keyrings, or keystores are involved. Thanks for the link, but it's not really applicable.

Hmm. I didn't mean for the link to be taken literally--just that their solution to their own problem might shed light on a way to solve PM's.

[Eric H. Jung]

I see. Well, what do you think of the solution I just proposed?

[David]

Perhaps it's because of my lack of understanding, but wouldn't it be rather repetitive-and if repetitive, while perhaps it wouldn't matter, fairly easy to establish the original hash given the entire password?

What I mean is that, if I understand it correctly-and there's a good chance I don't-the first x characters (the first hash) would be a selection of the original 10,000 characters, say, while the following characters would be a selection of the characters in the first hash.

First x characters: selected from 10,000.
Following characters: selected from x.

The OpenPGP initialization variation avoids this by concatenating multiple, different hashes of the original.

[Eric H. Jung]

wouldn't it be rather repetitive

Definitely not. I can give you some examples if you'd like.

would be a selection of the original 10,000 characters, say, while the following characters would be a selection of the characters in the first hash.

No. The encoding remains the same for all iterations.

[David]

Ok, sounds good then--not surprising I misunderstood. :) Thanks for pursuing this Eric!

[Eric H. Jung]

Thanks for pursuing this Eric!

My pleasure. Feel free to ask away :)

[tanstaafl]

Or maybe PM should simply institute a sane limitation on the length of passwords?

I'd rather not when there is a decent solution. I've thought of one, I think: the hash value itself should be the input to iterative calls of the hash function. In pseudo-code:

Really, I was only kidding. I don't like limitations, but was just making a point... are there really people in here who are using 128 character passwords and/or 200+ character sets? If so... WHY?

Or maybe a better question to ask... just *how* much more secure is it? I think using a 12 character passwords based on HMAC-SHA-256 and the Default Character Set (modified by me in my own special way, of course) is more than sufficient, even for highly critical and/or sensitive top-secret government purposes.

That said, your proposed solution sounds best - as usual...