Ga naar de inhoud

Deze pagina is nog niet in uw taal. U leest de Engelse tekst.

Glossary

Password manager

Four parts make one: a store, a key that opens the store, a road into the form, and a way to carry all of it to your other machines. Which of the four you get decides what a break-in costs you.

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.

Put the pair beside the account

Keep the sign-in details with the profile that uses them instead of in a sheet nobody guards.