This PR re-opens #984. After the initial review, we decided to explore an alternative solution (see: #1000). Unfortunately, that approach ended up not being feasible. So, here we are again :) Although the UX is not ideal, it stops the bleeding and provides a suitable fix for now. Eventually, we plan to split Bridge into separate apps, and can rethink this design when the time comes.
See the recent comments in #549 for details, but in short:
This commit introduced a discrepancy between how auth tokens are generated between custodial and non-custodial wallets. Specifically, per the docs for personal_sign, keccak256 is used by Ethereum Providers to sign a message.
When I first joined the Bridge project and had little insight into how things worked, I instead used the subtly different sha256 for the default auth token case (i.e, for master tickets and mnemonics). As such, for roughly the past 6 months, any actions performed in Bridge (generating invites, setting keys, etc) using these login methods were with a logically incorrect auth token.
Changes
This resolves #549 by:
using keccak256 for default auth token derivation
adding a "Legacy Token" login flow for custodial wallets (Master Ticket or Recovery Phrase); when this is enabled, the auth token is derived using sha256 instead of keccak256 to allow users to re-derive deterministic keys and view unclaimed invites created with the previous token algorithm
Preview
Legacy Toggle
When Keyfile is Unavailable
Info Modal
Testing
Confirmed using the dev mnemonic on Ropsten.
Log in with Recovery Phrase
Select ~winnet
Navigate to Home > OS, verify that Keyfile is unavailable
Logout
Log in with Recovery Phrase again, this time with Use Legacy Token enabled
Select ~winnet
Navigate to Home > OS, verify that Keyfile can be downloaded
Context
This PR re-opens #984. After the initial review, we decided to explore an alternative solution (see: #1000). Unfortunately, that approach ended up not being feasible. So, here we are again :) Although the UX is not ideal, it stops the bleeding and provides a suitable fix for now. Eventually, we plan to split Bridge into separate apps, and can rethink this design when the time comes.
See the recent comments in #549 for details, but in short:
This commit introduced a discrepancy between how auth tokens are generated between custodial and non-custodial wallets. Specifically, per the docs for
personal_sign,keccak256is used by Ethereum Providers to sign a message.When I first joined the Bridge project and had little insight into how things worked, I instead used the subtly different
sha256for the default auth token case (i.e, for master tickets and mnemonics). As such, for roughly the past 6 months, any actions performed in Bridge (generating invites, setting keys, etc) using these login methods were with a logically incorrect auth token.Changes
This resolves #549 by:
keccak256for default auth token derivationsha256instead ofkeccak256to allow users to re-derive deterministic keys and view unclaimed invites created with the previous token algorithmPreview
Legacy Toggle
When Keyfile is Unavailable
Info Modal
Testing
Confirmed using the dev mnemonic on Ropsten.