3 ms·
It seems like you do not verify the public key of the new device (client-side) before encrypting the authenticated device's private key to it? Your server can
by agrinman 8y ago
It seems like you do not verify the public key of the new device (client-side) before encrypting the authenticated device's private key to it?
Your server can then impersonate a "new device", generate an ephemeral key pair, send the public key to all the user's authenticated device and perhaps trick the user into encrypting their private key to it. One way to prevent this is to show some sort of fingerprint on both the new device and the authenticated device proving that the public key is the correct one.
- sneak 8y ago1) According to experiments, users associate the term "fingerprint" with crime, not security. 2) Users, even ones who know what fingerprints are and care, do not validate fingerprints. The rest of the users (the other 99.9%) don't either. This is not a good UX.
- agrinman 8y agoI don't know about 1 but definitely agree with you on 2. You could make validation part of the workflow (before you can even "say yes", you need to scan a QR code for example). You might say this is also not good UX and I wouldn't disagree. Cryptography + good UX is a hard problem.