[davmre]

Imagine that Keybase is compromised. It starts serving a password-prompt page that looks identical to the previous, but now sends your decrypted key straight to the malicious attacker.

Storing your private key on Keybase allows Keybase to become a single point of failure, which pretty much defeats the whole point of distributed social verification in the first place.

[rdl]

And worse -- it only needs to send that special password prompt page to a specific IP or user of interest, and maybe only when it comes from a mac box (if the victim is known to do auditing on a linux box, but uses it as a regular client on mac).

Shipping packaged software with evil inside to ~everyone is risky because at least one user is likely to find a bug (accidentally) and try to trace/reverse/whatever (or, at the very least, if you do networked evil, some kind of IDS/firewalling).

Per-user downloads, especially at time of each use, are vastly more risky; this is the "hushmail attack".

[maxtaco]

We're definitely worried about the hushmail attack, and we disclaim browser-based crypto on the site for those who want to protect against powerful adversaries. Some users might not have those concerns.

You've obviously indicated valid concerns, but note, they're not indictments of storing an encrypted private key on the server so much as they are of browser crypto.

[rdl]

Yeah -- from what malgorithms says, you're actually on the path to removing dependency on a given binary being "near" my key material. I trust you guys more than enough for now; I just don't want to have to trust you if this gets wide adoption in 2 years once you become an actual target.

[tlrobinson]

As an aside, the web is an extremely convenient application distribution platform, it seems like a shame we can't securely use it for anything remotely sensitive. Is there a middle ground somewhere? e.x. signed bundles of HTML/CSS/JS?

[voltagex_]

If you ever run into a VBScript on an old section of microsoft.com, it's likely to be signed. I think I've seen a Sharepoint Javascript file with a signature block on the end but I wonder if MS had more plans for this.

[maxtaco]

We agree this is a problem, all of those who try to access their private key during the compromise would be in trouble. Those who stayed offline would be safe.

BTW, this argument does not extend to the CLI or other uncompromised clients. People who sync their private keys across devices with the CLI are unaffected.

[peterwwillis]

I'm confused. It sounds like users are able to sync their private keys with the CLI, or with the web interface. It also sounds like if they do it with the web interface, they are at risk, whereas with the CLI they are not at risk.

If my understanding is correct, my question is: What is the reason for this difference in security for the two use cases, and isn't there some way to provide web access without reducing security? What about browser add-ons? Client certificates?

[maxtaco]

A browser extension is in our (ever-expanding) todo list. We had one a few months ago, but we have to do a fair amount of work to get it back up to snuff.