incorrect length

[Miquel 'Fire' Burns]

BTW, for warning of power of two, here's some code in which you can check to see if a number is a power of 2 (it's false if it is a power of 2)

Code: [Select]

((number - 1) & number)number being the length of the encode string, your proposed solution may not suffer from that too much...

[Eric H. Jung]

It's still not clear to me why character sets which aren't a power of 2 cause the repetition?

[Miquel 'Fire' Burns]

Character set are a power of 2 cause the repetition, those that aren't won't cause it. Look at the test page I posted, it has a repeating string as input for rstr2any and shows some random encodings to be used. Though if your solutions ends up runing the code through rstr2any, and append stuff to it's output, it may not be an issue.

[Eric H. Jung]

NOW i get it. I didn't notice the input was also a repeated string. Thanks.

[pgimeno]

Hello,

My suggestion for extending the password length is to use an additional counter which is hashed together with the data, instead of hashing the hash which might introduce unknown problems. Something like this:

For the first iteration, just 'data' is hashed, as before (this helps keeping backward compatibility).
For the second iteration, 'data' + '2' is hashed.
For the third iteraton, 'data' + '3' is hashed.

And so on. One caveat: in order to simplify the explanation I haven't introduced a separator between the data and the counter, but it's advisable to do so. '\n' or '\0' would be good separators. This is how it would look like for the second and following iterations when adding '\n' as separator:

Second iteration: 'data' + '\n' + '2' is hashed.
Third iteration: 'data' + '\n' + '3' is hashed.
...

The addition of the separator prevents that e.g. if 'data' ends in '2' the hash is the same as with 'data' with the '2' removed, in the second iteration. Example: say data = 'abc2'; without separator, the substring resulting from it would be the same as with data = 'abc' in the second iteration. With separator, the hash from 'abc\n2' is different from the one from 'abc2' and the problem disappears.

Thoughts?

-- Pedro Gimeno

[Eric H. Jung]

Hi Pedro,

I like this idea. One question: is a separator necessary for each iteration, or just the first? If so, why?

[pgimeno]

Eric,

Just the second and following need a separator. The first one may stay as it is now.

The separator is needed to identify 'abc2' without any extra data and 'abc' + '2' (the '2' appended because it is the second iteration) as different strings.

I'll try a better explanation. Consider the following scenario:

You have two users, 'user' and 'user2', for connecting to domain.com. Your master password is 'PW'. You want to generate a long key which needs 2 hashes. If you don't use a separator, in the case of the first user the hashes would apply to these strings:

'PWdomain.comuser' (for the first iteration)
'PWdomain.comuser2' (for the second iteration)

On the other hand, in the case of the second user the following strings will be hashed:

'PWdomain.comuser2'
'PWdomain.comuser22'

The first string in this case is the same as the second string used before, thus the password characters generated will be equal. However, using separators the strings hashed would be, for the first user:

'PWdomain.comuser'
'PWdomain.comuser\n2'

and for the second user:

'PWdomain.comuser2'
'PWdomain.comuser2\n2'

All strings are now different, which is safer. Actually, I would like to see separators between all the input fields in the password generation algorithm for similar reasons (simple concatenation doesn't distinguish where each field terminates and the next starts), but that would break compatibility.

Note that everywhere I write \n I mean ASCII character LF, code 10. In any case the idea is to choose a separator that can't be entered by the user.

-- Pedro Gimeno

[Eric H. Jung]

Sounds like a good idea. Thanks for the clarification. I'll use your suggestion instead of mine for the implementation.

[Eric H. Jung]

My suggestion for extending the password length is to use an additional counter which is hashed together with the data, instead of hashing the hash which might introduce unknown problems.

This is implemented in 1.3.3. Additionally, one of the original bugs mentioned in this thread by David is also fixed:

Incidentally, the random character feature is off by one character in length: ask for 3 random characters, and it gives you 4.

-Eric

[David]

Tell me please you only implemented this fix for *new* passwords...

[Eric H. Jung]

Yikes, unfortunately not. I didn't think anyone was experiencing the password limit length except when doing testing. I didn't realize you actually experienced this problem with real accounts.

You should be able to get around the problem by reducing the password length to the length of the password generated by 1.3.2. If you don't remember the password lengths you had in 1.3.2, uninstall 1.3.3, reinstall 1.3.2 and write them down.

1.3.3 *is* backwards compatible with 1.3.2 in that generated passwords are the same up to the max password lengths of 1.3.2. Where 1.3.2 would have stopped generating characters even though you requested a longer password, 1.3.3 steps up and actually provides you with all the needed characters.

Does that help?

[David]

Thanks Eric! I appreciate all your work--especially when you fix bugs that are bugging me ;).

So there'll just be a little bump here.

I figured I would have to do something like this, but I wanted to make sure that PM update was the problem and not something else (like I can't type today, etc.).