LayerT whitepaper
Share access, not passwords
Most companies have logins that several people use: the social media accounts, the bank portal, the payroll service, the admin console of a tool nobody set up single sign-on for. Their passwords end up in a spreadsheet or a chat thread. Everyone who has ever needed the account knows them. When someone leaves, somebody is supposed to change them all.
LayerT’s answer is to share access rather than the password. This paper explains how that works, why each step is built the way it is, and where the approach stops.
The model
A shared account in LayerT has four parts.
- A sealed secret. The password and, if the vendor uses them, the authenticator seed, encrypted and stored by LayerT.
- A policy. Who may use it, whether they need an approver each time, whether one person holds it at a time, and how long a session lasts.
- A sign-in recipe. Where the sign-in fields are on the vendor’s site, detected automatically or recorded once by the account’s owner. It never contains a value.
- A trail. Every request, approval, sign-in, extension and sign-out, attributed to a person.
A person never receives the account. They receive a session: a time-boxed, logged permission to be signed in, which LayerT carries out for them.
Sealed storage
Secrets are encrypted with AES-256-GCM envelope encryption. Each shared account has its own random 256-bit data key. The password and the authenticator seed are each encrypted under it with a fresh random nonce, and the data key is itself encrypted (“wrapped”) by a key-encryption key. The database stores ciphertext only, in its own table, separate from the account’s settings.
Changing a password re-encrypts both secrets under a brand-new data key, and is logged. Deleting an account deletes its secrets.
The key-encryption key is held on LayerT’s servers today. Moving it into a managed cloud key service, where it can be used but not extracted, is in progress Coming soon.
From request to session
- BrowserAsk or pickFrom the LayerT icon in the sign-in field, or the toolbar launcher. One-click accounts skip approval.
- Console or popupApproveFor medium and high sensitivity. Nobody approves their own request, and approval re-checks the requester is active and entitled.
- LayerT cloudSession opensBound to the person and their enrolled browser, with an end time. One holder at a time, if set.
- BrowserSigned inLayerT fills the vendor’s form. A chip shows it’s a LayerT session and the time left.
- BrowserSession endsOn time, by an admin, or at offboarding. LayerT signs the person out of the site.
Requests that nobody decides expire after 30 minutes. If two approvers decide at the same moment, only one decision counts. Sessions last one hour by default and can be extended up to eight hours in total from approval.
The grant
The moment of truth is when a password leaves storage. LayerT decrypts a secret only when all of these are true:
- the session is active and hasn’t expired,
- it belongs to the person asking and to the browser they enrolled,
- the person is still active in your directory and still entitled to the account, and
- the account hasn’t been disabled.
Only then does the server decrypt the password, in memory, and return it over HTTPS in a grant for that session. Each grant is logged with the person, the account and the device. The password and any authenticator code never appear in the log.
Filling without showing
The grant goes to LayerT’s service worker, which hands it to the page only if the page is the account’s exact site: same scheme, host and port, over HTTPS, no wildcards. The check uses the address Chrome reports for the requesting frame, not anything the page says about itself.
The fill runs from Chrome’s isolated world, the separate space where extension scripts run alongside a page. LayerT refuses to fill fields that are hidden, transparent, off-screen or read-only, which guards against decoy fields. A password only ever goes into a password field.
LayerT never shows the password: not in the launcher, the menu, notifications or the audit log. When it signs someone in, it doesn’t write the password to the browser’s storage.
To stop Chrome itself offering to save the shared password into someone’s profile, switch off Chrome’s built-in password manager by policy. LayerT’s deployment templates include that setting.
Submitting, carefully
Filling is not the same as submitting. Auto-submit is off by default, and an owner can switch it on only after the account passes a test sign-in. Even then, LayerT submits only when:
- the person explicitly picked the account,
- the page is the exact site and path, in the top frame,
- every field LayerT filled is still visible, and
- LayerT found the submit button without guessing.
It never submits on page load. A CAPTCHA pauses LayerT and hands over to the person.
Authenticator codes
Many vendor accounts use authenticator codes. LayerT keeps the seed on its servers and generates codes there (RFC 6238). Only the current six-digit code travels to the browser, when needed, and it’s filled like a password. A leaked code expires in seconds, and the seed never reaches a laptop.
Ending on time
Access that doesn’t end isn’t governance. LayerT ends sessions in three ways:
- On schedule. A minute before the end, the person can extend or sign out. At the end, LayerT clears the site’s cookies and the tab’s site storage.
- By an admin. An Owner or IT Admin can end a live session from the console, with a reason. The server stops honouring the session at once, and the browser signs out within about a minute.
- At offboarding. When your directory deactivates someone or removes them from a group, LayerT revokes their sessions and requests everywhere.
Break-glass
Sometimes a person genuinely needs the password itself, for example to change it at the vendor. LayerT makes that deliberately hard:
- Revealing a password needs two people: an IT Admin or Owner asks, and a different one approves. The password is then marked for rotation, and the event is logged.
- For disaster recovery, an offline export is encrypted and split between two custodians, each with their own passphrase. Neither can open it alone. Generating one is logged.
How this compares
| Shared spreadsheet | Password manager sharing | LayerT | |
|---|---|---|---|
| People see the password | Yes | Usually yes, and can copy it | No. LayerT fills it |
| Approval before use | No | Rarely | Optional, per account |
| Time limit | No | No | Every session |
| One holder at a time | No | No | Optional |
| Who used it, when | No | Partly | Every request, approval and session |
| Access ends at offboarding | Only if you change every password | Only if you remove sharing and rotate | Automatically, from your directory |
Limits
- The authorised person could read a filled password with DevTools, as described above.
- Sign-in forms inside cross-origin frames don’t get the in-page menu; use the toolbar launcher. Forms drawn on canvas aren’t supported.
- Automatic password rotation isn’t built.
- Real-time alerts for reveals and exports aren’t built yet Coming soon. Both are in the audit log.
Want to see it on your own vendor portals? Request a demo, and bring your hardest shared account.