Something as simple as confirm-fingerprint-over-https (eg. look for https://ssh-host/.host-ssh-fingerprint) could work if enough ssh clients used it.
"file /Applications/1Password\ 7.app/Contents/MacOS/1Password\ 7" says "Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64 - Mach-O 64-bit executable x86_64] [arm64]"
Activity Monitor says that all 1Password things are of Kind "Apple" (not "Intel").
So they still don't know how it happened.
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.
Edits: wordsmithing and improvementsAlso: Import your Slack team to Keybase: https://keybase.io/slack-importer
>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.)