Expanding digital footprints need new approaches to keep data secure
HOW WE GOT HERE
We've been in the security space for a long, long time. At our previous companies, we've built security products, spoken at conferences like Defcon and Black Hat, hacked things, blogged about hacking things, published podcasts about securing things, and even written books on security.
​
We've watched the security space evolve for decades. Yet there is still a long way to go, and there always will be. We built Secret Chest because password managers are mostly small encrypted sqlite3 databases and we felt like the industry could do better. The encryption algorithms themselves could take years to break, but the mechanisms we use to encrypt are often far less secure.
​
Think about it this way - we put our secrets into a single database synchronized between multiple devices, like so.
Then we take them out as a single atomic operation. Whether that's what we want to do or not. Even with MFA or some other security mechanism, we're still putting all our proverbial eggs in one basket. Even if every row uses a different SHA-256 hash, there's plenty of tools that can exfiltrate that data (primarily in use by forensics teams in law enforcement).
It is time to do better. We hate spreading fear, uncertainty, and doubt. That's no way to market or sell a product. We like to think of security like a parent, wrapping their arms around a child. The security mechanisms built into Apple products are like that: robust, secure, and amongst the best in the market, even compared to several third party products that organizations spent plenty of money to buy. That's why we use Apple's built-in mechanisms as our database and build on top of that to provide an added layer of security.
There's a lot of malware and other ways to get at databases of passwords while at rest on a file system. Let's say an attacker manages to gain access to the login keychain. Rather than attempt to break the encryption - it would be far simpler to simply brute force the password to the database itself. There are protections, but only at certain layers. Once unlocked, all the passwords and many keys (the secrets) would be exposed. This is one reason that we never keep a secret that can be reversed in a single place.
​
It's more fun to talk about features. Once secrets are split up, we have a bunch of things we can do. We can escrow a shard, we can put policies around when and how they're used, we can provide enterprises with telemetry about their metadata (e.g. complexity, type, last used, how frequently used, etc). We can allow them to be shared to groups of users or even split up and each shard shared to different users. We can also integrate them with other solutions by providing APIs for everything and webhooks to kick off any workflow we haven't yet thought of (which let's face it is most workflows). In short, we can improve the experience for enterprises, administrators, and end users (let's face it, user security is paramount in user experience).
​
​
What We Built
Our patented techniques are actually pretty simple. We generate elliptical curve key. Then split those into a few parts, which we call shards out of homage to one of the greatest cryptographers of any era, Adi Shamir, from a seminal paper he wrote in 1979.
Actually, that's over-simplifying it. The parts can be put back together with some missing. This means that we can make three keys and reassemble the key with two of them. That way, we can put one on a Mac, one on an iPhone, and one of our servers - or a text file on your computer. Here's the best part, they can live behind the native FaceID and TouchID. That way we can require a biometric factor on two different devices (think of this as three factor authentication).
And our app is a hardened runtime, meaning another process can't just watch for us to decrypt a secret and then grab it out of memory.
​
We remove secrets from stand-alone databases. So when the secret is called rather than simply grabbing it out of the database, we send a push alert from a Mac to an iPhone and reassemble the secret. This makes us immune to brute force attacks, malware injecting into a process, or even a big old quantum computer trying to decrypt a store of passwords and other secrets.
Every new minor evolution in cryptography should be able to stand up to scrutiny. So here's our patent for anyone who wants to help us be better!
Where We're Going
Secrets can mean a lot of things. ​We have filed patents for leveraging similar technology to protect against supply-chain attacks and for larger-scale secret distribution to help protect against the original sins of embedding simple keys into apps at compile-time. Stay tuned for more by subscribing to our email list!
​
FAQS
IT ALL SOUNDS GREAT, BUT WHAT ACTUALLY IS SECRET CHEST UNDER THE HOOD?
We encrypt a password, passkey, or other secret, and then shard the encryption key into multiple parts. The shards are required to reverse the encryption key into a password. Shards are protected by the built-in biometric security options on devices. This means an attacker would need to compromise an iPhone and a MacBook in order to get at your secrets. If that sounds like a lot, just know it's practically instant.
I’VE SEEN OTHER PASSWORD MANAGERS OUT THERE. WHAT MAKES YOURS THE BEST?
We actually work with password managers! To us, getting access to a password manager or federated identity management tool is just another secret that needs to be guarded. And we really, really like guarding secrets!
WILL YOU EVER GIVE MY SECRETS TO ANYONE ELSE?
We can't. We would have to comply with court orders (hasn't happened yet). Users can escrow a shard with us for password recovery (to reverse the sharding and encryption process) or keep a shard on an asset they own. Just remember that if we escrow a key, at least one other device (think of our cloud service as a device) is required to unlock the password. But if we don't have one, we can't help unlock those secrets (we also can't help if a device gets lost).
IS THERE SUPPORT DURING THE BETA?
Yes, and our developers are doing the support, so we can literally make a code change and ship a patch on the fly. I mean, compile and devops build times to run unit tests and all that, but we believe that developers who have some support responsibilities for a product tend to make better products, if only from a selfish perspective. Ultimately, all computing is automation, and if we can automate ourselves out of support calls by fixing some wonky flow, then so be it!