Uploading private keys puts users at risk #160

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

👍

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

lyndsysimon · Mar 7, 2014

👍

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

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.

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

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

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.

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

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.

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

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.

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

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.

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

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.

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

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

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

bdrewery · 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

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.

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

Compare https://blog.filippo.io/on-keybase-dot-io-and-encrypted-private-key-sharing/

plutext · Jul 26, 2015

Compare https://blog.filippo.io/on-keybase-dot-io-and-encrypted-private-key-sharing/

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.

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

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.

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

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.

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

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.

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

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.

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

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

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

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

w2ak · 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

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

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

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 !

w2ak · 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 !

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

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

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.

eduncan911 · Jan 29, 2018