Hacker News new | comments | show | ask | jobs | submit login
Keybase’s browser extension subverts its encryption (palant.de)
225 points by fallenhitokiri 3 months ago | hide | past | web | favorite | 75 comments



While they could have expanded better on their reasoning for not using iframes, I feel this is an overly dramatic post.

The browser extension is not their main product and they explicitly say so. The author is completely dismissing [0] the entire product just because of a side project, which in the worst case scenario could be fixed by the community by submitting a patch.

It is also strange that the author seems to feel the need to reinforce the sensationalism of this post by linking something completely unrelated to Keybase.

Also, where are the quotes on this post coming from? Where is the rest of the communication?

There is really nothing to see here.

[0] - "Initially, I planned to take a closer look at the crypto in Keybase, to see whether I can find weaknesses in their implementation. But that’s off the table now."

[1] - "But as experience shows (https://palant.de/2018/07/11/ftapi-secutransfer-the-secure-a...), the claim “end-to-end encryption” doesn’t automatically translate into a secure implementation."


The Keybase browser extension seems to be a first-party product from them on their site. If the guarantees they make about it are this misleading, then it feels harder to trust other things they say about their product.


  The author is completely dismissing [0] the
  entire product 
If he's looking for bug bounties (be it for cash, kudos, principles, or to see it fixed), and he finds a security bug and doesn't get a bounty, why would he keep looking?

Fool me once, shame on you; fool me twice...


There are rules for bug bounty programs: - https://hackerone.com/keybase


Which one of those "outside the scope" categories would you say this one falls into then?

To me it reads like there's nothing preventing this bug report from deserving a bounty.


None of these bullets are “open and shut cases”, but all are related without needing a major leap, especially the first one.

* Content spoofing / text injection

* Issues related to software or protocols not under Keybase control

* Reports of spam

* Vulnerabilities affecting users of outdated or unpatched browsers and platforms

Do I agree with their (alleged) actions? NO! But as I know several folks at Keybase personally, I’m sure there’s another side to this story and I’m willing to give them some benefit to the doubt until I hear otherwise.


If this vulnerability can fit those 4 categories, what kind of vulnerability would you be confident would qualify for the bounty?


That’s the problem, I feel their exclusions from bounty are too wide. This vulnerability if confirmed should be eligible for some bounty imho. That said, they published the exclusions publicly, so getting butt hurt over not getting paid when they said you wouldn’t feels a bit petty to me.


Why do you say he's butt hurt? He doesn't even mention not getting paid. The post is about Keybase not taking a security vulnerability seriously. Is it petty to warn people about an insecure product?


> Why do you say he's butt hurt?

I didn’t. It was a generalized statement about the bounty terms, not directed at any one person.


Keybase is clearly stating that it is infact not a bug, but an intentionally not implemented feature.


You think the guy who wrote the article should swallow that line of BS and be motivated to do more free pentesting for them?


The Chrome/Firefox extension is flagged "NEW" on the download page. If these allegations are correct, it ought to be clearly labeled as insecure. I'm quite disappointed.

And BTW, I also don't like the option to upload private keys. I mean, no sane person would ever do that. It's not that hard to copy keys to multiple devices, if that's really necessary for your work flow. Me, if I used mobile devices, I'd use dedicated keys, because those things are so readily pwned.


It all comes down to trustworthyness with products such as Keybase. If I were them, I'd make sure that Keybase comes across as trustworthy in all of their endeavours.


The quotes come from a bug report on HackerOne. While this report has been resolved, it wasn't made public.

The extension is very much an official Keybase product and recommended heavily on their end. Why should I waste more time on a product where valid security issues are being dismissed? It isn't even so much about not being paid, as: if they don't care about such edge cases subverting their end-to-end encryption, what do they care about?


I have to say I am surprised and disappointed. Keybase has up until now been a shining example of doing crypto right but still accessible and easy to use. This decision falls strictly on the wrong side of the line of acceptable compromises.

> there were technical reasons why iframes didn’t work, though I forget the details

It could be that there is one or a couple of engineers at Keybase who made this decision and are also the same entity that replied to the bug bounty. It feels like they haven't thought it through properly or brought it up for proper discussion inside the organization. Let's hope that they remedy this and adjust their general approach to this if this gets enough attention.

On the other hand, even if this is addresses, unfortunately it's an indicator that other compromises in this category are done in other parts of Keybase.


When they started asking me for my private key and claiming it'll be secure because it's "encrypted" that raised a red flag for me.

Then I found out that they're not using popular and audited libraries like OpenPGPjs instead... writing their own!


I second this. Would I upload/integrate my public key? Certainly, if it was supported as such. That being said, KB functions just fine without an explicit PGP private key, since each device I install KB on generates its own signing key -- that's good enough for KB to verify my social idents and support initial communication; the more proofs they add the better.

But more serious and nested "secure" communication would be wiser done elsewhere.


> Would I upload/integrate my public key?

I presume this is a typo, but if so it's a grave one.

The naming is very transparent, the intent is that we can give everybody our public keys, they're public, while our private key must remain secret.

(I like to use the U2 Lyric "A secret is something you tell one other person, so I'm telling you" to keep straight the difference between secret keys, which we must share with somebody else, and private keys, which we shouldn't share with anybody, although DH means in practice you may never need to explicitly "tell" anyone the secret keys in hybrid systems)

[Edited because I made the same dumb typo]


Filippo Valsorda had a blog post on uploading his private key (back in 2014) in which he actually publicly uploaded his private key - encrypted, that is, as it is uploaded to Keybase [1].

Of course, it goes against orthodoxy to share/upload your private key, but I'm not sure I've ever seen a good rebuttal to Filippo's post.

It seems to me though that you're reducing the entropy of your key from the 2048 bits or whatever to the entropy of your key phrase, which would normally only be some 100 or so bits (if you have a decent one) - but I'm not informed enough to judge the details. However, it seems to me that Filippo is, and he did upload his private key (encrypted) - so how bad is that, really? Anyone got some substantiated insights there?

[1] https://blog.filippo.io/on-keybase-dot-io-and-encrypted-priv...


I wouldn't have an issue with that if it was a private subkey. You could easily revoke it and replace it in case Keybase does something weird. But giving them private keys for master/primary key is not exactly sensible.

For the record I don't have a private master key in any online connected devices. GnuPG works well in an air-gapped scenarios. Does Keybase client? Or does it require constant phoning home?


If you encrypt a private key with a secret passphrase, then upload the encrypted private key somewhere, the passphrase is essentially your new private key. As long as the passphrase has sufficient entropy, there's no meaningful drop in security with this approach.


Security strength of RSA is much lower than the key size.

2048-bit RSA gives you only ~112 bits of security.


That's very informative, thanks. So indeed, with a good passphrase the drop in security is minimal.


Honest question: what makes you think they have -ever- done crypto right?

As best I can tell they have rolled their own mostly closed source crypto solution from day 1.


TripleSec is open source and they’re basically doing a reference implementation from Applied Cryptography. You can see the details here: https://keybase.io/triplesec


This is a perfect example of them doing it wrong.

Modern cryptographic algorithims rarely get broken, but keys get stolen by malware all the time. Instead of moving the keys out of system memory and thus out of reach of malware they just add layers of obfuscation to a key that is going to be decrypted into system memory. Mixing unrelated strong ciphers is likely to yeild nothing but a false sense of security at best and yeild malleability attacks at worst.

If you take your key and encrypt it 3 times, or 200 times, it is still moot if it by design it ends up plaintext in system memory.

You don't see anyone else doing this sort of nonsense mix and match security for a reason. Their threat profile is fundimentally broken if they think attacks on modern crypto primitives are more likely than malware on an end users system.


> Avoiding it is fairly easy, by isolating all of the extension’s user interface in an <iframe> element.

Right, but if the social network website can modify the HTML that the Keybase extension is injecting, then surely it can also modify the iframe's URL to an attacker-controlled one? Or, for that matter, replace the event handler on the "Keybase Chat" button itself before it even gets clicked?

I'm not an extension developer, so there might be APIs available to extensions or restrictions on webpage JS that I'm not aware of, but I suspect the only secure way to do this (if you don't trust the page you're embedding in) might be to have the extension communicate with the native Keybase app, which then opens a chat window with the appropriate user, similar to how the 1Password browser extension works.


Right, but if the social network website can modify the HTML that the Keybase extension is injecting, then surely it can also modify the iframe's URL to an attacker-controlled one?

Keybase could minimize that by showing the user's name and/or logo in the iframe. Barring another vulnerability, the site shouldn't know who is logged in into the extension, so they shouldn't be able to fake that.


Yes, I didn't bother expanding this further. Spoofing Keybase UI would still be possible, but users would notice that their message doesn't get sent. Still, the only complete solution would be to delegate even the initial message to the app rather than asking uses to enter it on the webpage. Unfortunately, browsers don't let extensions open trusted UI at will...


Sure they do, you just get a prompt saying 'you sure you want to open keybase?', with the option to skip this prompt in the future


By "trusted UI" I meant user interface within the browser that clearly doesn't belong to the webpage - such as the browser action's pop-up. As I said, an extension like Keybase could delegate this action to their app. Other extensions don't have this option because they don't have a native component. This is the reason why so many have implemented questionable or outright insecure solutions.


As an extension developer, I'm tempted to say that your suggestion might be the only secure way to do it. Extension Javascript is isolated, but all extensions share the DOM of course.


Keybase also silently subverts smartcards for in-memory keys per my findings here: https://github.com/keybase/keybase-issues/issues/1946

In general I find Keybase to be a step forward in user experience and two steps backwards in terms of actual security. They just don't seem to care about the latter at all and have not demonstrated any cooperation with standards bodies like the OpenPGP working group where members have expressed interest multiple times in adding generic URL uids to the openpgp public key itself to replicate and decentralize the idea of social media based trust bootstrapping (the one good idea from Keybase in spite of terrible execution). Instead they insist on their complex proprietary walled garden system that does not integrate with existing keyservers and throws everything on the bitcoin blockchain for reasons.

Keybase has become the IE of crypto and I can't take any security project seriously that even -integrates- with them.


They don't throw everything on the blockchain for no reason. They specifically back up the root of the merkel tree into the blockchain.

Honestly, the OpenPGP world has so competently failed at usability and is only adopted by the most hard core of nerds. Even I have stopped using it for the most part.

And that it is two steps back in security overall is just not true. Maybe in some individual features that you care about, but not in general.

And the same thing counts that always counted, crypto that nobody is using is not protecting anything.

The have mostly moved on from GPG any a different libraries now. The GPG is mostly a legacy feature.


> OpenPGP ... is only adopted by the most hard core of nerds.

This seems pretty inaccurate.

* Lots of software projects sign their releases with PGP.

* Almost all Linux distributions sign their software with PGP. If you use Linux, your security relies critically PGP.

* Github has support for PGP, and I see people use it.

* My random server hoster happens to sign all their emails with PGP.

You could claim that all these systems are run "by the most hard core of nerds", but at that point the statement loses its relevance.


The GP was pretty clearly talking about PGP in the context of ordinary encrypted communication between people (like email). Keybase isn't competing with PGP for signing releases. In the field that we are talking about, PGP has absolutely failed to gain widespread traction outside a certain hard core group of nerds.


Those aren't a representative sample of computer users though. Those are in fact the most hard core of nerds. If you want to take a poll of users, look at even keybase users (already highly biased). How many of them use the PGP key that they had to create when they signed up? I know I don't.


Even Facebook for all their privacy failings supports it. You can add your public key to your profile and they will encrypt all emails to you.


> crypto that nobody is using is not protecting anything.

There's only one thing that's worse. Crypto that people think is protecting them, but which isn't.


Yeah but for the most part Keybase is not that. The person above point out one special case and not for the whole system.

For the most part Keybase crypto is modern, effective and easy to use.


We already have a distributed backup system: the keyserver network. There are also efforts like DANE to put it in DNS. They however refuse to sync with it. They only sync with their own proprietary servers using their own protocol.

Also there are projects in the OpenPGP world making very easy to use workflows and interfaces without centralizing or breaking standards. OpenKeychain for android is a fantastic example of this.

I use OpenKeychain on my phone and can sign files, access passwords, or decrypt email by tapping my yubikey to it. I can tap someone elses key to my phone to import their key to my addressbook. No terminals or fuss and at no point does any key come in contact with system memory of any device involved so I have strong assurances it can't be stolen even if my phone is totally compromised.

A big example of the 2 steps backwards of keybase: they use keys in system memory and abandoned any compatibility with the openpgp smartcard spec, yubikeys, etc. The industry is moving to smartcards for very good reason: malware is a thing and it can use/steal keys from system memory without user interaction. A key stored in a yubikey 4 OTOH never touches system memory and requires a physical touch for each operation.

You can have usability without throwing out security and standards. Keybase is just another in a long line of companies ignorantly throwing out any security features they don't understand using usability as an excuse for bad engineering.


> There are also efforts like DANE to put it in DNS.

It seems GnuPG and "the ecosystem" is slowly moving to WKD (Web Key Directory) as it is easier to deploy (e.g. kernel.org is using it).

If you put your binary key (gpg --export 36C8AAA9) at https://lrvick.net/.well-known/openpgpkey/hu/gfoh5t79df9raqt... tools would retrieve it automatically when using your e-mail address (gpg --locate-key $EMAIL). (I got the hash by running gpg -k --with-wkd 36C8AAA9).

This is supported by GnuPG, OpenKeychain and some e-mail clients: Enigmail, GpgOL (Outlook) would fetch your key in background when someone is writing an e-mail.

For details see: https://wiki.gnupg.org/WKD#Implementations

The spec: https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-s...


> the OpenPGP world has so competently failed at usability

Don't you know? There's a rule that all cryptographic software must be arcane and obscure and virtually impossible to use correctly by anyone other than obsessive nerds.


This description perfectly captures my impression on Keybase too (especially the part on unwillingness to decentralize their social-media based identities).

For the record it soon may be possible to use native GnuPG through the browser extension:

> Installer: New optional module "Browser Integration" to register GnuPG as backend for Mailvelope 3.0.

Source: https://www.gpg4win.org/change-history.html

But given Keybase's track record I already know they're not interested in that.


Any trust went out the window when I realized I could pull out my smartcard and continue signing things. My head exploded.


You just don't seem to understand how the service you are using works and guess what. Its different then pure PG. It was not designed to work with your smart-card as it is not primarily about that.

Guess what, other people like me just realized that Keybase was not designed to be used like that and didn't use the smart-card together with Keybase.

I guess you can fault them for not saying that explicitly but since the made no mention of smart-cards and didn't evolve the security model in that direction it was pretty clear that that was not what they were about and therefore I did not expect it to be optimal to be used like that.


They used my openpgp key to setup my account. They link it on my profile as my key... I guess this gave me some crazy idea this was the key they actually use, not some silently created in memory keys that don't use the openpgp spec at all.


What is up with this issue? https://github.com/keybase/client/issues/13560

Is that a normal thing to do on github?


Changing the title of an issue, presumably so it doesn't show up in search results? Deleting the body of the issue? Not leaving any explanation? Yeah, that doesn't seem normal to me. Can't say I approve.


Looks to me like someone posted spam and it got removed. And yes, unfortunately, that's a thing on github these days.


Unless the title was lifted from another issue for the purpose of spam...

...this actually looks like a potential security weakness that was purged from the public space. (CWE-921)


it wasn't purged, per say. if you click "edited by maxtaco" on KirtiRamchandani's first comment, you get a dropdown to select the versions, and you can still find the original text.


Have you tried / compared Wire[0] by chance? I love Wire cause it's simple, my only recommendation is to register from a browser on your desktop, it asks for your number on the phone app, but you don't need to register like that. I also like that you can delete your account and nuke everything. The back-end is open source as well. Though KeyBase gets the UI / UX factor perfect, I wish some hardcore crypto devs would take KeyBase and make it more rock solid.

[0]: https://wire.com/


Wire's apps feel slow and bloated on both desktop and mobile. Compared to Telegram, Wire is almost unusable.


As a user, Wire has been fast and reliable and usable (even by non-techies) on iOS for several years, across a wide range of network conditions and hostile networks.

They are contributing to an IETF protocol (“MLS”) for E2E messaging, which is a long-term path to messenger interoperability.


I have not had the described slowness on Android and Windows (I think I tried it on Linux too) so I'm not sure what the parent commentator is speaking of.

Edit:

Relevant: https://tools.ietf.org/html/draft-barnes-mls-protocol-00


a long-term path to messenger interoperability.

I remember when we had that before E2E was popularized, it was standardized, and then walled gardens broke their interoperability in the name of (claimed) better user experience and user numbers.


So I wrote essentially the same chrome extension (albeit a different interface, which definitely allows for this vulnerability):

http://lettergram.github.io/AnyCrypt/

https://github.com/lettergram/AnyCrypt

https://chrome.google.com/webstore/detail/anycrypt/hddfngccl....

It worked fairly well (haven't tested it in a bit), but I had to reverse engineer pretty much all the Keybase APIs at the time.

The thing is, the author is totally correct. I wrote mine as a proof of concept, and quite frankly was surprised that the Keybase chrome extension (even a year ago when I checked) had the same issue(s) my implementation did...

That being said, this isn't an "end-of-the-world" kind of thing, I think there are several easy solutions to this problem as the author pointed out. Personally though, only 3 people use my extension with me. I couldn't get anyone to use the Keybase extension.. so I really think they should just update that phrasing on their extension page (perhaps add a warning) and let it be.


It cannot be said often enough: when you reference someone else's JavaScript in your solution in a way in which it has access to either the DOM or user interface components, it's no longer your solution. You therefore cannot, with any level of integrity claim that your solution is secure as you simply don't know what's happening in that bit of JS which is loaded by the solution into the user-space.


The keybase.io website offers a "Please send us feedback & bug reports" link[0]. As a keybase user, I intend to do so.

[0] https://github.com/keybase/client/issues


It seems like some analytics software like FullStory and possibly MixPanel would automatically log the messages.

I just signed up for keybase and was definitely steered towards installing the browser extension. I quickly uninstalled it because I found it annoying, though.


if you are going to encrypt a message, it must at some point be input without encryption. Just like you wouldn't type a sensitive message with someone looking over your shoulder, you can use common sense and limit use of this extension.

Keybase is fantastic.

i've been using keybase for 2 years now and have had no issue accessing my files through kbfs.

with keybase teams you can store secrets at rest and make them easy to access across your team.

the client loads 10x faster then slack and has nice ux.


> if you are going to encrypt a message, it must at some point be input without encryption.

How do you feel about someone else composing the message that "you" (your encryption software) are going to encrypt? Because that's what the article is talking about.


I feel like it would be best to avoid using their extension, but I am more concerned with the features and security of their core products.

And I would think it is analogous to running kbfs on a machine with a virus or keylogger.

And one nice thing is your root key is still protected by a paper key which you can physically secure, and use to de auth any compromised device keys.

For the casual user who is just getting into keybase, social integration like this may be worth the risk in order to help onboarding new users. Once they start seeing the real benefits of using keybase, they can delete the extension and still make use of the good stuff.

Finally, keybase is open source right? They are a small team and might not have the resources to improve the extension, but just getting the first iteration out there might be enough to attract contributors who see its value and can improve its security.


This isn't a hard bug to avoid, but it would take completely reimplementing the extension so that all of its UI beyond the "keybase chat" button lives in the extension rather than being injected into the page, and having the chat button do nothing but call the extension with the username of the intended recipient.

I understand why Keybase principals don't want to do that, because the extension is an addon that probably doesn't do anything in particular for them as far as adoption goes. I'm not sure I understand why they continue to ship the existing extension, knowing that it's insecure.

And I don't see any excuse at all for editing the bug report on Github out of existence - that strikes me as sufficiently sketchy that I may no longer use Keybase at all, and certainly will no longer rely on it to be especially secure.


Security bugs don't live on GitHub, they are on HackerOne. It is up to the vendor whether to make them visible. This particular one is still hidden, probably because I have code there demonstrating how this issue could be exploited.


Where do those quotes from Keybase come from? Private email?


Bug report on Hacker One. While it has been resolved, it hasn't been made public for some reason.


Thanks.


Meh. I wouldn't (and didn't) trust Keybase anyway.

My reasoning is that you're given some encryption software (keybase javscript on its website or browser extension) but the software is changing all the time: it might get re-downloaded on a tab refresh, the extension might download a "new version" or whatever... So basically you're supposed to trust an always changing piece of code (can you be auditing every piece of javascript that you download? every version of that javascript?) and you running in a super-connected runtime (like a browser). What could possibly go wrong?

I am not an encryption expert at all, but I feel a lot safer doing my crypto on a regular environment (linux shell or whatever) and then sending the cyphertext via any other mean (web, email, whatever).

Back in the day you could use pidgin to chat on the Facebook chat, and it was possible (and relatively easy) to use the OTR plugin to have really end-to-end encrypted chats. But (guess what?) Facebook later disabled the possibility interacting with its chat via external non-facebook-branded clients (afaik)


  Facebook later disabled the possibility interacting with its chat via external non-facebook-branded clients (afaik)
I don't think that's true, actually. The existence of Caprine[0] seems to suggest otherwise!

0: https://github.com/sindresorhus/caprine


I remember when Pidgin OTR worked fine with the old Facebook Chat, which I believe was based on the XMPP protocol. The move to Facebook Messenger deprecated this API and I don't think it works anymore.

In the case of Caprine, it appears not to use any official API and is just scraping the web page for the right elements. This seems quite fragile and also a non-trivial body of code.


this is exactly what i meant. thank you.


Keybase is fine for throwaway encryption that only needs short-term wire security to protect data that will be useless next month.

I wouldn't use a keybase key for anything that should be rendered eternally unbreakable, based on side-channel threat analysis alone. Private keys are not something that should be sourced from a website.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: