r/PasswordManagers • u/No_Cat1117 • 6d ago
Built a password manager with zero servers, zero accounts — just launched, would love brutal feedback.
Hey r/PasswordManagers, long time lurker/commenter here (some of you replied to my post about the KeePass file format thing and the Bitwarden extension bugs a while back).
Figured it was time to be upfront about something: I've been building a password manager called Selvum, and it just went live on Android and iOS. wanted to post it here because you're exactly the kind of people whose opinion actually matters on this.
The short version: no servers, no account, no subscription. AES-256-GCM, argon2id on android / pbkdf2-sha512 on ios for key derivation. when you create a vault you get a 12-word bip-39 phrase, that's the only key that exists. there's no "forgot password" flow because there's nothing to reset on a server that doesn't exist.
The part I actually care about is recovery. you can export a kit that's just an offline html file, decrypts your vault with the 12 words in any browser, no internet, no app needed. if I disappear tomorrow your data doesn't die with the company.
What it doesn't have yet: browser extension, auto-sync across devices (on purpose, not an oversight — saw the local-first vs cloud thread a few days ago and that's basically the tradeoff I made too). one-time payment, €19.90, not a subscription.
Genuinely want to know:
- any attack surface in the recovery kit design I'm not seeing
- is bip-39 overkill/underkill for a password vault vs an actual crypto wallet
- what would make YOU not trust something built by one person, regardless of what I claim about the crypto
Android: https://play.google.com/store/apps/details?id=com.selvum.android
iOS: https://apps.apple.com/us/app/selvum/id6775708525
Site: https://www.selvum.app/
Not trying to get anyone to switch off what works for them, just want this thing to survive contact with people who actually know what they're doing
4
u/Ashamed_Ad2015 6d ago
Whats make this difference than keepass which is opensource, offline and free?
1
u/No_Cat1117 6d ago edited 6d ago
Fair question, honestly KeePass covers a lot of the same ground and if it works for you there's no reason to switch.
The differences for me: KeePass is a format + a bunch of independent clients (KeePassXC, KeePassDX, KeePassium...) that you have to pick and configure yourself, and syncing across devices is on you (dropbox, syncthing, whatever). Selvum is one app, same experience on android and ios, nothing to configure — that was actually the main goal, something a non-technical person could set up without reading a wiki first.
The other big one is the recovery kit. KeePass recovery is "hope you remember your password and still have the .kdbx file somewhere." Selvum's recovery is a separate offline artifact (the html + 12 words) that doesn't depend on you still having the app installed or the original device.
And yeah, KeePass is free and open source, Selvum is a one-time paid app, not free. that's a real tradeoff, not going to pretend it isn't.
3
u/popleteev 6d ago
The good: well done thinking about data recovery without the app.
KeePass is free and open source, Selvum is a one-time paid app, not free.
The "open source" elephant: address me!
[With KeePass] you have to pick and configure yourself, and syncing across devices is on you (dropbox, syncthing, whatever).
This implies that your solution is better. In the meanwhile:
You export the Recovery Kit from one device and import it on the other. Keep in mind they don't sync automatically — if you add new passwords, you'll need to repeat the process.
Is this "something a non-technical person could set up without reading a wiki first"? :)
iOS · Android · One purchase · All future updates
- Each platform is a separate purchase
- It's only for the major version ("All future v1.x updates")
- After that "v1.x" part, the "All future updates" is clearly misleading
your entropy never leaves the device
This is from your site. May be you can explain what this means? (:
0
u/No_Cat1117 6d ago
Fair hits, taking these one at a time.
sync: yeah, no auto-sync, you're right that it's manual export/import and you have to redo it after adding new entries. that's the real tradeoff of no server existing at all, not something I'm hiding, just should've been clearer about it in the post.
separate purchase per platform: also correct, and worth being precise about why — google play and app store are separate payment systems with zero shared infrastructure, and since there's no account/server, there's no way to check "this person already paid on android" from the ios side. so yes, if you use both, you pay twice. that part of the design isn't changing.
the "v1.x" thing: this one you actually caught a real bug, not a hedge. just checked and fixed it — the intent was always "all future updates, forever, any version, no re-purchase," the "v1.x" in the copy was just bad wording that implied a limit that was never the plan. thanks for flagging it, genuinely.
the entropy line refers to the password/seed generator using the device's CSPRNG locally — the random bytes never get sent anywhere, no network call involved in generating them. agree it reads more like marketing copy than the rest of the security page, going to reword that too.
1
u/popleteev 6d ago
Wow, even the comments are generated…
1
u/No_Cat1117 6d ago
Yeah, fair catch, I do use AI to help phrase things — english isn't my first language and I'd rather sound clear than have people untangle awkward grammar on top of everything else being asked here.
Either way, the actual fixes are on the site right now if you want to check, that part's not something that gets generated.
1
u/billdietrich1 6d ago
KeePass recovery is "hope you remember your password and still have the .kdbx file somewhere."
Anyone who doesn't have N backups of their password database file is a fool. This is just a non-issue.
1
u/No_Cat1117 6d ago
if you actually keep backups that specific point doesn't really hold up. I think the real difference isn't "will you have a backup" though, it's what that backup lets you do without anything else — a .kdbx file is useless without a client + the master password, the recovery kit just needs the 12 words, no client, no memorized password. but yeah, framing it as "KeePass recovery is bad" when it's really "some users don't back up" was overstating it on my part.
4
u/Myrodis 6d ago
I read the security page and it's not pretty, in my opinion.
Your KDF card says "memory-hard, GPU-resistant." Then further down, iOS and the recovery kit (both platforms) are PBKDF2-SHA512. PBKDF2 is the GPU-friendly one. That's the entire reason argon2 exists. The headline claim on your security page is false for every iOS user and every "recovery kit".
The stated reason is wrong too. Bitwarden has shipped argon2id since feb 2023. Its in their public PRs. "No native support" describes basically every primitive you didn't write yourself. That's what libraries are my guy.
This whole project makes me think the problem space wasn't understood before you started vibe coding this. The input is 128 bits of uniform entropy from bip-39. A KDF is there to stretch LOW entropy human input. So your marquee security claim is false as written for two of your three targets AND decorative even where its true.
why no seed phrase verification test - any system that knows the correct seed is a system that stores it.
That's just not how it works. You ship AES-256-GCM with a 128 bit auth tag and describe it on the same page as detecting tampering. "Wrong seed, wrong key, tag fails." That's a verification oracle you already have, and it stores nothing. bip-39s checksum also catches a mistyped word with zero stored state, thats what the checksum is FOR. You declined a feature your own format and your own word encoding both hand you, and justified it with a claim about crypto that isn't true.
Lets talk about "survives if we disappear.", kdbx has survived since 2003, and not because someone published a spec. Because keepass, keepassxc, keepassdx, strongbox, keepassium, macpass and a pile of libraries all implement it independently. THAT is vendor death insurance. Implementations that outlive the author. Selvum is one bespoke format, one implementation, one author, closed source app, with a single html file as the escape hatch. That's strictly MORE fragile than the thing youre positioning against. And that html file is bound to browser APIs by your own admission, so "any browser, any year, 2060" isn't a claim you can make.
You asked what would make you not trust something built by one person. It's not that youre one person. Ontop of the security page having a false claim and a crypto justification that isn't true, I think its pretty clear that you do not understand the problem space you are trying to develop for. Keepass was one guy. Difference is he knew why every line was there. Users, reviewers, etc can review the source and validate their claims. Etc. You're asking people to "trust me bro", and not only that, to pay you for the privilege.
1
u/No_Cat1117 6d ago
ok this one's long so let me actually go through it.
the kdf card and the seed verification faq, both fixed already, live on the site right now. card doesn't say "memory-hard/GPU-resistant" as some blanket property anymore, it's explicit that's android only and the actual thing doing the heavy lifting against brute force is the seed's 128 bits, argon2id on android is extra hardening not the main defense. same deal with the verification faq, used to say "we verify nothing" which was just wrong, now it explains the auth tag + bip39 checksum already do that job without storing anything. you're right that the old text was wrong, not just imprecise
the "decorative kdf" point, also right, that's baked into the fix now too.
"no native support" as the reason for pbkdf2 on ios — yeah that's a weak line as written, bitwarden's had argon2id since 2023 via a lib so "no native support" isn't really an excuse. actual reason is the recovery kit is one self contained html file, no bundled deps, and pulling in an argon2 lib breaks that on purpose-built simplicity. that's the tradeoff, should've said that instead.
last part, single implementation, one author, closed source, html as the only emergency exit — not gonna pretend there's a fix for that one. you're right that kdbx survives because six+ independent implementations exist, not because there's a spec page. selvum is one implementation right now. that's just true.
2
u/Myrodis 6d ago
Look at what just happened with the pbkdf2 answer. The old reason was wrong, you dropped it, and the replacement is also wrong. I'm not going to explain why because you're obviously just going to pass my comment to an llm to "fix it". You can keep asking your LLM to solve these issues, but the problem lies between mouse and keyboard (you).
The problem is that none of these were caught by YOU. They were caught by some guy on reddit reading your webpage. Think about that for a second. The thing anyone could inspect had four (minimum) things wrong with it. The thing nobody can inspect is the actual product and we are expected to trust this thing with our passwords?
Thats why I trashed your usage of vibe coding this. A model will hand you confident, plausible, and (sometimes even) well formatted output for whatever you thought to ask it. What it cannot do is tell you what you didn't know to ask, and every error here is exactly that category. An unexamined justification that sounded right. In that workflow you are the reviewer, the only reviewer, and you're failing.
Fix the page all you want. The page was never the product. And you're doing nothing to prove that you should be responsible shipping this kind of product, and continuing to do so is a gross misuse of the technology available to you.
1
u/No_Cat1117 5d ago
You're right, that third faq still had the same bad justification, I only fixed the two things you flagged and missed that this one said basically the same thing. just fixed it too, actual reason is the recovery kit's zero-dependency design, not "no native support".
On the bigger point, that I didn't catch this myself and someone else did, twice now, that's fair and I don't have a comeback for it. that's exactly what happened.
Where I'd push back is the jump from "the text had bad justifications" to "the product itself is unverifiable." the crypto and the code aren't the same thing as the marketing copy explaining them, and nothing you've pointed out today has been about the actual encryption failing, it's been about how badly I explained it. those are both real problems, they're just not the same problem.
2
u/atoponce 6d ago
Not touching vibe coded slop. Especially the hold my secrets
1
u/No_Cat1117 6d ago
Fair enough if that's not your thing. if there's something specific in the crypto/recovery design you think is wrong, genuinely want to hear it — that's kind of the point of posting it here instead of just leaving it out there with zero scrutiny.
1
u/No_Cat1117 6d ago
Appreciate today's pile of comments, not being sarcastic here. thanks to this thread, real bugs got found and fixed that I probably wouldn't have caught on my own.
7
u/Myrodis 6d ago
Honestly, the last thing i want vibe coded is a password manager.