no passphrase required to read Folders

[florin-andrei-curbside]

I've added a few files under the KB filesystem:

/keybase/
├── private/
│   └── florinandreicurb/
│       └── private-test.txt
├── public/
│   └── florinandreicurb/
│       └── test.txt
└── team/
    └── XXXXXXXX/
        └── test.txt

After restarting my laptop, I was able to access those files without being prompted for any password. That shifts the burden of security onto the laptop's account password and disk encryption.

I could not do the same test on Android because KB is not exposing the folders to the mobile app yet.

So technically this is either the same as storing those files on your laptop in plain text (if a local plaintext copy is stored all the time in /keybase) or nearly the same (if the Keybase helper service is required to run to access those files). In the first case, disk encryption is mandatory to protect the files; in the second case, a strong account password on the laptop is mandatory.

Either way, I would feel a lot better if KB asked you to enter your GPG password at least once to read those files.

Perhaps this is just because the Folders feature is pretty new?

---

Or, in case I misunderstand the way things work: with Keybase, how do I regain the same level of protection I had when I was using GPG? How do I make sure the secrets stored in KB are protected by more than just the account password on my laptop? (or the PIN on my phone)

[msassak]

Requiring a second factor to read some files after a period of time would be very helpful. It may be hard to use Keybase in some settings without it. But all in all an amazing product, thanks!

[sowbug]

Keybase promises end-to-end encryption, but not encryption at rest on endpoints out of its control. That's a good balance. If your threat model includes physical/local device access, then you already had full-disk encryption and a passphrase + screen-lock policy before installing Keybase. Anything Keybase did to address that threat on a machine without OS-level FDE & screen locking would be inadequate, or at least very hard to guarantee across Win/Linux/OS X/mobile.

By the way, this is approximately the same debate as this one, which unfortunately resulted in punishing all Chrome users to "protect" those who don't understand the true threat of physical access to hardware ("protect" in quotes because it's security theater).

If you want at-rest security, use FDE + a strong local access policy (just as you suggested). As a userland app/service, Keybase can't do it.

[florin-andrei-curbside]

@sowbug I see your point.

However, it should be noted that if the app allows unrestricted access to all its data as soon as you are able to open the GUI feels like a big disappointment after the initial promises. You get strong protection end-to-end, but then each end is very significantly "softened".

The all-or-nothing approach seems unnecessary at best, and misleading at worst. For the sake of convenience and ease of use, sure, keep most content directly accessible from the GUI. But the app would be that much more useful if the user could designate certain areas that require extra authentication - ideally in the form of the GPG passphrase.

Keybase seems to solve some of the persistent issues that plague GPG - key distribution, user-friendly GUI. But it's underwhelming to see how those problems are solved at the price of weakening the overall protection at each end of the tunnel. Just like GPG, it solves the problem of securely sharing data; unlike GPG (and arbitrarily so), all that same data is then presented in cleartext at each endpoint, as shown above.

Again, to make it clear, I am arguing against the all-or-nothing approach. Do not decrypt everything no matter what. Decrypt all new content by default, but allow the users to optionally create "walled gardens" in the Folders section where additional protection is enforced, perhaps following the model used by gpg-agent where the GPG passphrase is required for initial access and is then optionally cached for some time (and no walled garden content is stored in clear text anywhere).

As it is currently, Keybase is nothing more than strong crypto for the communication part, but then it completely abandons all protection as soon as the data comes out of the encrypted tunnel. It's a bit disappointing to be honest, especially after years of waiting for someone to come up with some kind of "GPG done right".

[sowbug]

I think we agree on the facts but have different attitudes about the security story. I view Keybase as an ingredient of the full story (FDE etc. being more essential ingredients). You're being a little more pragmatic, recognizing that not everyone is willing to go that far. Thus you're concerned that Keybase doesn't actually do anything, today, to protect data at the endpoints for people who aren't committed to the full story. My attitude for security is that if you can't do it right, you shouldn't do it at all. Your attitude is that there are still practical benefits to a 95%-secure solution. I'm really afraid of the 5% insecure part (for example, the person who is stopped by your folder-based walled garden instead installs a keylogger on your machine). I think it's OK for us to disagree -- your position represents reality, and mine is where I want people to go.

[florin-andrei-curbside]

My attitude for security is that if you can't do it right, you shouldn't do it at all.

Don't ignore a key concept here: layered security. As a matter of fact, all security is "layered" on some level, there's no magic silver bullet in this field. There's a lot of value in not removing that extra snag from the way of the intruder, especially when that does not affect general usability. It's certainly better than the abandon-all-hope-ye-who-enter-here approach.

Removing layers from the security "onion" never increases security. It's quite obvious.

your position represents reality, and mine is where I want people to go

This industry is a darwinian world, and people will go where things really work.

I am trying to get away from the semi-manually maintained bunch of *.gpg files for storing and sharing passwords with the team, which I don't have to tell you how awful it is, for I am certain you can imagine it quite easily, knowing how GPG works. And we use Slack. So Keybase looked very promising - GPG finally done right, and more, or so it seemed - until I've noticed how it stores all files in cleartext on the disk in a path that's pretty standard, without any extra authentication factor.

PCI compliance would never give that a pass. I would never give it a pass. And it seems silly to harness the full power of GPG to encrypt communication, but then be forced to use LastPass or whatever for secrets. Then why give up Slack? There goes an opportunity for Keybase.

With this one change - allowing the creation of persistently encrypted domains within the app - Keybase could even touch the periphery of use cases for the likes of Symphony.com, almost like an inexpensive DIY alternative when requirements are not that strict. So much potential, so close yet so far away.