Identifying as dapp instead of as Status when in a dapp

Right now if you use Status to access a dapp like Cent which needs login information, you get offered autofill from password managers on most devices. However, Status still identifies as Status to the password manager, even if context is changed to the dapp, which means the password manager will offer the password for Status (if any) and not for the dapp itself.

This is a UX breaker and hugely impractical, especially since login cookies seem to be lost after every Status restart, and Status itself crashes with Java exceptions every time the phone falls asleep long enough to dump the cache of the app. This means that roughly every 5 minutes, a Status user (on Android at least) needs to full re-login into Status, then navigate to the dapp, wait for it to load (why no PWA manifest and offline cache for assets?), then log in there. That’s two times a user has to manually enter a password, unless the main one is in the password manager which slightly reduces friction there.

I propose the following 10x UX improvements, apart from fingerprint logins which are already planned:

  • remember dapp cookies indefinitely (as long as they’re set to be remembered rather than the custom duration imposed by Status) per user account in Status. Encrypt cookies with private key and wipe on logout. Decrypt and auto-apply on logging in again with same identity. This makes it possible for two identities to use two accounts of the same dapp on the same device without constantly having to log in and out of everything.
  • expose dapp URL to the password manager, not the app name (Status). See how normal browsers do it.

ooh. we have a chance to split from the insanely insecure practice of sending the cleartext password to the server that verifies it … why not something radical, like banning password fields in dapps and requiring Password-authenticated key agreement - Wikipedia

@Bruno Do you have any insight why the identification is performed incorrectly in password manager? What password manager specifically.

As a side note, some DApps leverage ethereum signing for identification e.g. peepeth

Lastpass in my case. The autofill context auto-infers from app name currently. This is natural on the login screen, but should be customized in the dapp browser.

As a side note, some DApps leverage ethereum signing for identification e.g. peepeth

Sure, but most don’t and won’t for a long time to come, not least because it’s not exactly easy to port a wallet from Status to desktop (web) and therefore people have different Eth identities associated with the same account (Cent + Status vs Cent + MetaMask). I don’t know how to make it easier to port while keeping things secure so I think a better autofill context would improve things.

To reproduce the issue, register an account on Cent and test autofill out on the latest iOS and Android.

1 Like