Add a pin/password for each file

[mterron]

Add the possibility to have a password/pin to protect each file.

[pdehaan]

In #384, @danielquinn says:

Password option to allow sharing link over unencrypted networks

The trouble with sharing files like this is that the link will almost certainly be shared over an unencrypted system like email, effectively defeating all of the encryption you've done here. Having an option to require a password to get the file would help with this (assuming of course that the user doesn't share the password over the same insecure channel, but you can't help everybody ;-))

FWIW I have a crude implementation of this in my little Korra project. Working instance is here.

[johngruen]

Asking UX to move forward on this. We should explore whether there are their alternatives to pins that might be more fun/user friendly? Creating a pattern? Taking a picture? etc? Ideas are weclome, though I'm happy to move forward with a simple passprhase input to start.

The user stories:

As a send user concerned about possible MITMs, i would like the option to set a secondary key in order to further restrict access to downloads.

As a Send user interested in a quick and easy way to send files, I do not wish to add a secondary key since doing so would slow down and complicate the file transfer process.

Requirements:

• [ ] It should allow a user to optionally set a secondary key
• [ ] It should measure the rate at which users opt into this flow
• [ ] It should not force users to create a secondary key or materially slow the file sharing process for users who do not wish to create a secondary key

Deployment

• We should do an A/B deployment to 10% of users to help us better reason about the uptake of this feature.

[mterron]

An 8 digit pin is easy to transmit out of band and secure enough as long as you only allow a reasonably low number of retries before deleting the file.

[ehuggett]

Can the user story be adjusted to make it clear they are concerned about the message with the URL being intercepted or observed (this could be email/irc/sms/rfc2549 etc) by a MITM/etc. If an adversary is able to MITM the https connection to Send then they will be able to inject/modify javascript to steal the key and any password/pin the user enters.

Send does not currently require the receiver to prove in any way that they posses the decryption key before allowing them to download the encrypted file and I do not think it would not be possible to meaningfully limit the number of password/pin attempts without (the server requiring this proof from the client). n.b. "proof of secret" does NOT involve sending the secret to the server (and the proof stored by the server would have to be generated by the senders client)

Once filenames are also encrypted #69 , it would (should) be impossible to display the filename without the password/pin (as presumably the password will be used to derive a key that can decrypt the wrapped file encryption key and it looks likely this key will also be used to encrypt the filename).

Korra

So how does this work in Korra? I've had a quick look and, guessing from what i see on the dev tools network tab, the UUID in https://transfer.danielquinn.org/download/ is only made available to client encrypted with the password they have to enter? edit: or not, the UUID does not change when i deliberately enter the wrong password (it fetches the same url every time i get it wrong)

[danielquinn]

Korra is really not that elaborate. The file is symmetrically encrypted with the user's password, so when the user submits a password the server tries to decrypt the file with said password. If it works, you get the file, if it doesn't, you get a fail message.

The assumption in Korra's case is that you control the server (it's meant to be an on-site install), so it can be trusted to do the encryption/decryption. If I understand Send's case, the server doesn't have the ability to decrypt the document, so the password offered by the user would only be able to be used by the client to decrypt the file. In this scenario, the server would have no knowledge if the password was legit or not, only that a user requested the file and that it was delivered.

If you want the server to have some knowledge of whether the password is legit or not, you'd have to store a hash of it server-side and check that before returning the encrypted file.

[youwenliang]

@johngruen Here's a quick mockup for setting password when sending files and entering password for receiving files. Might need to learn more about the implementation in order to make some design decisions.

(6 screens, visual is not final yet) https://mozilla.invisionapp.com/share/Z4CYKA4UY

[youwenliang]

@johngruen

Proposal 1: Add customized password before uploading files: https://mozilla.invisionapp.com/share/4VD1F8WAF

Proposal 2: Use auto-generated decryption key as password: https://mozilla.invisionapp.com/share/YKD1F98RH

[ehuggett]

Proposal 1,

• Its seems very reasonable to "unmask" the password by default (i think this was added after the initial mock-up?). An option to mask the password might be useful in some environments (but most users would probably not require this, depending upon how they share the secret it may be displayed on a screen anyway)

In proposal 2,

• I can't see any harm if the "pointer url" and the "decryption key" switched places. It "feels" wrong to do this, can anyone tell me why? The advantage would be a shorter "password", desirable if they can't copy & paste it to the downloader (separate device or using a telephone etc)

[youwenliang]

@ehuggett For proposal 2 I'm just following the current implementation (short pointer url + long decryption key). This approach is similar to what MEGA(https://mega.nz) uses to protect user's files.

[youwenliang]

Measurements for Proposal 1: https://mozilla.github.io/testpilot-assets/Send/Send_Password_1/

Measurements for Proposal 2: https://mozilla.github.io/testpilot-assets/Send/Send_Password_2/

I think we can either plan for A/B tesing the two proposals or go with Proposal 2 to test out the password idea first.

[sevaan]

I just went through Proposal 1, and it feels awkward to set a password before you upload a file. Shouldn't the password options be on the Copy URL page like the hash stuff in option 2?

Also, the confirmation states when copying the password/hash should be a checkmark, instead of the word "copied" to match the confirmation action when copying the URL.

[youwenliang]

@sevaan Agreed, seems a bit awkward to set a password before uploading. We've talked to John and learned that there might be some feasibility issues if we set the password after uploading.

Anyway, I suggested we can test out option 2 first.

[mterron]

Why don't you generate the pin, no input from the user.

6 digits should be plenty.

On 24/08/2017 2:23 pm, "You-Wen Liang (Mark)" notifications@github.com wrote:

@sevaan https://github.com/sevaan Agreed, seems a bit awkward to set a password before uploading. We've talked to John and learned that there might be some feasibility issues if we set the password after uploading.

Anyway, I suggested we can test out option 2 first.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/mozilla/send/issues/381#issuecomment-324514391, or mute the thread https://github.com/notifications/unsubscribe-auth/AEOr2_AHKS3p4drbYUNF0vcF0nnO-M-rks5sbN6-gaJpZM4OqjCu .

[ehuggett]

I just went through Proposal 1, and it feels awkward to set a password before you upload a file. Shouldn't the password options be on the Copy URL page like the hash stuff in option 2?

If the users password is used as part of the data used to generate/derive the file encryption key this would be a technical requirement, The details ended up being quite long so I've put them here https://gist.github.com/ehuggett/e1e3b4c8f73cd793cfc114c570187212 to keep the noise down a bit

edit: i missed a few comments between loading the page and commenting

[dannycoates]

We've talked to John and learned that there might be some feasibility issues if we set the password after uploading.

Setting the password after upload isn't totally infeasible but would be harder to implement. An option that would not be any harder technically is to set the password after you've selected the file, but before uploading. We could do this with a modal dialog or an intermediate screen.

[sevaan]

Here's another take on separating the decryption key: https://mozilla.invisionapp.com/share/DVD8UDI75#/screens/250844186_Separate_Decryption_Key

On the sender side I downplayed the option since it's more of an advanced feature and added an info tooltip which explains why you might want to do it.

On the receiver side, I removed the image of happy flying file from the view where the receiver has to enter to decryption key, putting the focus on the form field. The image returns if the correct key has been entered.

[sevaan]

Based on a team discussion yesterday I've made the following changes:

• Increased the size of the text next to the checkbox
• Increased size of question mark icon
• Removed hidden characters from decryption key field on download page
• Created second option where info text appears once box is checked
• Second option has a different string for the checkbox
• Updated spec

[sevaan]

After more discussion we are no longer doing split-hash, and instead are doing straight-up password protection. Here are revised mocks of the UX for the sender, and the receiver/downloader.

[ehuggett]

The secret on the URL does not change when the password is updated, implying no key wrapping etc, so the server will have knowledge of the password?

If this is the case, Perhaps the server should specify the password to avoid handling any 'sensitive' information? (no need to have a big collection of password hashes, which unlike the encrypted data is vulnerable to brute force if obtained/stolen)

If the server has knowledge of, and can be responsible for enforcing the password requirement by requesting it from the downloader, then it should delete the encrypted data after too many failed attempts. (show this countdown? it would also be a warning if anyone else has tried to access it)

With a random 7 digit pin number (10 million combinations) per file, and only 3 attempts, I would expect to succeed trying random pin numbers only once every ~3.3 million files I attempted to access? 11 digits would raise that to ~33 billion attempts

I would add an 8th as a Check Digit so that most of the time the downloaders client can tell them they must have typed it incorrectly without using an attempt. Displaying it in groups of 4 would hopefully make it familiar (chip and pin, CC numbers etc) for most users?

(random passwords could be shorter, but profanity would always be a minor risk)

[sevaan]

Updated the UX for the Sender and have removed the edit password feature for now and will save it for later. This keeps it simpler, and I don't think editing passwords will be required much until longer expiry times and multiple downloads are implemented. So consider this MVP for p/ws.

The secret on the URL does not change when the password is updated, implying no key wrapping etc, so the server will have knowledge of the password?

I'm not sure of the implementation with regards to the server knowing it or not so have left that as is until I know more. @dannycoates Could you shed some light?

Good idea about enforcing download attempts.

Displaying it in groups of 4 would hopefully make it familiar (chip and pin, CC numbers etc) for most users?

This is actually a pretty great idea in that grouped numbers could be read to someone verbally.

[sevaan]

This is actually a pretty great idea in that grouped numbers could be read to someone verbally.

However the user would have to share those numbers with someone then and there, or write them down somewhere before leaving that page. Otherwise access to that file could be lost.

I wouldn't want to put the passkey in the list on the homepage for security reasons, unless it's behind an account.

Since a custom password is user-entered, it makes it potentially much easier to memorize, so I could share the link with someone, meet up with them later and recall it.

[ehuggett]

I've given my thoughts on 3 different approaches, I'll try to summarise them concisely (ignoring difficulty and focusing on what is technically possible)

1. the password is used as part of the secret that encrypts the file. The server has no knowledge of the password. This is not possible with the proposed UX, as we don't ask for the password before encrypting the file.
2. the password is used to encrypt the file encryption key, which changes the url when a password is added or when it is changed. The server has no knowledge of the password.

clarification:

The secret on the URL does not change when the password is updated, implying no key wrapping etc, so the server will have knowledge of the password?

What I should have said is: The secret on the URL does not change when a password is set or updated

You can't let the user copy (see) the link before the password is set or changed, or we need to reinforce somehow that they need to copy it again after changing the password or we can't use this method either as the old link would require/work with the old password (too confusing).

3. The server has knowledge of the password. Similar to a temporary account (with the fileid being the username). This allows a short/weak pin or password to be used so long as it is not predictable and the server deletes the data to protect it from unauthorised access after a few failed attempts.

   I wouldn't want to put the passkey in the list on the homepage for security reasons, unless it's behind an account.

Perhaps we shouldn't be leaving the non-password secret links in the browser either? (to display on the homepage). Perhaps it would be reasonable (to store the pin) if

• add an option bulk or individually remove items from the history (without deleting the files), possibly an option to remove only the pin?
• asking the user if they are using a public computer (/if they want the pin to be remembered) would address a more general problem at the same time (and don't store anything at all if they say yes)

If its not a public computer, its very likely the uploaded file is still stored on it (so the history is less of a concern, but certainly not irrelevant).