Cette page n’existe pas encore dans votre langue. Vous lisez le texte anglais.
Glossary
Password manager
A password manager is a program that keeps account credentials under one key and puts them into sign-in forms for you.
The four parts
The word covers products that differ enormously once you look under it. These four questions separate them.
The store
One file or one table holding every pair, which is also the one thing worth stealing.
The key
A passphrase you type, a key held by the operating system, or a key held by the vendor.
The road into the form
An extension inside the page, a helper outside it, or your own two hands and the clipboard.
The way it travels
A vendor's cloud, a folder you own, or nothing at all, and each answer moves the risk somewhere else.
Who can open the store
The interesting question is not whether a store is encrypted but who can open it while you sleep. If the vendor can show you your own passwords after you forget your passphrase, the vendor holds a key.
A key that ships inside a program is not a key at all, because everyone who downloads the program has it. That is why the app here carries none of its own.
What a profile holds instead
A profile can carry the pair for the one account it signs into, next to that account's other settings rather than in a separate sheet. The operating system keychain seals it, and the app adds no key of its own.
Profile settings travel to the server while you are signed in, and the pair is not among them, so a teammate opening a shared profile arrives without it. Two roads take it off this machine. A transfer archive carries it under the passphrase you set, and a plain settings export asks first and leaves the pair out unless you choose to put it in.
Filling a form without handing it over
The value reaches the window only when you press show or fill. Until then the profile list is drawn from the fact that a password exists, so it never rides along with an ordinary redraw.
In the main document, filling runs in a world of its own, where the page cannot swap out the machinery that writes into a field. On a build with no separate worlds it falls back to the page's own, and there the page could. Only frames belonging to the same site are touched, and the password field is chosen by what the form calls it rather than by being first.
Often confused with
The browser's own saved passwords
They live inside one browser profile and follow whoever is signed in to that browser, not the account you meant.
A system keychain
It seals values for programs that ask, and it has no opinion about forms, accounts or sharing.
A team vault
Its point is handing a secret to somebody else, which is a different problem with different failure modes.
Autofill
That is only the last step. Where the value was kept and who could read it is the part that matters.
What this does not do
- ARMANOS is not a password manager. A profile carries one pair, with no vault, no search across accounts and no password generator.
- There is no master password on the app itself. Anyone already signed in to your computer can open it, which makes the user account the boundary that matters.
- The pair is not mirrored to the server, so a profile shared from there reaches a teammate without it. Two roads carry it off the machine: a transfer archive under the passphrase you set, and a plain settings export, which excludes the pair unless you choose otherwise.
- Nothing checks a password for strength or against a list of known leaks. What you type is what is kept.
Check it
Every claim above has a file behind it, and most have a stand that fails when the claim stops being true.
- The pair is sealed by the system keychain, and a value that will not open is not erased
- apps/desktop/src/lib/profiles.js · apps/desktop/test/login-in-keychain.js
- No call that sends profile settings carries the pair, and the list reaches the window without the password
- apps/desktop/test/login-stays-local.js
- Filling reaches only frames of the same site, and a secret never reaches the run log
- apps/desktop/src/main/main.js · apps/desktop/test/подстановка-входа-в-свои-рамки.js
- Files holding secrets are written for the owner alone and whole
- apps/desktop/src/lib/secureFile.js · apps/desktop/test/secrets-on-disk.js
Questions
- Should I keep using my password manager?
- Yes. A profile holds the pair for the account it signs into, and everything else you sign into still belongs in a manager.
- Does the pair go to your server?
- No. The settings mirrored while you are signed in are name, group, scenario, fingerprint template and generation, proxy, tags and notes, and the pair is not one of them.
- Can a page steal the value as it is typed in?
- In the main document the writing comes from a separate world with machinery the page cannot touch, unless the build has no separate worlds, and then it falls back to the page's own. It sees only the events a person at the keyboard would produce. Inside a frame the writing runs in the page's own world, and only frames of the same site are reached.
- What happens if the keychain cannot open it?
- The sealed form is kept rather than replaced by emptiness, and the app hands over nothing instead of handing over something unreadable that a site would refuse.
- Why not keep the pair in a spreadsheet?
- Because a sheet is open to everything on the machine and to every copy of itself, and because picking the wrong row is how a password reaches the wrong account.
Next to this
Put the pair beside the account
Keep the sign-in details with the profile that uses them instead of in a sheet nobody guards.