Mooltipass freeze for some seconds if credential is not in active category

[rms5566]

Expected behavior

If you set the active category to "work" the mooltipass should not freeze for some seconds if you visit a website where the credentials are saved under no category.

Actual behavior

If you set the active category to "work" or "home" the mooltipass freeze if you visit a website where the credential and username is saved under no category.

Step by step guide to reproduce the problem

1. plug in your smartcard and enter your pin code
2. set the active category to one of your categories
3. visit a website where the credential is not saved in the current active category
4. scroll through the Mooltipass menu and notice that it is stuck at the current menu icon. After 2-3 seconds you're able to scroll again.

Moolticute Version

v0.42.32-testing

DEBUG: (2020-02-25T08:20:04.319) :0 - JSON API recv: {"msg":"ask_password","client_id":83,"data":{"extension_version":"1.0","service":"gitlab.northernroot.net","fallback_service":"northernroot.net","login":"","request_id":82}}
INFO: (2020-02-25T08:20:04.319) :0 - "Get Credential"
DEBUG: (2020-02-25T08:20:04.319) :0 - Platform send command:  "GET_CREDENTIAL (0x0007)"
DEBUG: (2020-02-25T08:20:04.319) :0 - Full packet# 0 :  "[0xb8, 0x00, 0x07, 0x00, 0x34, 0x00, 0x00, 0x00, 0xff, 0xff, 0x67, 0x00, 0x69, 0x00, 0x74, 0x00, 0x6c, 0x00, 0x61, 0x00, 0x62, 0x00, 0x2e, 0x00, 0x6e, 0x00, 0x6f, 0x00, 0x72, 0x00, 0x74, 0x00, 0x68, 0x00, 0x65, 0x00, 0x72, 0x00, 0x6e, 0x00, 0x72, 0x00, 0x6f, 0x00, 0x6f, 0x00, 0x74, 0x00, 0x2e, 0x00, 0x6e, 0x00, 0x65, 0x00, 0x74, 0x00, 0x00, 0x00]"
DEBUG: (2020-02-25T08:20:06.619) :0 - Message payload length: 0
DEBUG: (2020-02-25T08:20:06.619) :0 - "Received answer: GET_CREDENTIAL (0x0007)"  Full packet: "04000700000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"
DEBUG: (2020-02-25T08:20:06.619) :0 - Platform send command:  "GET_CREDENTIAL (0x0007)"
DEBUG: (2020-02-25T08:20:06.620) :0 - Full packet# 0 :  "[0x2a, 0x00, 0x07, 0x00, 0x26, 0x00, 0x00, 0x00, 0xff, 0xff, 0x6e, 0x00, 0x6f, 0x00, 0x72, 0x00, 0x74, 0x00, 0x68, 0x00, 0x65, 0x00, 0x72, 0x00, 0x6e, 0x00, 0x72, 0x00, 0x6f, 0x00, 0x6f, 0x00, 0x74, 0x00, 0x2e, 0x00, 0x6e, 0x00, 0x65, 0x00, 0x74, 0x00, 0x00, 0x00]"
DEBUG: (2020-02-25T08:20:09.073) :0 - Message payload length: 0
DEBUG: (2020-02-25T08:20:09.073) :0 - "Received answer: GET_CREDENTIAL (0x0007)"  Full packet: "04000700000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"
WARNING: (2020-02-25T08:20:09.073) :0 - Credential get for fallback service failed

Firmware Version

AUX MCU version: 0.13 Main MCU version: 0.18

Operating System

• Windows 10 2016 LTSB

[rms5566]

Same problem occurs if you deny a credential recall. It does not happen if you accept a credential during recall

[limpkin]

Wow, I'm impressed you managed to find that issue.
This is actually by design to prevent random probing for credentials existence (https://github.com/mooltipass/minible/blob/master/source_code/main_mcu/src/LOGIC/logic_user.c#L662) . In short, for every website you visit with a login request is made to the device. If the device doesn't have any credential for the website (and therefore can't prompt the user), it doesn't answer right away and waits for a random time to simulate the case where the user would deny the prompt.
If that becomes too much of an annoyance I can definitely tweak that code / remove the random delays....

[rms5566]

So if it has a purpose it should not be removed. It is okay like it is now.

[limpkin]

the purpose is debatable... we'll see if people are annoyed by it :)

[elendil-software]

I have a suggestion : Instead of delaying every time, do it only if there are several attempts in a short span time. A bit like some forums do in their search function, if you do several search you have to wait before trying again.

Regards,

Julien

[limpkin]

great idea! edit: though for this kind of attack it wouldn't be an issue for an attacker to wait a minute between attempts...

[mario-oberwalder]

Can you display an explanation on the device so the user knows whats going on?