A Decade of Distrust: My Experience with Chrome Password Manager

This is the 13-year journey that resulted in Neulock, a different approach to password management. Here goes articles[0] of articles.length == 2.

Part I

It was back in 2011. Contagion was still movie material; people communicated using monochromatic doodle faces instead of Pepe the Frog and Shiba Inu doges, and Daenerys Targaryen was the little girl who made the barbaric Khal Drogo find love.

Run, Drogo! Run everyone! Image by Tina Riordan on Pinterest.

It was then that Google Chrome first made that offer.

Do you want Google Chrome to save your password for this site?

Save this password? Is that a thing browsers do now? Wow, thanks, Chrome, that’s so convenient! Come to think of it, I type most passwords on a web browser, so this looks like a great place to save them.

Besides, what’s the worst that can happen? Chrome is a program installed on my computer. MY computer! I’m a seasoned Debian Linux power user, and nowhere in the universe is there a safer place than my hard drive!

Sure, Chrome, go ahead. Save this password, and the next one, and every password I type in your input fields.

Deception

Until I bought another computer. After ditching the pre-installed Windows for whatever Linux distro I fancied at the time, the next thing to do was install Chrome. Firefox Quantum was still six years away, so there wasn’t much choice.

Sign in with your Google account? Sure, why not? Let’s go check Facebook or whatever, and… hey, do you remember my username, Chrome? All right, let’s sign in to Facebook. Wait, why is the password field already filled in with asterisks? No, dear Chrome, this must be a bug, I’ve just bought this computer, your local database is pristine. You’ll realize your mistake once I click the login button. And… I’m in?

I went to check Chrome settings immediately. What I saw only increased my horror. All the websites and usernames I had been saving were there, on a list. Plaintext passwords were only a click away.

Two expectations had been broken. The first and most important thing is that I never expected Chrome to upload my passwords to Google’s servers without asking for consent. They asked me to save my passwords, not to share them!

My face when I realized Chrome had been uploading my passwords

The second expectation was wishful thinking on my part. Shame on me. Google is one of the coolest tech companies in the world, and its engineers are supposed to be geniuses doing the impossible between ping-pong matches at the Googleplex. I thought Chrome was storing my passwords in some super-secure fashion and only retrieving each password at the right time to inject it like a ninja in the precise input field where it belonged. I didn’t expect to see them all in plaintext.

And I wasn’t the only one who was shocked. Elliott Kember called Chrome’s password security “insane”. In a further discussion, Justin Schuh, Chrome’s chief of security, just shrugged it off in a rather arrogant manner. Sir Tim Berners-Lee took Kember’s side, calling Chrome’s password manager “a way to get your big sister’s passwords.”

After this experience, I never got myself to trust any password manager, even though I knew it was better than confabulating weird passwords in my stupid human head. But, as we say in Brazil, a dog who’s been bitten by a snake fears even sausages. It doesn’t make more sense in Portuguese.

A better password manager

I spent the next ten years wandering in the desert of password insecurity. I was longing for a better password manager, but all of them seemed to follow the same principle: bundle up all your passwords in a “vault,” encrypt it with your master key and upload this vault to their cloud servers. I could never trust this model. Are they implementing end-to-end encryption, right? Is there a “key recovery” backdoor waiting to be exploited? Or maybe Justin Schuh was right after all: your passwords are “trivially recovered” from any application that stores them, and attempts to make passwords harder to leak are “all just theater.” In this sense, trying to safeguard your passwords any further than trusting a password manager was a novice fool’s errand.

In 2019, I landed in the IT Department at the Ministry of Foreign Affairs of Brazil. There, I shadowed the CTO and tech guru Fabio Cereda. I learned a great deal from him and took over after he left. Cybersecurity was always on the agenda since that Ministry produced about 80% of all classified information in the Brazilian Federal government, and its operations were spread over 240 locations in all habitable continents. We were constantly targeted by the world’s scariest acronyms, so we needed to keep our guard up at all times. Over those years, through constant exposure to problems in different domains of cybersecurity, I started to put together principles for a better password manager.

Principle #0: all cryptography is broken or eventually will get broken

There was a museum of diplomatic communications where I worked. It was full of code books, cast-iron cipher machines, suitcase-portable dish antennas, TELEX adapters, and a few specimens of the infamous Crypto AG C-52 machine. It was a showcase of one and a half-century of secret communications between the headquarters and Brazilian embassies and diplomatic missions abroad. All of them relied on some sort of crypto to hold the secrets. All of that crypto is now broken.

This thing was secretly owned by the CIA. Credit: Rama / Wikimedia Commons

If you think about a password manager, the fact that all crypto will eventually get broken isn’t scary. Let’s say it takes, on average, 15 years to break a cryptographic protocol. Just change your passwords every couple of years, and you’ll be fine. A decent password manager should upgrade its crypto every now and then so you’ll always stay ahead of the curve.

The scary part is that it’s impossible to know if a protocol has been broken already. Or worse, if it was designed with an intentional, hidden vulnerability, as was the case with the Crypto AG machine. Intelligence agencies and cybercriminal organizations keep their zero-days under the radar for as long as they can.

The more I saw last-gen, corporate-grade security systems leaking secret information, sometimes in catastrophically spectacular manners, the less I trusted the vault model employed by all cloud-based password managers.

Until very recently, these concerns were merely theoretical. As fellow hackernooner @hossam26644 wrote,

There is nothing wrong with using Google’s password manager, Microsoft, Apple, 1password, Bitwarden, or whatever. People have been using them for long, with zero problems till now.

He was right on July 25th, 2022. He didn’t trust any of them, though, and he was right again. One year later, there was compelling evidence that the notorious LastPass leaks were resulting in some high-value vaults getting cracked and people losing money. Over 150 people, over $35 million in money.

A common misconception is that for an encrypted vault to be cracked, the AES algorithm itself would need to be compromised. LastPass has reminded us how much easier it is to break encryption. AES stands strong, but LastPass made poor implementation decisions: too short master key requirements, too few iterations, and some users were left with vaults that were easily crackable by brute force.

Principle #1: logistics are often the weakest security link

Government cryptanalysts knew Principle #0 all too well. They are some of the most intelligent people I’ve ever met, and few of them would put money on something protected by cryptography alone.

The most wary of them insisted on the use of a One-Time Pad (OTP) for critically secure communications. In fact, they put this requirement in the regulations for the transmission and storage of top-secret documents.

In principle, an OTP cypher cannot be broken. It is a simple XOR operation of the plaintext (the data) and a buffer of random values of the same length as the data (the OTP key). By XOR’ing the cipher against the same key again, the plaintext is recovered.

Although unbreakable from a cryptanalysis standpoint, the OTP has several inconveniences:

• Each OTP key can never be reused;
• An OTP key must be at least as long as the plaintext;
• The key is symmetrical and must be pre-shared between the sending and the receiving parties.

For a worldwide organization, supplying every office with OTP keys is a large ongoing logistical operation. Even worse, it’s the Achilles’ heel of the whole security model! Because, for all of OTP’s crypto-awesomeness to hold true, you need perfect logistics, both in-transit and at-rest.

Say hello to a diplomatic pouch. International law and little else protect it from tampering. Credit: Anfecaro / Wikimedia Commons

Should Eve intercept your OTP keys while on the road to the destination? All your communications from that point on are compromised.

Should Eve physically crack your safe room and steal your OTP key media? All your comms from that point on are compromised, and maybe even your previous ones, if used portions of the key had not been properly erased from the media.

If you implement OTP keys as 1 GB chunks of random bytes that get consumed as you send information, it clearly lacks both forward and backward secrecy.

In the end, the perfect crypto is a way to shift responsibility from the cybersecurity team to the physical security team.

And a similar problem affects offline password managers: they trade-off availability for confidentiality, leaving you with a logistical mess to sort out.

As anyone running a local copy of KeePass knows, you need to backup your vault. This backup had better be external in case your computer storage dies. You need to keep your backup up-to-date. And make sure nobody has access to it. And don’t keep them all in your house, lest they fall prey to flood and fire. And don’t upload them to Google Drive; otherwise, you’re not using an offline password manager anymore. And…

Your backup is being uploaded to the cloud. Image generated by Adobe Firefly

Principle #2: when a user device is compromised, it’s game over

One day, my boss called me. She wanted to share a PDF with ten people from the upper echelon. This information should remain in their eyes only for three days. She knew that they had incentives to share this document with their respective teams to get a head start. This sort of information should be presented in person, but covid. So, she asked me to make this PDF impossible to copy and share.

— Can’t be done, I replied.

My boss was an Ambassador. This is the diplomatic equivalent of a General. Ambassadors aren’t used to hearing “no” as an answer.

I patiently explained that, in computer science, when you give someone read permission to a resource, you implicitly give them permission to copy and distribute. Information access rights don’t obey legal rights. Even if we somehow made it inconvenient to share the file, they could just take pictures of their screens with their phones and share them over WhatsApp. If they can see the document on the screen, so can their cameras.

Justin Schuh was right. If someone gains full access to your computer (or phone), they have full access to the information that you, the user, can access through that device. He’s right, but that doesn’t excuse him for implementing such a lousy password manager on Chrome.

Who never embedded Back Orifice to warez and pwn their friends just for LOLz? Source: nestor.minsk.by

For a password manager, it means that protecting the user’s device is always critical. If the server leaks, the attackers still need to go through the challenge of cracking the vaults. But if a hacker gains complete ownership over the computer running the password manager client, there’s nothing stopping them from stealing all passwords.

This happens quite often in the crypto community. User Alice has a few dozen BTC, which makes her a millionaire. She has been doxxed or never hid her identity in the first place. She keeps a copy of her seed phrase in a local password manager on her desktop. “This is not a cloud password manager; I’m safe from leaks,” she thinks. Hackers find a way to make her install a backdoor to her computer. If they’re really good, they can do this without user interaction. The next morning, she wakes up to an empty wallet.

For all the doom and gloom about user device compromise, there’s a silver lining: protecting our own devices, as users, is something that’s within our control. A server leak is not. The 150+ people who lost millions to the LastPass server leak bore no responsibility for the leaks or for LastPass implementing inadequate encryption standards.

If user device compromise is a catastrophic attack vector no matter the password manager security model, and if we, as users, must protect our devices anyway, wouldn’t it be nice if this were the only attack vector? If we could build an online password manager where no secrets ever leave the user devices so that users don’t need to worry about things out of their control, like server security and AES implementation details?

The ingredients are on the table

Fellow author @hossam26644 continued, on his article: “maybe I am a security freak, but I don’t want to trust my passwords to an entity, regardless of their promises &/reputation”. He’s right again. Cybersecurity is supposed to be proven and auditable, not based on trust and reputation.

The three principles outlined above guided my development of Neulock Password Manager. It took me three years of ideation and iterations to arrive at its current form: an auditable cloud-based password manager that achieves zero knowledge by design and not through encryption. Passwords are synced across user devices using the cloud, but no secrets ever leave these devices. Cloud server compromises cannot leak any secrets because secrets never reach the cloud.

The three years of the making of Neulock will be documented in Part II.

---

This article was originally published by Lucas Neves on HackerNoon.