auth: use keccak256 to derive token

[tomholford]

Context

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 Compatibility" login flow for custodial wallets; when this is enabled, the auth token is derived using sha256 instead of keccak256 to allow users to re-derive deterministic keys

Preview

Legacy Toggle

When Keyfile is Unavailable

Info Modal

Testing

Confirmed using the dev mnemonic on Ropsten.

1. Log in with Recovery Phrase
2. Select ~winnet
3. Navigate to Home > OS, verify that Keyfile is unavailable
4. Logout
5. Log in with Recovery Phrase again, this time with Use Legacy Compatibility enabled
6. Select ~winnet
7. Navigate to Home > OS, verify that Keyfile can be downloaded

[tomholford]

Per out of band conversations with @Fang-, @nerveharp, and @jyng, we've come up with an approach with significantly better UX. Instead of providing the option to the user upon Login, instead at the time of keyfile generation, we will derive tokens using both sha256 and keccak256 and see if either matches the on-chain keys.