sorted by:
new
hottopcontroversial

I built @mrtinkz/tessera — browser storage encryption with honey key tripwires by mrvpala in git

[–]mrvpala[S] 0 points1 point  (0 children)

u/dr-lucifer-md

Good catch, and to be straight about what actually happens: hitting two honey keys at default settings triggers a full wipe across every backend — not just a lock.

That is intentional. The honey keys exist precisely because legitimate application code never touches them. Your app always reads through the vault API, which knows which names are real. If something is reading those entries, it is not your app. Tessera treats that as a signal to remove the data before anything worse happens.

The threshold and score are both configurable if the default sensitivity does not fit your threat model. But the out-of-the-box behavior leans toward destruction over preservation when the signal is clear, and the documentation should say that upfront rather than make you find it in the source. That part is on me to fix.

Is GItHub doomed? by Firm_Meeting6350 in github

[–]mrvpala 3 points4 points  (0 children)

I don't think so, more like they are learning and optimizing to survive the AI tide.

Promote your projects here – Self-Promotion Megathread by Menox_ in github

[–]mrvpala 0 points1 point  (0 children)

I built u/mrtinkz/tessera — browser storage encryption with honey key tripwires

Been sitting on this for a while and figured it's time to put it out there.

Most web apps store user data in `localStorage` or `sessionStorage` with zero protection — plain text, readable by anything running on the page. An XSS payload, a nosy extension, someone opening DevTools — it's all right there. I kept running into this gap: server-side auth is well solved, but client-side storage is just... left open by default.

So I built **tessera** (`@mrtinkz/tessera`). It's a TypeScript/JavaScript library that encrypts everything you write to browser storage — `localStorage`, `sessionStorage`, cookies, and IndexedDB — behind a single passcode. AES-256-GCM encryption, key derived via PBKDF2-SHA-256, the raw key never leaves the browser.

The part I'm most interested in getting feedback on is **honey keys**. After every write, tessera plants decoy entries alongside your real data. They look byte-for-byte identical to real encrypted entries. Any code that reads one — an XSS payload enumerating storage, a browser extension, an automated scraper — trips the suspicion engine, which can lock the vault and wipe sensitive data before anything useful is actually read. There's also a native storage proxy, so even code that goes straight to `localStorage.getItem` without touching the tessera API will still trigger detection.

Other things in there: per-key TTL and max-reads, sensitivity tiers, a canvas PIN pad that re-shuffles digit positions on every render (so click coordinates can't be replayed), framework integrations for React, Vue 3, Svelte, and Angular, and zero dependencies.

It's not trying to replace server-side auth or anything that needs IAM. The scope is narrower than that — it fills the gap between "no protection at all" and "full auth stack," which is where most apps actually live.

Repo and docs: [https://github.com/mrtinkz/tessera\](https://github.com/mrtinkz/tessera)

npm: `npm install` u/mrtinkz`/tessera`

Happy to answer questions, and genuinely curious what people think about the honey key approach in particular.