Importing passwords back to the Mini truncates them to 16 characters

[limpkin]

This is not a bug report per say, but an explanation for people wondering about this potentially frustrating limitation.

Mooltipass Mini Password Field
The Mooltipass Mini password field is 32 bytes long: https://github.com/limpkin/mooltipass/blob/master/source_code/src/NODEMGMT/node_mgmt.h#L163
As the Mooltipass Mini only supports ASCII, that effectively means the maximum password size supported by the Mini is 31 ASCII characters + 1 terminating 0.

Mooltipass Mini BLE Password Field
The Mooltipass Mini BLE password field is 128 bytes long: https://github.com/mooltipass/minible/blob/master/source_code/main_mcu/src/NODEMGMT/nodemgmt.h#L172
As the Mooltipass Mini BLE supports BMP characters (stored on 2 bytes), that effectively means the maximum password size supported is 64 BMP unicode characters (terminating 0 is in the struct).

The Issue
As the password field is encrypted it is impossible to modify it when transferring it across devices. When transferring the password field from the Mini BLE to the Mini, 32 bytes out of the 128 are transferred. However, as the Mini BLE uses Unicode BMP (2 bytes per char) to store characters, that effectively means that only 16 characters for a given password can be stored on the Mini

[rms5566]

You could split the password and create two entry's on the mini. Of cause we would have problems with special characters but the password length is still valid. Example:

Mini BLE Superduperwebsite -> PW: Thisisaverylongpassword

Mini Superduperwebsite1/2 -> PW: Thisisaverylong

Superduperwebsite2/2 -> PW: password

Maybe you could connect this two entry's with Moolticute but it is saved as two different passwords in the database. But I don't know if you want to rework the whole mini.

[limpkin]

that could be an option indeed!

[alanrick]

I want to keep using my mini even when I receive my miniBLE and I hope to keep them in sync. I have many passwords in my mini longer than 16 chars and I want to continue that way. I understand the value in supporting BMP so that other languages can be used. However I’d like my miniBLE to run in compatibility mode requiring password-entering to be restricted to 31 chars and requiring databases to be exchanged between devices without truncation, and limiting character-entry to ascii chars.

Theoretically such a compatibility flag would need to be offered at the dB level, but I’d be content if it was offered at the device level.

Surely that’s possible without splitting the passwords into two?

If @ThunderKing54 suggestion was used instead and the two halves were concatenated in the Moolticute UI and chrome autofill I could live with halving the max number of passwords stored.

[egalanos]

What's the benefit of switching to BMP rather than UTF8 and maintaining compatibility with the mini?

[limpkin]

@egalanos in short: to keep things simple and minimize the potential security risks. The mini actually uses chars above 128 so there would have been some issues in any case. @alanrick your proposition is interesting. I could imagine setting the mini BLE in a special mode forcing password storage in ascii so we could import to the mini as is. How would you imagine setting that special mode?

[alanrick]

Yes, I would definitely use ascii. 16 chars is too short for many of my passwords and I’d like to use the BLE in conjunction with my existing MINI (backup, home use....).

[limpkin]

how would imagine setting up the mini BLE in this special mode? on moolticute?

[alanrick]

a) A combo box in the password profiles form (Moolticute settings) which is disabled once an entry exists in the database.
b) A combo box In the synchronization form. I'm not sure if you can add a flag in the header of the export file so that exported BMP database can be distinguished from ASCII. That would be the best-case scenario, that would automatically set the (virgin) database to ASCII when importing files from the mini.

Reason... password files are not synched between the users. I don't even think the import is used to merge databases. So either it's someone importing from a mini into BLE (retain ASCII), or someone who doesn't have a mini who's importing from another BLE and is happy to keep using BMP. BTW: Common password generators have over 16 as a default (e.g. https://my.norton.com/extspa/passwordmanager) so I do think this will be widely used.

[limpkin]

So I gave this issue another look and came to the conclusion that we can't store passwords in the old database format inside the mini BLE without creating security issues (old gen XORs IV while new gen ADDs IV, which could lead to the same CTR value being used). I'll keep thinking about it, but I think we'll have to split the credential in two...

[alanrick]

Will there be a database setting for the BLE stipulating max password length? Even if there’s no workaround to the max of 16 chars, I’d be keen on preventing creating new passwords on the BLE which couldn’t be transferred to the Mini. E.g. Max=16 or Max=32 or Max=128 for non-Mini users.

[kbembedded]

I'd love to continue using my mini as a backup. If it helps the cause, I would be satisfied if the password was broken in to two fields since it would be a worse case scenario backup.

[CGuy-1]

Two years on and I'm surprised one solution wasn't suggested. In Moolticute, save the DB in Mini compatible mode that Mini can upload. This would just need going from BMP characters to ASCII. Any characters that can't be converted could be flagged in a report or just which credential failed to be converted. Same thing to import from Mini, it would go through the translation step.

I think way back that there was an option to save in Mini format but I don't see it any more.

[limpkin]

I'm afraid we do have limited resources.... and we were hoping to count more on contributors