incorrect length

[David]

Steps to reproduce (with my setup at least):
1) Enter a large password length-say 40.
2) Enter a large number of characters-say 200.
3) Use PM to populate password field.

Actual results:
The password generated by PM is shorter than requested. The exact length depends on other factors.

Desired results:
The password length matches the requested length.

This is not a case of a password being cut off by maxlength.

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

[tanstaafl]

Eric, I nailed this down to at least give you a starting point of where to look:

Password Length set to 35
No leet
HMAC-SHA-256
URL Contains: .google.com/
Use URL: google.com

I simply copied the default character set and pasted it at the end of itself to produce an incorrect password length. I then used the half-split method, until I hit upon the magic number of 180 characters that produce a good result - anything more produces a password that is one character short:

Character set length = 180
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789`~!@#$%^&*()_-+={}|[]\:";'<>?,./ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789`~!@#$%^&*()_-+={}|[]\:"
PW: OK
CYY_FFQT,&?C9QSU-`v{o}v%ehl{J#{&u:& = 35

Character set length = 181
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789`~!@#$%^&*()_-+={}|[]\:";'<>?,./ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789`~!@#$%^&*()_-+={}|[]\:";
PW: WRONG
;!Ut$(MkhV*^Ya_xbE@CW4Pm6%Dv2*<#SL = 34 - off by one

Next, I tried just alphanumeric characters, to see if maybe it had anything to do with the non-alpha-numerics, but this produced the same results (180 character max).

I did play with even larger character sets, and the resulting password length gets even shorter, so the bug seems to be compounding.

I hope this helps...

[tanstaafl]

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

This one is confirmed, but not every time...

The first few times I tried it, it worked fine - then it started doing as you described.

I tried closing the Browser, and reopening it, and again - it would work once, twice, sometimes three times, but then it would start giving one extra character.

[Eric H. Jung]

The password generated by PM is shorter than requested. The exact length depends on other factors.

I'm aware of this. It's due to the nature of hash functions: they each produce a fixed length byte array. SHA-1 always produces 160 bytes; SHA-256 always produces 256 bytes. The bytes are encoded into printable characters using the character set you define, but that character set is a radix. The more characters in the set, the more bytes can be encoded by a single character.

The only way around this is to repeat the password to meet the requested password length.

Is this an acceptable fix?

[tanstaafl]

Ok... well, as long as the problem is known and reproducable - and not likely to change? - then I'm ok with simply dcumenting it myself (when, why and how it happens). Even better would be a pop-up warning whenever someone sets their Settings in such a way that this 'issue (I guess bug isn't the correct term) kicks in?

I don't use character sets that big or passwords that long, so this doesn't affect me anyway. Now that you mention it, I do recall something about his, but I guess since it didn't affect me I simply forgot about it.

[Eric H. Jung]

I will add a popup warning about it; good idea, and also have the password repeat until it meets the desired length.

David, I'll fix the Random character length problem--thanks for reporting it.
-Eric

[Miquel 'Fire' Burns]

I think for the repeat thing, have the repeat occur before the rstr2any function, so that if the character set is more than the hex string "0123456789abcdef" you can't see where it repeats. Maybe repeat the hash some 30 times?

BTW, you sure about SHA1 returning 160 bytes? I thought it was 20. Maybe you're thinking bits? (160/8=20)

[tanstaafl]

I will add a popup warning about it; good idea, and also have the password repeat until it meets the desired length.

Perfect...

Out of curiousity...

It's due to the nature of hash functions: they each produce a fixed length byte array. SHA-1 always produces 160 bytes; SHA-256 always produces 256 bytes.

This may be a dumb question (obvious to anyone who understands 'the nature of hash functions'), but - is this something that is likely to ever change? If not, then your solution of repeating the password until the number of characters is reached si definitely the best solution.

[David]

I'm aware of this. It's due to the nature of hash functions: they each produce a fixed length byte array. SHA-1 always produces 160 bytes; SHA-256 always produces 256 bytes. The bytes are encoded into printable characters using the character set you define, but that character set is a radix. The more characters in the set, the more bytes can be encoded by a single character.

The only way around this is to repeat the password to meet the requested password length.

Is this an acceptable fix?

Thanks for the replies!

Three things:

(1) I don't understand what increasing the number of characters inputted has to do with the outputted password length. With 100 characters, the outputted password matches the requested password in length. With 200+ characters, the outputted password is shorter. With 10,000 characters, it's quite a bit shorter.

In my confused mind, if the # of characters inputted really has to affect the outputted password length, wouldn't it be more secure (than repeating the password) to pick a random set of x (max number of characters) characters from the inputted set?

(2) Repeating the password or whatever solution is done runs the chance of altering existing passwords, so like other fixes, it probably should only be done with new passwords.

(3) I would suggest that if there's a warning, it should give the max input characters and max password length so people aren't having to play around to find those values...

Anyway, sorry for the confusion. I regularly use very long passwords; I think it was the addition of the random feature that brought this issue to the fore, as it's now simple to have input character sets of whatever length you wish.

Edit: I guess it can't be random, silly me. :)

[Eric H. Jung]

I think for the repeat thing, have the repeat occur before the rstr2any function, so that if the character set is more than the hex string "0123456789abcdef" you can't see where it repeats.

I don't understand how this would hide the repeat. Inputting the byte array duplicated 30 times to rstr2any() should produce repeated output, no? BTW, maybe you could tell me how you setup Venkman to step through this code. It would be very helpful to me.

BTW, you sure about SHA1 returning 160 bytes? I thought it was 20. Maybe you're thinking bits? (160/8=20)

Sorry, I meant bits.

is this something that is likely to ever change?

Nope. Never.

I don't understand what increasing the number of characters inputted has to do with the outputted password length

I'll demonstrate by analogy, and assume you know what hexadecimal. Suppose you want to represent the number fifteen in decimal notation (base 10). It requires two characters to do so; a one and a five: 15. Now suppose you want to represent that same number in hexadecimal notation (base 16). It requires only one character to do so: F. But in base 2 (binary), you'd require four characters: 1111. As you can see, the higher the base, the less characters needed to represent ("encode") the same information.

The character set for base 10 is generally 0123456789. The character set for base 16 is generally 0123456789abcdef. When you specify a character set comprised of 200 characters, you are using base 200 notation to encode a mere 8 bytes of data for MD4/MD5, 20 bytes for SHA1 and RIPEMD-160, and 32 bytes for SHA-256. I hope this explains things.

Reading your last response, David, has given me another idea. I think PasswordMaker should limit password length as a function of the length of the character set rather than repeating the password.

[David]

Ok, I'd have to look at the code. Perhaps it has something to do with hashing, but from an outsider's perspective, the character set should not be doing double duty as (1) characters to choose from to make the password and (2) radix.

I don't think you should limit password length. If the radix (character set) is too large, I would suggest, as before, selecting characters from the inputted character set to actually use.

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, though, it's not clear to me why the character set is doing double-duty. Don't feel like you have/ought to explain it though--I'll take your word. :)

[Eric H. Jung]

it's not clear to me why the character set is doing double-duty

Hm, can you explain why you think the character set is being used for two things? What's the second purpose? You might help me to think of other ways of solving this/doing this by talking it through with me.

[David]

The bytes are encoded into printable characters using [1] the character set you define, but that [2] character set is a radix.

the character set should not be doing double duty as (1) characters to choose from to make the password and (2) radix.

Is that clearer? I told you I was confused :-(

[Miquel 'Fire' Burns]

Unless you're using a base that is a power of 2 (Most likely being 16 (hex character set)) the hash returns one big ass number, and rstr2any is basically converting raw bytes into another base.

Look at this: http://www.miquelfire.com/stuff/rstr2any.htm ;)

[Eric H. Jung]

Unless you're using a base that is a power of 2

What does it return if it is a power of 2? this code was written by Paul Johnston, and I haven't stepped through it with Venkman...yet.

the character set should not be doing double duty as (1) characters to choose from to make the password and (2) radix.

Well, that's not really double-duty. Those are one and the same. Think about hex, for instance. Hex's character set is 0123456789abcdef and its radix is 16. The character set is merely defining an encoding (or code page) with which to map bytes to characters... just like ASCII, UTF-8, UTF-16, IS0-8859-1, or any other code page...