UI design: Passphrase disclosure risk when configuring sharing

[candlerb]

ISSUE NAME

• Passbolt Version: v2.0.7
• Platform and Target: -- Operating system: Ubuntu 16.04.5 LTS -- PHP: 7.0.32-0ubuntu0.16.04.1 -- Web server: apache 2.4.18-2ubuntu3.9 -- Database server: mysql 5.7.25-0ubuntu0.16.04.2

What you did

• Create a new password
• Open "Shared with" and click the Edit (pencil) icon

Note that at this point, the "Share with people or groups" data entry box looks exactly like a passphrase entry box: it has the three-letter security token in the security token colour. Furthermore, if you type anything into the box, and backspace it again, the entire background colour of this box changes to the security token colour.

• Type a partial user or group name, select them, add to sharing
• The "Share with..." box is still there, inviting you to add another sharing user.

At this point, I knew that the sharing wouldn't be activated until I'd confirmed with my passphrase. But instead of clicking Save, I started to enter my passphrase into the Share with... box!

I realised quickly, but it was too late.

Since Passbolt sends what you type to the server as you type it (to offer matching users and groups), a chunk of my passphrase ended up in Apache logs.

What happened

These messages ended up in the Apache access log file:

x.x.x.x - - [05/Feb/2019:10:03:50 +0000] "GET
/share/search-users/resource/e44760f2-0d6c-4dce-91fb-b7969a7f1439?api-version=2&filter%5Bsearch%5D=BL HTTP/1.1" 200 2072 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36"
x.x.x.x - - [05/Feb/2019:10:03:50 +0000] "GET
/share/search-users/resource/e44760f2-0d6c-4dce-91fb-b7969a7f1439?api-version=2&filter%5Bsearch%5D=BLAH1234 HTTP/1.1" 200 2072 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36"

where BL, BLAH1234 were parts of my passphrase

What you expected to happen

I see two issues here.

1. Clearly I was not reading the screen carefully (it says "You need to save to apply the changes"), but I also think that this is poor user interface design. It was the visual cue of the coloured and token-tagged box which triggered me to start entering the passphrase.

   I think that the security token and colour should only be shown when prompting for your passphrase (especially if it could be logged as you type).

2. The typing was logged. For general privacy, I propose that search-as-you-type should be POST rather than GET.

To be fair, the FAQ says:

This cue will be shown whenever we ask you for your master password and other sensitive places to help make sure you are dealing with an authentic passbolt dialog and not a fake one!

[my emphasis]

So the question is whether prompting for a username or group to share with counts as a "sensitive place". I would argue it isn't: it only results in Passbolt offering you potential matches, which you always select from a drop-down. If anyone could MITM at this point, they have your whole session anyway. Furthermore, you're required to confirm with Save (and then your passphrase) before any change to sharing is applied.

[stripthis]

I discussed it with the team, it makes sense to remove the security token there.

[stripthis]

Fixed with v2.13.