
Keybase’s browser extension subverts its encryption - fallenhitokiri
https://palant.de/2018/09/06/keybase-our-browser-extension-subverts-our-encryption-but-why-should-we-care
======
pedroaraujo
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...](https://palant.de/2018/07/11/ftapi-secutransfer-
the-secure-alternative-to-emails-not-quite)), the claim “end-to-end
encryption” doesn’t automatically translate into a secure implementation."

~~~
michaelt

      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...

~~~
pedroaraujo
There are rules for bug bounty programs: \-
[https://hackerone.com/keybase](https://hackerone.com/keybase)

~~~
hjek
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.

~~~
jsjohnst
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.

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

~~~
jsjohnst
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.

~~~
daveFNbuck
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?

~~~
jsjohnst
> 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.

------
Legogris
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.

~~~
Leace
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!

~~~
FabHK
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...](https://blog.filippo.io/on-keybase-dot-io-and-encrypted-private-key-
sharing/)

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

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

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

------
adambrenecki
> 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.

~~~
palant
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...

~~~
orf
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

~~~
palant
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.

------
lrvick
Keybase also silently subverts smartcards for in-memory keys per my findings
here: [https://github.com/keybase/keybase-
issues/issues/1946](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.

~~~
nickik
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.

~~~
nh2
> 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.

~~~
arglebarnacle
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.

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

[http://lettergram.github.io/AnyCrypt/](http://lettergram.github.io/AnyCrypt/)

[https://github.com/lettergram/AnyCrypt](https://github.com/lettergram/AnyCrypt)

[https://chrome.google.com/webstore/detail/anycrypt/hddfngccl...](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.

------
patcheudor
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.

------
jwfxpr
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](https://github.com/keybase/client/issues)

------
benatkin
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.

------
dilatedmind
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.

~~~
phyzome
> 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.

~~~
dilatedmind
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.

------
throwanem
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.

~~~
palant
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.

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

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

~~~
icebraining
Thanks.

------
znpy
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)

~~~
fastball

      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](https://github.com/sindresorhus/caprine)

~~~
als0
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.

~~~
znpy
this is exactly what i meant. thank you.

------
wetKoala
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.

