Leading 0s trimmed; causes incompatibility with .6

[breyed]

In version 0.7.2, it appears that leading zeros are dropped from the generated passwords. This appears to have not the case in 0.6.

Here is a repro:

Use the following configuration for both versions:
MD5, 8 char pw, chars 0123456789abcdef, no l33t, URL component: domain only

Use the domain: sunrocket.com
Use the password: 0123456789abcdefghijklmnop

Try the above in the passwordmaker extension, version 0.7.2.
You'll get this pw: 44813afb

Now try the above using the 0.6 jscript version at this URL:
http://breyfamily.net/Password/
You'll get this pw: 0044813a

I haven't tried this specific use case with the 0.6 extension, but I suspect it matches the jscript version, or else I wouldn't have noticed the problem in the first place (I couldn't log into one of my accounts after I upgraded!).

[Eric H. Jung]

Hi breyed,

Thanks for the reporting this inconsistency between versions. I've duplicated it, and your mirror of PasswordMaker Online 0.6 was quite helpful (prevented me from having to dig that out).

At this point, I'm not sure I should change it back to the 0.6 behavior. It could harm more than help since it would introduce leading zeros for some of the algorithms, thereby changing passwords for many people yet again (including you, unless you haven't upgraded).

I am truly sorry for the inconvenience. My goal all along has been to maintain compatility across versions, and I think I've done a pretty good job of that going all the way back to version 0.1 which only supported md5.

I have a set of tests I run against all the algorithms before doing a release which has changed them to ensure compatibility. Clearly, I need to update my tests. The good news, however, is the algorithms are very unlikely to change again. The only reason they changed to begin with was to support arbitrary characters encodings (not just hexadecimal).

I've seen that you're active on [email protected], so I value your opinion. What do you suggest at this point?

Best regards,
Eric

[breyed]

My advice would be to use the algorithm that does not trim leading zeros… if certain assumptions I am making hold true.  Here’s why:

1. Sticking with the trimming algorithm will cause more incompatibility problems than reverting back to the non-trimming algorithm.  Here’s why:

1.a. Most people using 0.7 are using the default character set [assumption], which has some 40+ characters.  Therefore, trimmed zeros (and hence incompatibility with existing 0.7 passwords) will occur for only 1 out of 40+ passwords.  OTOH, in 0.6, the character set was smaller, and so a greater proportion of passwords would be broken (1 in 16) if 0.7 would continue to trim.

1.b. 0.6 has been around a lot longer than 0.7 and so a lot more passwords have been generated using it [assumption].

2. The algorithm that does not trim leading zeros produces a stronger password, since the set of possible passwords is larger.

3. There aren’t any other factors to consider. [Big? assumption]

[Eric H. Jung]

Hi breyed,

Very good points. I will work on this. Since I didn't write the encoding algorithm, it will take awhile (bitwise arithmetic was never a strongpoint of mine).

Thanks for the feedback,
Eric

[breyed]

If you could post here when you've released a beta with the changes, that would be most helpful for me to know when I can provide "real-world" testing.

Also, if you need a hand with updating the code for the bitwise arithmatic, let me know. That happens to be one of my strong points. :-)

Ed

[Eric H. Jung]

Hi Ed,
I've got the changes, but my PC crashed. It wasn't until this past weekend that I could rebuild my system. Now that I'm running Xandros instead of Windows, I have to re-write my build script before I can issue a beta. There are also still a few tools I need to install before I can do development (namely, Eclipse and some plug-ins).

I'll let you know when there's a beta. I think I will offer a checkbox to remove leading zeros or not...

[Marius]

In the latest stable (0.7.3) you can ask for the password to be prefixed with a zero. You need to create a special account for each website that started with 0 in the previous versions.

[Eric H. Jung]

Thanks for the tip, Marius. I haven't forgotten about this problem. It's high on my list of priorities.

[breyed]

It's good to have a work-around available.  Just to be clear, there are a couple of limitations to the workaround of prefixing a 0:

- It's not easy for a user to quickly determine which of all the sites he has accounts with have 0-leading passwords.  So the problem would have to be accounted for on an as-encountered basis - not so easy when you share your computer with your wife who's not quite as techy. :-)

- It doesn't work for the occasional password with multiple leading 0s (should be only 1 in 256, but alas I know I've encountered at least one).

I'm looking forward to the real fix.

[Eric H. Jung]

Hi Ed,

Two questions for you:

1. Is MD5 the only hash algorithm for which you experience the leading zeros problem? Are other algorithms affected?

2. How are you working around the problem today?

Thanks,
Eric

[breyed]

Here are my not-so-interesting answers:

1. I haven't tried with anything except MD5.

2. I've been working around the problem by not upgrading from 0.6.  :rolleyes:

[breyed]

I tested the beta for 0.8.2.  I tried it with two real-world sites that had passwords with leading 0s under 0.6 (all I could find in a reasonably short amount of time).  I also tried several non-leading-0 sites.  All worked fine.  So as far as the bug in this thread is concerned, I'd say 0.8.2 is ready for release... with the one caveat that the web site pw generator should be updated to support the .6 algorithm by release time or shortly thereafter.

Thanks for the fix!  :D

[Eric H. Jung]

Thanks for the testing, Ed! 0.8.2 will be available to the public shortly.