Interesting reminder how security is holistic: it includes cryptography, protocols, clients, user flows, habits, etc. A system is only as secure as its weakest link.
A thread on key management in @zksync, dangers of pwd-protected wallets, and what's wrong with Ledger 👇
A thread on key management in @zksync, dangers of pwd-protected wallets, and what's wrong with Ledger 👇
Passwords are notoriously unsecure because most ppl don't care to diversify them across different services – it's just too hard. Hackers posses over half a billion of compromised pwds linked to user identities: haveibeenpwned.com/Passwords
So even if your service handles passwords properly (salted multi-round PBDKF2, etc), your users are still vulnerable to phishing and hacks on other less secure websites they use. Countless hacks on the highest-profile targets serve as a proof.
Thus, with large enough user base you must count on having lots of users with weak or compromised passwords. And with the current situation in blockchain privacy, it's just a matter of skill to link identities of some of them to their Ethereum addresses.
The only proper way to handle the login problem is cryptographically strong secrets that never leave the user device. Good examples are 2FA authenticator apps and hardware keys. They really work.
But that only works for login to servers! If you store private keys of your users on the server, you make them vulnerable: no one's opsec is perfect. Even Swiss banks get hacked. And encrypting keys with passwords won't help for reasons explained above.
Therefore, private keys should never leave user's device, which should be well protected. But I don't mean only the protection of the key itself. You need a protected UI which is aware of your protocol.
Consider using a @Ledger Nano wallet to sign a transaction for @gnosisSafe. You will see something like this: 
Fantastic! That made me feel safe! Now I know for sure I'm not sending all my precious tokens to the attacker who hijacked the gnosis-safe.io website!
@metamask_io with structured signatures support (EIP712) is not extraordinary helpful either: am I sending 0.01 ETH or 1000 ETH? Answer quickly!
Also notice the truncated recipient address: it's not scrollable. An attacker who hijacked a dapp website can generate a vanity address prefixed 0xdEbb6c... and most users won't notice, because they only quickly check the beginning and the end of the address (if it all).
Conclusion so far: your dapp is only as secure as its user-facing edges. So one way to increase security is to increase the number of edges that an attacker would have to break. For example, you can use a multisig with multiple wallets from different vendors:
But @zksync, just like @loopringorg and @StarkWareLtd, faces a deeper problem: we need to use a new ZKP-friendly signature scheme which is not yet supported by most wallets. How to handle this in the most secure and user-friendly way?
One simple solution is to derive our ZKP-friendly private key from the Ethereum account via signature:
The sha256 (or another pseudorandom hash) is important from the cryptanalytic perspective: signatures are elliptic curve points, so we need break any potential relation between the two keys.
The text is also important and serves two purposes: 1) domain separation between apps, 2) protect the user from being tricked into leaking the key to an attacker.
This is indeed how we do it in @zksync:
But now the key is in the js memory of the browser. If someone hijacked the zksync.io website, they would gain full access. (And remember: Google, Cloudflare plus a bunch of other organisations hold root-level SSL certificates; what if those are leaked?!)
As I said before, the proper solution is to integrate the new signature schemes into all wallets. There is already an initiative for this: ethereum-magicians.org/t/extensible-c…
But for now, we use a simple trick: every @zksync tx must be signed with 2 signatures: a ZKP-friendly one for use inside zkRollup, and a normal Ethereum one for our API (signed in the 3rd party wallet):
This second signature is verified by our servers and the transaction will be rejected if it's not valid. It serves as a sort of 2FA for @zksync transactions. Notice that the message is in plain text: this way we can provide a proper format handled by most wallets.
Now, even if our web client is hacked, the attacker won't be able to trick the user. The attacker would have to break BOTH 1) the web client AND 2) either user wallet or our servers. Those are hosted on different systems and maintained by different people, which is a lot harder.
Of course, this 2-factor approach will only work as long as @zksync is operated by trusted service providers. By the time we transition to a fully permissionless protocol most wallets should support the new curves.
@threadreaderapp unroll
