[Feature] Backing up Seed with Cloud Storage connect

#1

The use case

As a user, I want to have a more convinced and familiar way to backup and restore my key.

Prototype: "SimpleBackup"

https://projects.invisionapp.com/m/share/2TUNC3TRQEN#/391282255

For this feature, you can backup your seed phrase by connecting to 2 to 5 different cloud storage services. If you need to recover the Wallet, you log in again to these services from your wallet and it will restore.

.

Seed phrase wallet backups can be done in several ways, including "paper backup", metal backup, writing down on a text.doc on the device. These options will range from insecure, a hassle, or expensive. And generally, follow an unfamiliar use pattern for most people.

The advantage we want to convey is letting users deal with a familiar interface (password) in a trusted context (reliable storage services), with less hassle. The seed phrase is encrypted and split across different storage services, keeping it secure.

.

What are your first thoughts?

How do you backup your seed or wallet right now, and how does this compare to you?

26 29 30 33

#2

Victor asked: if there is such a feature, would I use it.

I'm not the target persona, so I do not participate prioritization. It's all Zaki/Victor/Lucas if you guys put it on the pipeline I'm okay. Personally, if this feature is there, I would forego it for the seed, so when something goes wrong, I don't have too many things to suspect.

Let me tell a story: my parents kept asking me to use their credit card in China, so I don't have to spend AUD when traveling in China and bare the exchange cost. I kept saying "no", because, if I never knew their credit card, when there is a fraud it couldn't have leaked from me. Scams often target ageing parents like mine, so I can't let my parents confuse a fraudulent transaction with my spending. In the same manner, I don't want to need to question if a cloud account is the source of trouble, if I discover my money is leaking.

Now that is just my personal feedback. If I put on the hat of a security guy, whether or not I use it depends on the security of the cloud. The encrypted backup on the cloud server is protected mostly by the cloud, not by the password used to encrypt the backup. The reason is that if you have the encrypted backup, you can hire the best computer to crack it 1-million attempts a second. But if you don't have the cloud account access, you can try 3 times then the cloud will block your IP address. Zaki is aware of this for his design decision-making. e.g.

  • whether or not to inform the user that they need secure cloud access more than they need secure encryption on the seeds. or
  • whether or not to make the number of rounds of hash to apply to the passsword adjustable.
#3

For context, I saw this on twitter and wanna comment because i've been working on solving this before.

As a user

@hellolucas You may wanna specify who the user and the situation is exactly. Eg. when I read about this, I first thought of onboarding some no-coin stranger in a bar to Ethereum. And for this case, I think a cloud backup is perfect.

Basically let the user login with google. Then after they have more than $50 in the address, you prompt them to do a hardware backup.

Against this, WeiWu had a good point on Telegram. That you want to transfer funds to a new account, instead of a hardware backup of the first one. Because google/the attacker always has a copy of your keys.

And at this point I'd argue that a contract wallet is way better for this flow, vs a normal wallet. As you can open a lower-level address for the first-time user and keep an admin address with the privilege to move funds in a multisig.

The new Dharma is a good example of this. And it's arguably better UX than login with google. https://github.com/dharma-eng/dharma-smart-wallet#summary

#4

@seichris about the user, you have the right idea. The issue here is one familiarity, and the user is someone who finds learning about seed-phrase backups overwhelming and unfamiliar... so that he can fall back on passwords and familiar services.

For users who are familiar with crypto, it's for those that don't want to go to extremes on security or wants less hassle than paper backups. There is a large sub-set who keep their assets centralized, and they would likely be comfortable with the idea as well.

Preliminary feedback from a telegram chat:

User A keeps his assets on CEX only had a hard time understanding the feature at first - he believed it easier, although also insecure "what if my dropbox gets hacked?". Once explained that it works by splitting across services, he found it complicated because he needs to sign up for each storage.

Progressive security is definitely a solution to onboarding.

1 Like
#5

  1. 'Someone who finds learning about seed-phrase backups overwhelming and unfamiliar' are 99% of humans.

  2. Users who have crypto, but keep it on exchanges. They arguably got fucked a bunch of times already in CEX history. If you understand your responsibility in keeping funds secure and the scam potential of exchanges, you are not very smart to keep funds with that entity.

  3. Why not concentrate on people in your local environment. Friends and strangers alike. The guy you meet at a restaurant, who is curious, but never really digged crypto. Or your friend who works at a web2 fintech company - who got the knowledge, but needs to be pushed a bit into crypto.

Build for them. Ask them which flow they are used to. They are 99% of people and they will have different opinions, different preferences.

And that's exactly the value in Open Source, in Ethereum, and in Token Script. It's whitelabel up to the UI. It never been easier for end-users to build their own UI. Because the basics just get auto generated.

Eg. you onboard that guy at the bbq restaurant. You send him a bit of ETH for gas, some DAI and an NFT, which represents 1 work-hour from you. He scans your QR code and has the funds in his webwallet in his mobile chrome. No downloads. No hassle. He needs no backup, because the gnosis onboarding contract allows you to admin his funds for 3 days. ...

#6

... point being, ask your friends about google cloud backups. Not this forum and not crypto twitter.

Build alpha for the other 99%

#7

@seichris thank you for the feedback!

Exactly :sweat_smile: At first look, it's a general use case. The remainder % being crypto users && have backed up a seed phrase before. But...

We've also been testing with these users, by getting them to go through the prototype and the current AW seed backup flow face-to-face. So it expands on the above hypothesis:

Who is this for?

  • Users who prefer to deal with familiar security protocols (vs seed phrases)
  • Users who do not onboard crypto because seed phrases can be confusing
  • Users who are not overly concerned about security (trust storages)
  • Users who do not want to do physical backups

Who is this not for?

  • Security-minded crypto users who prefer strong methods
  • Users who prefer physical methods to back up

Some feedback so far:

  • I don't remember my login passwords like that (4/5)
  • I don’t really understand it... Key concerns: (3/5)
    • "What if they hack dropbox?"
    • "Doesn't google keep my information?"
  • [once they do understand it] Ok, it's secure… but...
    • Feels less secure, I would still write it down on paper (2/5)
    • Seems like a hassle (to login to my services) (2/5)
  • “I understand it, I would use it” [1/5 mention, non-security focused user] (1/5)

So as it stands for users who have used crypto but are not deep into it, the feature can be difficult to understand. And carries concerns from "Cloud use" after understanding. Complicated to re-login services.

Thoughts? Still testing for more casual users.

#8

53

@hboon Coinbase doing simple iCloud backup as an option — thoughts on the security/UX trade-off?

#9

It's good for small value accounts but definitely wouldn't trust for anything more than 2 or 3 eth, as I'm trusting someone else's system that hasn't been cleverly hacked yet.

#10

Some observations and thoughts:

  1. I observe that banking apps I have seen don't seem to store the user's password on iCloud
  2. Apple provides API to save passwords/secrets to the keychain (which is by itself secure) with an additional flag that makes the data not be saved to iCloud (they default to sync with iCloud). This implies, by design, there are secrets that shouldn't be saved to the iCloud Keychain, which is encrypted and not viewer even by employees.
  3. The difference between a banking app password and a private key/seed phrase is the former (A) can be changed and (B) to a certain extent, you have central parties (bank and police) to go to fix it if you lose funds.
  4. Apple has lost data on iCloud before. Most recently from Apple Mail bugs when upgrading from macOS Mojave to Catalina. Note that keychain data is also stored on iCloud, but it is more secure
  5. When Coinbase announced this feature, there was some users complaining about it on technical grounds. I don't know if that is representative, but user perception is also important. https://thenextweb.com/hardfork/2019/02/13/coinbase-cryptocurrency-google-icloud/
  6. Backing up to iCloud effectively lowers the security of the seed phrase to just the iCloud user + password + 2 factor. Apple still supports 2 factor via SMS (they call it two-step verification, vs their more modern 2fa which requires multiple devices), so such iCloud accounts can be hacked remotely without stealing any of your device.

On the other hand, we are a small startup and we don't have to be the market (thought) leader in every aspect especially as this can be made optional for users and improves user experience.

From the screenshot, it might be that the user can only back up to iCloud or manual (or maybe not). I think if we support backing up to the cloud, we should make it clear they can all be used together. Preferably back up to iCloud is a switch rather than a button. If we can stick to just iCloud for iOS [1], there's no user configuration and it'll be easier to restore from transparently. Setting up a back up is just flicking the switch and restoring is just a prompt with an address or list of addresses.

[1] Might be a few more options and screens for Android, but might be a good place for some considered inconsistency

#11

I forgot to mention, a few months ago, we made the way we handle keys and seed phrases as secure as the OS and hardware allows on both Android and iOS. We didn't quite market it. Depending on whether we decide to support cloud backups, we might do better with marketing how secure we have made it?

#12

Ok, nice that you did user research. How many user did you ask?

It's not much learnings in there. You know, if I ask 10 random out of my friends they answer the same. Its like median vs arithmetic mean.

You may want to define certain personas. Characters of the users you are interested in. Don't categorize them by their problems, because they have different motivations. Once you set them, they follow a path and give you answers for another problem you wanna solve.

It's also a question about your business model. Which guys you actually want to make money from. Which is not clear to me atm.

@JamesB 100% agree from my perspective. But what's Alpha Wallets VIP user's perspective?

@hboon makes sense. Summarizing:

  • can't trust the cloud provider
  • difference to web2 = attacker gets access to private key = fucked
  • local backup is as secure as the attacker/ex-girlfriend stealing your phone

So my learnings:

  1. personas for user testing. start with you / your friends / VIPs
  2. the power of ethereum & especially token script is that the 'sender' can serve UI. "A onboards B. A can propose that B needs web2 onboarding"
  3. test different flows. A/B test. look at the data
  4. speak to other wallet teams. they all got the same problems