Keybase CEO here. Let me tell a quick story. January 2019. I was loading the car to leave for a short family ski vacation when I got a truly horrifying email: that my slack account had been accessed from a distant land (that I hadn't been to).
There goes my weekend!
When we first started Keybase, we used Slack as other teams did, but were gradually moving all Slack-based workflows over to Keybase. As such, we didn't use it for anything beyond communicating when Keybase was down. But I was very worried. I knew I used a good, random, one-time password for Slack, so it couldn't have been that the password was stolen from somewhere else. Had my computer been rooted? Had my side-hustle password manager been compromised (oneshallpass.com). I immediately contacted Slack security and asked them if this issue was on their side, and they neglected to point me to the relevant blog article from 2015 (which didn't detail the extent of the compromise, we now know). They just said they take security very seriously and hinted I was at fault.
In the subsequent few weeks, I reset all of my passwords, threw away all my computers, bought new computers, factory-reset my phone, rotated all of my Keybase devices, and reestablished everything from the ground up. It cost me a lot of time, money and stress. In the end, I was pretty sure but not 100% convinced that if I had been rooted, that the attackers couldn't follow me to my new setup. But with these things, you can really never know for sure.
I got the email today that my account might have been compromised in the attack. I would say for sure that it was compromised, and I can breathe a big sigh of relief, that was the explanation I wanted to hear all along.
It was great to know throughout this ordeal that the product we're building --- Keybase --- solves this problem in a fundamental way, not with adding further workarounds (2FA while better than just password alone, reminds me a bit of the 3-digit verification code on the back of your credit card; and if Slack's credential database is compromised again, 2FA won't help at all). With Keybase, all of your data is E2E encrypted, and your encryption keys never leave your device. A would-be attacker who compromised our database would have no ability to access any important user data.
Summary: estimated cost to me:
- $5000 worth of hardware
- 60 hours of labor
- 25 hours of lost sleep
- 10 additional hours of team effort
Fortunately:
* Keybase does not communicate sensitive information in slack such as cap tables, financials, employment decisions or compensation discussions, team reviews, company devops secrets, stupid memes that could be taken out of context, or private DM'ing. Basically we just use a `#breaking` channel in Slack, for when we break Keybase.
* Keybase itself is immune from this kind of break-in.
Note that Slack has only sent the email about account access since 2018:
>Additional security features: As of January 2018, we began sending an email every time your account is accessed from a new device; this is a simpler and more immediate way for you to be aware of new logins to your account than periodically reviewing your access logs.
(Quote from the "Slack password reset" email they recently sent out to affected users.)
I think if this happened to me I would just assume the company was hacked due to poor security practices. It seems much more likely than my password being stolen from a device of mine considering that a very significant percentage of companies I have account with seem to have had breaches at some point. But maybe I am just naive.
I think it’s different depending on who you are and what systems you have access to. The Keybase CEO is much more vulnerable to targeted attacks where 0-days would be potentially worth the cost.
Why throw away your computers? Why not remove/disconnect the batteries (if portable) and just store them somewhere in case you eventually no longer suspect a hardware hack, as in this case?
Further: Keybase is a security product and it wasn't deemed worth the risk for the CEO. And while Keybase isn't made of money, the $5k was roughly irrelevant compared to the other costs mentioned here and the _magnitude of the risk_.
If you haven't been through this kind of thing, it's hard to understand how scary it is to have a break-in of unknown origin. If you use strong, unique passwords as Max did, then you're almost certain it's a server break in (and again, this is why Slack is scary for sensitive info)...but being 99% certain isn't enough. Removing that computer permanently from the team gave peace of mind.
Great point. The fact that street parking is roughly free in NYC both encourages drivers to drive and causes unnecessary bottlenecks on congested major thoroughfares. Take, for instance, 86th Street. One lane taken up by parked cars, plus just one double-parked truck means most crosstown traffic along that latitude and in that direction (including packed busses) must single-flight. That the city chooses to keep commuters stuck in traffic to accommodate disused cars is a pessimal allocation of precious street area.
Correct: forward secrecy isn't on by default. We think there's a trade-off here. With forward secrecy, your old messages won't be visible on a new device, but users want this since Slack (and others) make it seem natural. However, you can opt-in to forward security on a per-message or per-conversation basis.
The report says "device and server compromise." Decryption keys never leave the user's client. What they mean is if: (1) the server's stored data is compromised; (2) your phone is also compromised; and (3) the messages weren't marked ephemeral; then the attacker might be able to read past messages, even if the user tried to delete them (i.e., did Keybase really delete the ciphertexts?). This line of reasoning is correct and one of the primary motivations for key ratchets. I don't think the report is claiming that users need to trust Keybase's server in general. They do need to trust Keybase to delete messages that are marked deleted, which would mitigate the attack above if conditions 1 through 3 are met.
My issue with Keybase's exploding messages is they're time-based exploding. I wish there was an option to do forward-secrecy messages where the message is visible indefinitely to current devices, but not visible to future devices.
From the anonize paper [1]: “Our system is constructed in two steps. We first provide an abstract implementation of secure ad-hoc surveys from generic primitives, such as commitment schemes, signatures schemes, pseudo-random functions (PRF) and generic non-interactive zero-knowledge (NIZK) arguments for NP.”
Agreed we could have used either of those. We needed a PRF keyed by the Game ID (so the revealed secrets of this game can't be replayed in the next). Blake2b and SHA3 would also have worked fine.
The problem is that if you assume your encrypted traffic is being collected and stored today, and you want it to stay secret indefinitely, and you anticipate quantum computers will break discrete-log-based crypto in 20 years, then you need to deploy a post-quantum cryptosystem today.
This is a problem we face training activists and journalists in a number of countries. Esp places like China, Russia etc. We have to work hard to help people get the idea that a lot of the encrypted, password protected stuff etc they send now is potentially at risk in 5-10+ years. To a certain extent (but different context obviously), the lessons of the Venona Project comes to mind.
IIRC that's one of the big things the NSA's data center was doing - storing Tor traffic with the assumption QC could break the public key crypto and either see where it was going/coming from or maybe even what was being sent (traffic itself)?
Take what I say with a grain of salt, I'm not a cryptographer.
It's my understanding the onion routing (what went where) could be cracked since it uses public key. The data itself may be fine because it uses private key, but if you sent the private key using a public key then you may be burned (IIRC there's a protocol where you send the symmetric key using public key crypto then fall back to private key since it's faster)
There goes my weekend!
When we first started Keybase, we used Slack as other teams did, but were gradually moving all Slack-based workflows over to Keybase. As such, we didn't use it for anything beyond communicating when Keybase was down. But I was very worried. I knew I used a good, random, one-time password for Slack, so it couldn't have been that the password was stolen from somewhere else. Had my computer been rooted? Had my side-hustle password manager been compromised (oneshallpass.com). I immediately contacted Slack security and asked them if this issue was on their side, and they neglected to point me to the relevant blog article from 2015 (which didn't detail the extent of the compromise, we now know). They just said they take security very seriously and hinted I was at fault.
In the subsequent few weeks, I reset all of my passwords, threw away all my computers, bought new computers, factory-reset my phone, rotated all of my Keybase devices, and reestablished everything from the ground up. It cost me a lot of time, money and stress. In the end, I was pretty sure but not 100% convinced that if I had been rooted, that the attackers couldn't follow me to my new setup. But with these things, you can really never know for sure.
I got the email today that my account might have been compromised in the attack. I would say for sure that it was compromised, and I can breathe a big sigh of relief, that was the explanation I wanted to hear all along.
It was great to know throughout this ordeal that the product we're building --- Keybase --- solves this problem in a fundamental way, not with adding further workarounds (2FA while better than just password alone, reminds me a bit of the 3-digit verification code on the back of your credit card; and if Slack's credential database is compromised again, 2FA won't help at all). With Keybase, all of your data is E2E encrypted, and your encryption keys never leave your device. A would-be attacker who compromised our database would have no ability to access any important user data.
Summary: estimated cost to me:
Fortunately: Edits: wordsmithing and improvementsAlso: Import your Slack team to Keybase: https://keybase.io/slack-importer