issue #302; passwords generated differ from different MPW versions
It would be useful to see milestones, weight and timelines attached to this git issue, which is correctly tagged as category-critical
The underlying fault completely undermines this promise from the MPW site "Even if a personal or natural catastrophe causes you loss, you can never lose your account passwords — all you ever need is your one and only secret master password and anyone's Master Password calculator app." For this to remain valid, anyone's MPWapp must be the same as anyone else's MPWapp. With different versions of MPW generating different passwords this is clearly not the case.
This issue needs a fix ASAP. The location of this fix in the commit tree will identify the versions affected by the issue. These must be documented to the help pages. That's the easy bit.
Resolving the discrepancy among all the installed versions is considerably more challenging. Ideally every user of MPW would be alerted to the issue, but I suspect that is not possible. A suitable workaround would be to highlight the divergence point and to recommend that users of earlier versions upgrade. The earlier versions could perhaps be 'earlier development versions'. Early adopters would not ordinarily be expected to see that message. However, many early adopters (myself included) recommend MPW, and a suitably prominent notification would be a step in the right direction.
The testsuite going forward needs to include verification of password continuity.
The original issue was acknowledged on the helpdesk immediately (July 16th). Git issue #302 was subsequently logged. On August 24th user Bruno highlighted the significance of this issue. Bruno has a point but over-reacts. MPW is the best currently available solution to an otherwise trying issue. I will continue to use it. And I will continue to recommend it to others once this issue is fixed and communicated. The capabities of the author Maarten Billemont are beyond doubt considerable. These need simply to be applied to resolving this issue as a priority. I look forward to seeing issue resolution in a timely manner.
Best Regards
Keyboard shortcuts
Generic
| ? | Show this help |
|---|---|
| ESC | Blurs the current field |
Comment Form
| r | Focus the comment reply box |
|---|---|
| ^ + ↩ | Submit the comment |
You can use Command ⌘ instead of Control ^ on Mac
Support Staff 1 Posted by Maarten Billemo... on 21 Sep, 2019 03:32 AM
It's important to note that though this distinction is troubling, it only exists on algorithm versions < 3. If all apps are updated to use the current version of the algorithm, they should all agree on the generated password. In this case, the output password for V3 is:
Darv8^CukeZaxf, on all devices.I will conduct a full analysis of the problem in #302, but for now, my advice is, always ensure you are on the latest algorithm version.
V0 has a bug in it that causes the algorithm's result to be platform/architecture dependent (more specifically, it performed math on bytes whose numerical value's signedness depends on the platform, thereby resulting on some platforms treating the byte as a positive integer and other platforms treating it as a full integer, yielding different numerical values).
Thank you for your commitment to this issue and the app, Mat.
Support Staff 2 Posted by Maarten Billemo... on 27 Sep, 2019 02:25 PM
To address the additional concerns raised here:
It is certainly true that for MPW to maintain its relevance, it is absolutely critical that it is universally trustworthy and will generate the correct output on any platform at any time.
Since the underlying fault is limited to the obsolete V0 algorithm, however, and the current V3 algorithm does not exhibit the issue anymore (it was fixed for V1), I would posit that MPW's promise remains intact, though it becomes necessary for people to migrate their V0 passwords over to V3.
This issue was fixed in V1, which was committed to the tree here:
Every app released since then has had support for the fixed algorithms and backwards-compatible support for the old algorithm to enable migration.Correct. I do not hold any records on users.
This is what the iOS app does (should do), though admittedly the other apps could do a better job of making the need to upgrade from V0 clear.
The test suite tests all algorithms, including V0, for all known edge cases, including this one. The test suite is not currently run against a variety of architectures. I can look into this.
Any additional feedback / thoughts & recommendations are more than welcome. Thank you for your support and endorsement - they are invaluable to the cause.
Maarten Billemont closed this discussion on 27 Sep, 2019 02:25 PM.
Matthew Goulden re-opened this discussion on 27 Sep, 2019 02:39 PM
3 Posted by Matthew Goulden on 27 Sep, 2019 02:39 PM
Maarten,
Thank you for this clarification. If the V0 algorithm is fundamentally flawed perhaps it ought to be clearly flagged as obsolete/deprecated and for removal from versions going forward? You mention V3 as free of this glitch. What is the status of V2?
Best regards
-- Matthew
________________________________
Support Staff 4 Posted by Maarten Billemo... on 27 Sep, 2019 02:45 PM
Well, it's important to recognize that a new algorithm only exists because there is some issue with a previous version that was addressed. V0, V1, and V2 are certainly obsolete, every app defaults new users to V3. The other algorithm versions continue to be supported to allow users the freedom to look up old passwords should it become necessary. The apps will perpetually include support for the old versions for this reason - ie. V0 will never be removed.
The flaws in the previous algorithms are described here:
https://gitlab.com/MasterPassword/MasterPassword/blob/rewrite/platf...
V1 and V2 had issues with multi-byte unicode characters in names (eg. the person's full name or the site's name).