Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Uploading private keys puts users at risk #160

Closed
englishm opened this issue Mar 7, 2014 · 29 comments

Comments

Projects
None yet
@englishm
Copy link

commented Mar 7, 2014

Just looked at the usage message for keybase push:

keybase push -h
usage: keybase push [-h] [-g] [-p] [-s] [search]

Positional arguments:
  search                search parameter to find the right key

Optional arguments:
  -h, --help            Show this help message and exit.
  -g, --gen             generate a new key
  -p, --show-public-only-keys
                        Allow picking of public keys for which no secret key
                        is available (not recommended)
  -s, --secret          push the secret key to the server

"push secret key to the server" is not something that should ever be encouraged. It puts users at great risk.

@lyndsysimon

This comment has been minimized.

Copy link

commented Mar 7, 2014

👍

In what circumstance would pushing a secret key to the server be desirable?

@ghost

This comment has been minimized.

Copy link

commented Mar 7, 2014

It is my understanding that private keys are not uploaded in plaintext, but encrypted with the user's passphrase. This allows the browser to download the private key, unlock it on the client side with the passphrase, and thereby allow keybase to function. Perhaps a keybase dev can clarify.

@malgorithms

This comment has been minimized.

Copy link
Contributor

commented Mar 7, 2014

Hi guys - this is a feature we'll continue to support. Many of you early users - who are of course skewing to the more security conscious - will not use it.

There are a few reasons one might wish to do this. All of them center around easy transportability of their secret key. For example, I'd like my secret key on multiple machines, and I don't know how to move it around easily. If I'm the average computer user out there, almost all solutions are strictly worse than what we're doing with keybase push -s

We'd like as much review as possible of our process for pushing and pulling secret keys from the server. Your key is triplesec encrypted (https://keybase.io/triplesec) client side, and you could do this yourself with triplesec if you don't trust the client to do it.

It's not there as a mistake, but we know that many people who use the command line version will not use it.

@malgorithms malgorithms closed this Mar 7, 2014

@michiexile

This comment has been minimized.

Copy link

commented Mar 24, 2014

You don't actually have to remove it to discourage it; and I agree with several other earlier comments that this is something you should strongly discourage for a wide variety of security reasons - including what happens if you lose your database.

I'd suggest something like have the actual process of pushing a secret key include several steps of information about what ramifications the decision would have and what feasible alternative methods could work. This way a user who chooses to do this will do so well informed, rather than almost completely uninformed.

We who react now are all people who wouldn't touch the functionality with a 10' stick. But the question isn't really about us: what worries us is (inter alia) the lack of user education coming with the option, as well as the various levels of inherent risk in even offering the feature.

@zQueal

This comment has been minimized.

Copy link
Member

commented Mar 25, 2014

Although I agree that it's totally insecure, no matter how you sugar coat it--I really don't think it's a feature that should be removed. One of the major points to keybase as a product, at least to me, is to bring PGP keys and authentication to the layman. Not everyone is able to use the command line, so having a secondary option just makes sense.

As an example, Facebook and 2Factor authentication. It just makes so much sense to enable it, considering our phones are always within hands reach from us, but ask yourself how many do you think actually have it enabled? If your facebook account gets taken over, it can really hurt your social image in the same ways as your private key getting taken.

Just some food for thought.

@MattSurabian

This comment has been minimized.

Copy link

commented Mar 25, 2014

It's a feature I'll never use, but probably a good time to point out that this is why one's private key should be protected with a strong and secret pass phrase. The PGP protocol is structured such that possession of the private key alone is not sufficient to encrypt, sign, or decrypt without the passphrase.

It still strikes me as a terrible idea, but provided a proper host-proof storage solution is implemented by Keybase it's not Armageddon.

👍 to clearer messaging regarding the the potential risks. The general idea of keybase is crypto that's more available to the masses, and at least a small piece of that should be best practices education. It's conceivable that a user coming to PGP for the first time might make the mistake of using a short, or otherwise poor pass phrase while also choosing to upload their private key to the server simply because they aren't aware of the pass phrase's intended function within the PGP protocol.

@orblivion

This comment has been minimized.

Copy link

commented Mar 25, 2014

For full disclosure, I'm not a PGP veteran by any means, but this strikes me as a fundamentally bad idea because the private key has been secured over many years of fixed mistakes. Maybe file permissions weren't ideal, maybe the random number generator wasn't great at this or that part of the process. It's the one really important piece of information that is critical to making PGP worth what it's worth. That it's now trusted with this new triplesec encryption, well, perhaps the developers are among the best, but it still hasn't stood the test of time. So you're taking a step back for integrity.

So you want to sacrifice some of what PGP has to offer in order to make it convenient enough for people to actually use. But you're going to dilute PGP in the process (assuming you're successful) by introducing a lot of people who have weaker standards (and people don't follow protocol that tightly as it is. and maybe that's a point in your favor). PGP and tools like it have the unique ability to withstand any storm that happens between your computer and the other party's computer. No matter what gets compromised in between you two, so long as your computer is safe (and I'm not saying it always is), your communication is safe. Your scheme doesn't fundamentally break this since the key is encrypted, but subjecting it to a new scheme makes this guarantee arguably a lot weaker.

Even if PGP is not practically a very secure system because of its awful user interface leading to people not treating it carefully, it's a model for a great system. It would just be a shame to break the model. There is a place for a less secure, but more widely used, system like yours (until somebody finds a way to make another robust system actually usable), why not start from the ground up? It's not like PGP is widely used among the people you're targeting anyway.

@kevashcraft

This comment has been minimized.

Copy link

commented Mar 26, 2014

I came upon this thread because the default option during the "keybase gen" function is to upload the private key and I was surprised. After reading the comments, I agree that the function is useful but I do not think it should be the default during the initial key generation.

@bdrewery

This comment has been minimized.

Copy link

commented Mar 28, 2014

This is a really bad idea. Whatever you claim on your intentions and security and as many reviews as you ask for, you are inviting hackers and skepticism. Encryption is hard. The world can review triplesec and not find any issue for years.

These things usually break down in other ways. A hacker, or a rogue employee, or a simple breakdown in your site's SSL, or rogue CA, could slip in code into the client-side encryption javascript to send the password somewhere and go unnoticed for minutes, hours, days, months. Any period of time would be unacceptable. This someone could then keep these keys for years until they find the right opportunity, and you'll never know. Just look at the recent Target POS fiasco. You are not immune to being hacked and manipulated.

Without client-side SSL cert pinning there is also great risk as well.

Yes, you have the feature with the intention of extending it to more people who would otherwise not have access to it, but you are also risking ruining the whole idea of it by storing private keys. "I can't copy my file around securely" is not a good reason either.

@bdrewery

This comment has been minimized.

Copy link

commented Apr 8, 2014

http://heartbleed.com goes to show just how bad of an idea this is. More things like this will happen.

Take it from the expert: "Unbreakable" Encryption Almost Certainly Isn't

@alexflanagan

This comment has been minimized.

Copy link

commented Oct 9, 2014

I agree with the usability reasons for having this feature, I'm using it to transport keys between work and home, and I think uploading the private key shouldn't be the default on keygen for the reasons above.

As a general software design principle I favour secure defaults. This default favours usability. It's an interesting tradeoff in terms of the command line client: the user there is probably more technical and so less concerned about usable defaults.

Loving the product though.

@plutext

This comment has been minimized.

@DanielHeath

This comment has been minimized.

Copy link

commented Apr 14, 2016

filippo claims that decrypting the (password-protected) key is arguably as hard as reverse engineering the private key from the public one.

That is absolutely, categorically not how crypto works and he should know better.

Assuming correct implementations and appropriate key sizes, reversing passphrase protection costs thousands of dollars in compute time; reversing the private key from the public key (without significant mathematical breakthroughs) is not achievable by all the computers on earth.

@orblivion

This comment has been minimized.

Copy link

commented Jul 17, 2017

I just wanted to note something I discovered, that may be of interest to others here who are troubled by the existence of this feature:

Until this point, I've refused to use Keybase. However, though I don't get it, Werner Koch is okay enough with it to use it. It doesn't make sense to me to refuse to use it anymore if the guy who makes GPG doesn't protest.

@cwh1te

This comment has been minimized.

Copy link

commented Jul 28, 2017

Not providing an obvious means of uploading a public key is bad. Asking users to upload their private keys is worse. Storing those private keys unencrypted without the user knowing is just unforgivable (#2863). Shame on you, keybase devs. You should absolutely know better.

@smscotten

This comment has been minimized.

Copy link

commented Aug 13, 2017

This seems like a good use case for signed subkeys with the master key kept somewhere airgapped. Generate a brand new key pair just for use with keybase, not your master key, and not the key you use for daily email etc, but one that is still in your main keychain as trusted. And revocable at any time.

I still find it outrageous, but it is a way to make use of the feature without blind faith in keybase's good intentions.

@hadees

This comment has been minimized.

Copy link

commented Aug 27, 2017

What about supporting something like TREZOR? It seem like to me if you want to encourage laymen to use good practice a hardware key seems like an easy way to transfer. It could even be used like @smscotten suggests and generate a separate key that gets upload to your server which is just used for things that absolutely require a private key and/or you let users use the less secure key but checkoff on the risks.

@sp4ke

This comment has been minimized.

Copy link

commented Oct 12, 2017

@hadees Agree with you, for me a company that is advertising being all about security and ignoring and issue like keybase/client#4675 and just waiting for public contributions says a lot about their priorities ...

After some years I decided to give it a try, I installed on my machine and when came the moment to send my public key I discover to my surprise Keybase needs the secret key. Sorry but I chose a Trezor exactly so the private key never touches an online machine and you not having support for hardware keys is a no go for me. Too bad the product looks really good but this is just security theater as far as I'm concerned.

@w2ak

This comment has been minimized.

Copy link

commented Oct 29, 2017

Hello !

While it seems to be now impossible to host a private key on keybase (keybase push tells to use keybase pgp select which promises not to upload the secret key whatever we do), certain webpages like the decryption page still advertise the possibility to host our private key on keybase.

Is this an incoherence ? If we cannot upload secret keys on keybase anymore, how is it that there are still a signing and decryption page on the web application ?

Thank you,
neze

@aditsachde

This comment has been minimized.

Copy link

commented Nov 9, 2017

@w2ak It is still possible.

The reason I do use this feature is that I don't (and most others) use pgp often and across due to the complexity. I only use pgp on my linux machine (and really, its the only one I trust), but in the case that I ever need urgent access, I am able to use keybase to do it.

As with all good security practices, I keep up to date with keybase so if under any circumstances, the encrypted version is leaked, I can revoke it and if the attacker actually managed to decrypt it, they would find themselves revoked key.

@w2ak

This comment has been minimized.

Copy link

commented Nov 9, 2017

Thank you 😄

I looked a little further and found the functionality. It seems a little hidden but all right.

@densecomet were you able (did you try, by any chance ?) to upload only your private subkeys ? I did not try yet but if I were to upload my key, I would really want to upload only the subkeys.

Thanks !

@aditsachde

This comment has been minimized.

Copy link

commented Nov 9, 2017

@w2ak I generated keys and stuff on an offline copy of tails and only transferred the subkeys to my main laptop (so if I loose my laptop or keybase looses their database, its not as big of a deal). I had reset my account, then used gpg to export from my laptop and uploaded only those keys to keybase, which are the subkeys only.

@eduncan911

This comment has been minimized.

Copy link

commented Jan 29, 2018

I too follow the practices @densecomet does. Though I don't use Tails (Tails erases everything on shutdown?), I do use an air-gapped machine for my master and secrets, issuing only sub-keys for my primary laptop, desktop and work machines. I never store nor use my master on any machine I normally use on a daily driver.

The only reason someone would want to go to this extreme would be to build solid faith in the documents (and messages) they sign as truly being them - as it's more difficult to lose your master key being stored offline.

It sounds like @densecomet and myself do go to this extreme to prove our identities.

I've recently been asked by a security-group of individuals to join up on Keybase and every time I dig into it, it always wants my private key. I just cannot fathom why any application would want that.

Yes, the CLI may prompt for my phasephrase to sign my pubkey, to prove it's me.

Yes, the CLI has the option for pushing set to False by default - we think.

Yes, it is open sourced and I've been some time this morning crawling through the code to see if it is indeed set to false by default - and have ran out of time looking for that code.

Even if I was able to find that piece of open source code, what's to guarantee that the downloaded application on macOS or Linux CLI doesn't have a different flag set? Sure, it's signed by the publisher - but still I'd be more comfortable tweaking the source to basically break the push of my key and compiling it myself. Oh which I spent an hour trying to get ramped up on this morning, and just ran out of time.

So to all of those hesitant, here's what I am doing... This laptop is somewhat trusted by me. I only use a sub-key with a short expiration on this machine, with no master secret. I will use this to sign my keybase account, knowing that I can revoke it in the public domain at a later time if my machine is compromised. They say they won't upload... And I am willing to risk it considering the small timelines I use with my sub keys to expire them.

@syang

This comment has been minimized.

Copy link

commented Sep 16, 2018

echo what @michiexile said above, would a high level architecture diagram help educating the mass? Unlike GPG keyserver, keybase server is a proprietary implementation, and I think it may be understandable for whatever commercial reasons; but at least an educational diagram from user risk awareness and assurance perspective would help.

BTW, I got directed here through this discussion: https://superuser.com/questions/227991/where-to-upload-pgp-public-key-are-keyservers-still-surviving

@wiktor-k

This comment has been minimized.

Copy link

commented Sep 16, 2018

@syang I doubt that would ever happen. From my perspective Keybase is interested in making encryption easier to use even when it contradicts best practices (e.g. offline master key) because they're more interested in a broader audience rather than the "long tail" of "specialized" users. That would also explain why they don't provide standard keyserver API (HKP) and are not interested in the general OpenPGP ecosystem.

@aegershman

This comment has been minimized.

Copy link

commented Nov 7, 2018

Can confirm: I'm a huge idiot who knows nothing about encryption && I'm perfectly happy uploading my private keys into Keybase, at least for the time being until I get better at understanding encryption. Until then, I'm more than happy to take a risk if it means the barrier to entry is lower.

@sp4ke

This comment has been minimized.

Copy link

commented Nov 18, 2018

@aegershman if you trust your private key with a private proprietary third party it is indeed lowering the barrier to entry for "security theater". If Keybase is honest about their aim to make key management more user friendly they should at least post an update on this topic and their motive for not taking it seriously. Hardware based keys are getting more widespread and they are incompatible with the current keybase CLI.

@eduncan911

This comment has been minimized.

Copy link

commented Nov 19, 2018

So I am coming back to say that Keybase doesn't use your PGP key.

As mentioned in my previous post above:

  • I use subkeys generated offine using my master key with short expiration dates.
  • I did not push my key to keybase when using the CLI to import it.
  • I cannot use the web GUI, because I did not oush my key (which is fine, and I prefer it that way)
  • My subkey has expired 4 months ago, the one I gave to keybase.

However, I'm still able to send/receive messages, and encrypt and decrypt old and new files on the KBFS - with a long expired subkey.

Now that begs the question... Why does Keybase demand my private key over and over when setting it up without keygen, if it isn't even used?

The only thing I can think of is to prove my identity it posts in my profile. But in that case, why even have an "upload" feature as it's not even used?

@zQueal

This comment has been minimized.

Copy link
Member

commented Apr 12, 2019

@eduncan911 if this is the way you intend to use Keybase, a better question to ask yourself would be "why use Keybase at all?"

It doesn't seem to be the type of software you're comfortable with using. So why?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.