[Zashi-iOS audit] Issue E: Copying of the seed phrase should be discouraged

[daira]

From @defuse's draft report:

Severity: Medium

Zashi allows users to copy their seed phrase to the device’s general pasteboard.
On iOS, applications must request access to the general pasteboard to be able to read the contents there. However, after that permission has been granted to an app, it can access the pasteboard without notifying the user. If the user copies their seed phrase and then opens a malicious app which they’ve previously granted permission to access the pasteboard, it could steal their seed phrase.
Outright removing the ability to copy the seed phrase might discourage users from backing up their seed phrase in the way that they desire, which would create another kind of risk of losing funds.
Instead, I recommend warning users about the risks before they copy their seed phrase. An expiration time should also be set on the pasteboard when the seed phrase is copied, so that the seed phrase does not remain on the pasteboard indefinitely. This can be done through the options argument to UIPasteboard.setItems().

[LukasKorba]

@daira @true-jared

There are few things we can do or at least we can take into considreation:

• we should show an alertView with a warning, something like Recovery phrase has been copied but the copy will expire in x minutes/seconds.
• the copy can be set to expire, I need you to tell me how much time is enough. 30 seconds or 2 minutes or anything else?
• IMPORTANT behaviour to know.. by default every copy is globally accessible. Meaning I copy on an iPhone and can paste on a macbook for example. This behaviour can be turned off so the copy is always and only available at the same device. Typical iOS/Apple user is used to ecosystem features like continuity, so copying on one device and pasting somewhere else is very common. There's a downside though! If we set an expiry time and a user pastes on an another device, the copy will stay available on that device even after expired time!!!

here are the scenarios for 10s expiryTime being set:

1. a user copies but does nothing for 11s, pasting is not available on the same device, pasting anywhere lese does nothing (OK for us)
2. a user copies and pastes after 5s on the same device, tries to paste at 12s mark on another device - it does nothing (OK for us)
3. a user copies and pastes after 5s on the same device, tries to paste at 12s mark on the same device , the past is not available (OK for us)
4. a user copies and pastes after 5s on another device, from now on, the paste will be always available on that device even after 10s mark (the copy is copied on that device so it's a different instance of pasteboard) (BAD for us)

Possible solution is to set another key called localOnly which prevents from pasting anywhere else.

I see 2 problems with this approach

1. it's something user doesn't expect becuase continuity works out of the box, we could educate a user upfront in the alertView, but read point 2
2. a user can paste the seed to any place on the same device and copy it again, this time the paste will be available anywhere anytime. That basically fully breaks what we were trying to fix

I see only 1 fully functional solution and that is to never let users to copy the seed. Actually it wasn't in the Figma design, Honza put it there with no discussion in the team. So I put it there as well, we might reconsider this.

[true-jared]

Thanks for describing the scenarios for us @LukasKorba ! This seems like a good candidate to discuss tomorrow at the Zashi team call once we have the whole team on?

[pacu]

Very well explained Lukas!

I've read research about this and it sheds some light on this kind of trade-offs.

Most probably users will make mistakes that will lead to loss-of-funds errors. Copy to clipboard is the easiest to develop and more effortless way for users to quickly get started and having some sort of backup quickly.

A less secure backup is probably better than having no backup at all given the probabilities of each scenario to happen.

see:
http://www.florian-alt.org/unibw/wp-content/publications/froehlich2020dis.pdf

Krombholz et al. found that 22.5% of their sample had lost
cryptocurrencies. Of these incidents, 43.2% were account to
the fault of the user, 26.5% to a hardware failure, 24.4% to
a software failure and 18% to security breaches [37]. The
questions on how to best secure crypto assets and minimize
the risk of losing them are therefore vivid discussion points.
[..] listed security breaches as the least
common reason of Bitcoin loss. Bitcoin loss was caused by
user mistakes twice as often as by security breaches [37].

Cited paper is:

Katharina Krombholz, Aljosha Judmayer, Matthias
Gusenbauer, and Edgar Weippl. 2017. The other side of
the coin: User experiences with bitcoin security and
privacy. Lecture Notes in Computer Science (including
subseries Lecture Notes in Artificial Intelligence and
Lecture Notes in Bioinformatics) 9603 LNCS (2017),
555–580. DOI:
http://dx.doi.org/10.1007/978-3-662-54970-4_33