ID.me
An idea I've been carrying since 2022.
Not a product. Not a pitch. I had my email hacked and realised my database password was the same one. That scared me. So I started thinking — what if the hash changed every time you logged in? What if there was no phone in the loop? What if recovery was built on something you actually lived?
This is me finding out if that holds up.
This is a starting point.
I built it to see if the idea holds up — and it can grow with the community. If you have something to say, I'd love to hear it. If you think I'm missing something, tell me. If you want to take this further — with me or without me — I'm open to that conversation.
I'm not a security company. I'm one person with an idea and working code behind it. Still building. Not done.
A quick honest note — some things here might not work perfectly yet. I'm building this in my spare time alongside two jobs, and I haven't had the chance to test every flow end to end. If something breaks, doesn't respond the way you'd expect, or feels off — please let me know. I genuinely want to hear it. I'll fix it as soon as I can. Thank you for understanding, and thank you for being here.
The short version
I had this idea since 2022. It sat in my head for a long time — one of those things you keep thinking about but never build.
Then my email got hacked. And I realised my database password was the same as my email password. I know — not acceptable. But it happened. And it scared me, because if the database had leaked too, everything would have been out there. Every user's data. Plain and readable.
That's what finally made me build this. Not because I think I've invented something new — I haven't. I'm combining a few existing ideas in a way that I think makes sense. I talked to a couple of people about it in 2023. Nothing came of it. Now, thanks to AI helping me bring it to life, here it is.
I'm doing this in my spare time. Two jobs, real life. No timeline. No deadlines. Just building when I can. If it takes a while, it takes a while.
Three problems I kept thinking about
Your hash is already stale
Databases get stolen. That's the most common breach. I kept thinking — what if every time you logged in, the password hash changed? What if an old database snapshot became useless the moment you logged in again?
No phone. No app. No SIM swap.
SIM swaps, phone loss, interception — I wanted to see if I could take the phone out of the equation entirely. No authenticator apps either. Just things you know.
Recovery built on what you lived
People forget passwords. But they don't forget the things that happened to them. I thought — what if recovery was built on something you actually lived, not something you memorised?
The idea, step by step
No jargon where I can avoid it. If you're technical, the detail is underneath each step.
Three secrets at once
To log in, you need your nick, a secret number I'm calling ID.me, and your password. You enter all three together. If any one of them is wrong, it just says "authentication failed" — no hints about which one was off.
Why this matters
Most systems tell you "username not found" or "wrong password" separately. That helps attackers figure out which usernames exist. Here, everything is checked simultaneously. Same error. Same response time. No signal for an attacker.
Your secret number picks the method
Your ID.me isn't just checked — it also selects 1 of 1,024 ways to mix your password with the salt before hashing. That choice is never stored in the database. Re-calculated from your ID.me every time you log in.
Why this matters
If someone steals the database, they don't even know which of 1,024 mixing methods was used for your account. They'd have to try all of them for every password guess. That's 1,024 times more work on top of the slow hashing.
The hash changes every login
Every successful login generates new salt using the current timestamp and context, mixes your password with it again, and stores a completely new hash. The old one is gone.
Why this matters
A database snapshot from yesterday won't match what's there today. Even if an attacker is actively trying to crack your hash, you just need to log in once and their work starts over from zero. The encryption key for the salt material lives on the server — not in the database.
Nothing stored in plain text
Your email is hashed. Your nick is hashed. The salt material is encrypted with a key that lives on the server, not in the database. There's no way to read your information by looking at a database row.
Why this matters
In most breaches, the attacker gets a database dump. Here, that dump contains only hashes (one-way, can't be reversed) and encrypted blobs (useless without the server's key). No emails for spam lists. No usernames to try elsewhere.
Recovery from your story
When you register, you write something personal — a memory, a moment. The story itself is never stored. Only hashed fragments of meaningful words from it. To recover: your seed phrase (16 random words shown once) plus answers to questions drawn from your own life.
Why this matters
No phone number to SIM-swap. No authenticator app to lose. Recovery is built on two things: something you were physically present for (the seed phrase, shown once at registration) and something only you lived (your story). Both are needed. Neither is stored as readable text.
You can see what gets stored
During registration, there's a live panel showing the shape of every hash and encrypted blob that represents your account. Nothing is hidden from you. You can see for yourself that no plaintext passwords, emails, or stories are kept.
Why this matters
Transparency. I don't want anyone to just trust me when I say "your data is safe." I want them to see it. The panel updates in real time as you type — what you're giving me and exactly what gets stored. Judge for yourself.
What's stored. What's not. What it means.
If someone steals this database tomorrow, here's what they actually get — and what they don't.
What sits in the database
What's NOT in the database
What an attacker has to break through
Not solved problems — just how I'm thinking about them
Database breach — the salt is encrypted, the hash rotates, and you'd need three secrets plus the master key
Weak passwords — ID.me adds a second secret that an attacker has to guess alongside the password
SIM swap — there's no phone in the loop at all
Enumeration — generic errors and padded timing make it harder to fish for valid usernames
Credential stuffing — a leaked password on its own won't get anyone in
Email exposure — hashed, not plain text. A database leak doesn't hand it to spammers
What this does not defend — and I want to be honest about this:
If the server itself is fully compromised (master key + pepper leak together with the database), a lot of this collapses. Client-side malware, phishing of all three secrets, physical-device attacks — all out of scope. This is a prototype and an idea. Not production-ready. I'm still learning.
I'm not building this alone in a corner
If you've got anything to say about this — express it. If you've got a better idea, or a way to push this further, I'd love to hear it. If you want to work on this with me, or even take parts of the idea and run with it without me — I'm open to that conversation.
I'm particularly interested in talking about: how to protect users' data in databases better, how to protect passwords without relying on phones, and whether this idea of a newsletter subscription that doesn't store your email in the database is actually feasible.
This is one person's idea. I'm not a security researcher. I'm not a cryptographer. I'm a self-taught coder who had a thought and decided to see if it works. The code is real. The concept is working. Whether it's good enough — that's what I need other people to tell me.
This is a starting point.
Try it. Break it. Tell me what's wrong with it. Tell me what's right with it. I'll keep building.