Why we'll never store your password to check it

The obvious path, the wrong one

Most security apps ask you to hand over your passwords. They need them to check if those passwords have been exposed in breaches, or if they're too weak, or if you're reusing them across sites. The logic is straightforward: to scan a password, you have to see it.

What happens next is less straightforward. That password gets stored somewhere. Maybe it's encrypted. Maybe it's in memory only. Maybe it's synced to a server. Maybe it's deleted after the scan. Maybe it isn't. And now you've introduced a new vulnerability: the very thing that was supposed to protect you has become a liability.

When we started designing the password health feature for Shield, I kept thinking about the customers who'd already been breached. They'd come to ARK because they wanted to know if their details were out there. The last thing they needed was to hand a password to another company and hope that company handled it better than the one that failed them the first time.

What we do instead

The password health check in Shield doesn't ask for your password. It asks for a hash of your password. Your phone computes that hash using a one-way algorithm. We receive the hash, never the password. We compare it against the Have I Been Pwned database. If there's a match, you know your password has appeared in a breach. If there isn't, you know it hasn't.

The difference sounds technical, but it's practical. A hash is cryptographic one-way; even if someone intercepted it, they couldn't reverse it back to your actual password. We can't see it. We can't store it. We can't accidentally sync it somewhere. Your phone never transmits the password itself.

This is also why we never ask you to scan 'all your passwords at once' from a vault or export file. Some apps do that. They take a CSV of your passwords and run them through their system. We don't because storing that file, even briefly, is a risk we chose not to take.

The deeper reason

There's a phrase I've heard a lot in tech: 'We're serious about security.' Usually it means strong encryption, or a compliance badge, or a blog post about their security practices. All fair. But to me, it means this: don't collect what you don't need to keep.

Most of what ARK does happens on your device. Your 0-100 security credit score is calculated locally. The stalkerware detector runs on your phone. The permissions audit happens offline. We're not hoovering up data and shipping it to a server so we can analyse it later or, worse, so we can profile you.

The password health check is just an extension of that philosophy. Yes, we need to talk to the HIBP API to check for breaches. But we do it in a way that keeps your actual password entirely on your phone. It stays there. It doesn't travel. It doesn't sit on our servers.

When you're privacy-conscious, you don't just think about what happens if we're hacked. You think about what happens if we're subpoenaed, or if someone inside the company makes a mistake, or if we get acquired by someone with different values. The safest password is one we never see.

What this means for your other accounts

The password health feature works within clear limits. It tells you if a password you've used has been in a known breach. It doesn't tell you whether that password is strong; that's a matter of complexity and length, which your phone can check locally without us. It doesn't tell you how many times you've reused it across sites; that would require us to have access to all your passwords, which we don't and won't ask for.

If you want more comprehensive password management, you need a password manager. That's not ARK. We're a security health scanner. We check your device, your network, your apps, your data exposure. Password managers are a different product with a different job. They should be companies you trust with that specific responsibility, and you should evaluate them on their own security practices.

What we can do is tell you whether a password you know has been compromised. We can flag if you're using weak passwords in your phone's saved credentials. We can audit your 2FA setup to make sure you've actually enabled it where it matters. But we do all of that without ever needing to see, store, or transmit your actual passwords.

Why this matters more than you might think

I've read a lot of security incident reports over the past few years. Most of them start the same way: 'An unauthorised third party gained access to our systems.' Then the company walks through what was exposed. What surprises me, every time, is how many companies were storing sensitive data they didn't actually need to keep.

Passwords are the obvious one. Unencrypted user data is another. Session tokens in plain text. Copies of information that was supposed to be deleted months ago. The pattern is always the same: someone collected something because it was easier than designing the system not to, and then that 'something' became the thing that got people harmed.

ARK is built to be the opposite. We collect what we need to give you a real security score. We store it where it's least likely to be accessed without your knowledge. When we can't keep something completely local, we use encryption that even we can't decrypt. And when we don't need to collect something at all, we don't ask for it, even if it would make our product slightly more convenient to build.

That's a choice, not an accident. It's a choice we made before we launched, and it's a choice we'll make again every time we add a new feature.