9 ms·

Keybase’s browser extension subverts its encryption

225 points by fallenhitokiri 8y ago

Legogris 8y ago
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 8y ago
  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!
  - oedmarap 8y ago
    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.
    - tialaramex 8y ago
      > 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]
  - FabHK 8y ago
    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-private-key-sharing/ https://blog.filippo.io/on-keybase-dot-io-and-encrypted-priv...
    - jwilk 8y ago
      Security strength of RSA is much lower than the key size. 2048-bit RSA gives you only ~112 bits of security.
      - FabHK 8y ago
        That's very informative, thanks. So indeed, with a good passphrase the drop in security is minimal.
    - danenania 8y ago
      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.
    - Leace 8y ago
      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?
- lrvick 8y ago
  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.
  - Shank 8y ago
    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 https://keybase.io/triplesec
    - lrvick 8y ago
      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.
jwfxpr 8y ago
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
icebraining 8y ago
Where do those quotes from Keybase come from? Private email?
- palant 8y ago
  Bug report on Hacker One. While it has been resolved, it hasn't been made public for some reason.
  - icebraining 8y ago
    Thanks.
pedroaraujo 8y ago
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-alternative-to-emails-not-quite 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."
- michaelt 8y ago
  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...
  - DuckyC 8y ago
    Keybase is clearly stating that it is infact not a bug, but an intentionally not implemented feature.
    - michaelt 8y ago
      You think the guy who wrote the article should swallow that line of BS and be motivated to do more free pentesting for them?
  - pedroaraujo 8y ago
    There are rules for bug bounty programs: - https://hackerone.com/keybase https://hackerone.com/keybase
suttan 8y ago
http://upindia.mobi/277103/ofTQQJR http://upindia.mobi/277103/ofTQQJR
adambrenecki 8y ago
> 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.
- icebraining 8y ago
  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.
- AlphaWeaver 8y ago
  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.
- palant 8y ago
  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 8y ago
    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
lrvick 8y ago
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.
- Leace 8y ago
  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 https://www.gpg4win.org/change-history.html But given Keybase's track record I already know they're not interested in that.
  - lrvick 8y ago
    Any trust went out the window when I realized I could pull out my smartcard and continue signing things. My head exploded.
    - nickik 8y ago
      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.
dilatedmind 8y ago
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 8y ago
  > 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 8y ago
    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.
znpy 8y ago
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 8y ago
  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 8y ago
    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 8y ago
      this is exactly what i meant. thank you.
benatkin 8y ago
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.
deleted 8y ago
[deleted]
lettergram 8y ago
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 8y ago
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.
throwanem 8y ago
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 8y ago
  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.
sealthedeal 8y ago
Keybase is making crypto more accessible to the common man.
wetKoala 8y ago
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.

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 8y ago
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!
- oedmarap 8y ago
  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.
  - tialaramex 8y ago
    > 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]
- FabHK 8y ago
  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-private-key-sharing/ https://blog.filippo.io/on-keybase-dot-io-and-encrypted-priv...
  - jwilk 8y ago
    Security strength of RSA is much lower than the key size. 2048-bit RSA gives you only ~112 bits of security.
    - FabHK 8y ago
      That's very informative, thanks. So indeed, with a good passphrase the drop in security is minimal.
  - danenania 8y ago
    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.
  - Leace 8y ago
    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?
lrvick 8y ago
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.
- Shank 8y ago
  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 https://keybase.io/triplesec
  - lrvick 8y ago
    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.

jwfxpr 8y ago

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

icebraining 8y ago

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

palant 8y ago
Bug report on Hacker One. While it has been resolved, it hasn't been made public for some reason.
- icebraining 8y ago
  Thanks.

pedroaraujo 8y ago

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-alternative-to-emails-not-quite 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."

michaelt 8y ago
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...
- DuckyC 8y ago
  Keybase is clearly stating that it is infact not a bug, but an intentionally not implemented feature.
  - michaelt 8y ago
    You think the guy who wrote the article should swallow that line of BS and be motivated to do more free pentesting for them?
- pedroaraujo 8y ago
  There are rules for bug bounty programs: - https://hackerone.com/keybase https://hackerone.com/keybase

suttan 8y ago

http://upindia.mobi/277103/ofTQQJR http://upindia.mobi/277103/ofTQQJR

adambrenecki 8y ago

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

icebraining 8y ago
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.
AlphaWeaver 8y ago
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.
palant 8y ago
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 8y ago
  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

lrvick 8y ago

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.

Leace 8y ago
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 https://www.gpg4win.org/change-history.html But given Keybase's track record I already know they're not interested in that.
- lrvick 8y ago
  Any trust went out the window when I realized I could pull out my smartcard and continue signing things. My head exploded.
  - nickik 8y ago
    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.

dilatedmind 8y ago

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 8y ago
> 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 8y ago
  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.

znpy 8y ago

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 8y ago
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 8y ago
  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 8y ago
    this is exactly what i meant. thank you.

benatkin 8y ago

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.

deleted 8y ago

[deleted]

lettergram 8y ago

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 8y ago

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.

throwanem 8y ago

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 8y ago
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.

sealthedeal 8y ago

Keybase is making crypto more accessible to the common man.

wetKoala 8y ago

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.