Så fungerar det

Det finns ingen backend. Tillägget är ett Chrome-tillägg med Manifest V3 som genererar TOTP-/HOTP-koder lokalt med OTPAuth. Vi driver inga servrar, har inga konton och saknar kanal genom vilken användardata skulle kunna nå oss.

Eftersom det inte finns någon server finns inte heller något nyckelmaterial på serversidan, ingen nyckeldeponering och ingen återställningsväg som vi kontrollerar. Om en användare glömmer lösenordet och tappar bort återställningskoden kan vi inte hjälpa till — så är det tänkt.

Lösenordsskydd är valfritt och av som standard. När det är på:

Kryptering

AES-256-GCM, slumpmässig 96-bitars IV per post och per omskrivning

Nyckelhärledning

PBKDF2-HMAC-SHA256, 600 000 iterationer, slumpmässigt 128-bitars salt (enligt OWASP)

Huvudnyckel

256 bitar, från crypto.getRandomValues, genereras en gång; lösenordet omsluter den bara

Fingeravtryck

HMAC-SHA256 under en HKDF-härledd undernyckel, används för att slå ihop poster mellan enheter

Lagring av upplåst nyckel

chrome.storage.session — endast i minnet, skrivs aldrig till disk, rensas när webbläsaren stängs och är oåtkomlig för content scripts

Automatiskt lås

Vid varje öppning / efter 5, 15 eller 60 minuters inaktivitet / tills webbläsaren stängs

Implementation

Enbart WebCrypto. Ingen primitiv är egenskriven och inget kryptobibliotek paketeras.

Data krypteras aldrig direkt med en nyckel härledd ur lösenordet. En slumpmässig huvudnyckel krypterar posterna; PBKDF2-utdata omsluter bara den huvudnyckeln. Två följder av det, och båda spelar roll:

• Att byta lösenord skriver om 32 byte i stället för att kryptera om varje post, varje säkerhetskopia och varje export. Det är just vid sådana massomskrivningar som lagringssystem tappar data.
• En 160-bitars återställningskod kan omsluta samma huvudnyckel oberoende, så ett glömt lösenord går att ta sig förbi. Koden visas en gång, måste skrivas in igen för att bekräftas och byts ut efter varje användning. Ingenting skrivs till disk förrän användaren har bekräftat den.

Med lösenordsskydd på krypteras hela kontoposten utom dess identifierare och fingeravtryck — inklusive tjänstens namn, så en stulen profil avslöjar inte vilka tjänster användaren har konton hos. När skyddet slås på krypteras posterna, verifieras genom att dekrypteras och jämföras, och först därefter tas varje kopia i klartext bort: webbläsarens lokala lagring, synk och alla sju roterande säkerhetskopior.

Kort sagt: det här skyddar data i vila. Det försvarar inte, och kan inte försvara, en enhet som redan står under en angripares kontroll medan den används.

Manifestet deklarerar exakt två behörigheter och inga värdbehörigheter:

storage

Konton och inställningar i lokal lagring, den upplåsta nyckeln i sessionslagring och den valfria synkkopian

activeTab

Läser den aktiva flikens värdnamn för att lyfta fram rätt konto, och fångar fliken när användaren skannar en QR-kod från skärmen

Det finns inga content scripts, inga tabs-, cookies- eller webRequest-behörigheter och inga web-accessible resources. Tillägget kan varken läsa eller ändra innehållet på någon sida.

QR-skanning med kameran körs på en tilläggssida i en flik, inte i popupen — en popup förstörs när den tappar fokus, vilket är precis vad en behörighetsfråga gör. Det här kräver ingen behörighet i manifestet: det använder webbläsarens vanliga kamerafråga, som ges per tilläggs-origin och kan återkallas i webbplatsinställningarna, och den kommer aldrig förrän användaren öppnar skannern. Video avkodas lokalt och skickas eller sparas aldrig.

Vid normal användning gör tillägget inga automatiska anrop, och Manifest V3 förbjuder fjärrkod. Alla anslutningar det över huvud taget kan göra:

Inga typsnitt, skript, stilmallar eller bilder laddas från tredjepartsvärdar. Allt som behövs för att rita upp gränssnittet ligger i paketet.

Ingenting av ovanstående behöver tas på förtroende. Tillägget är öppen källkod och varje release går att återskapa:

1. Ladda ner den publicerade .crx från Chrome Web Store och packa upp den
2. Checka ut motsvarande git-tagg
3. Kör npm ci && npm run build på Node 20 LTS
4. Jämför den resulterande dist/ med det uppackade paketet

Med varje GitHub-release publiceras en SHA-256 för varje fil i den byggda dist/, som SHA256SUMS-v<version>.txt och i sha256sum-format, så steg 4 blir en enda körning av sha256sum -c. Skillnader bör begränsas till filordning inuti arkiv och blanktecken i minifierad utdata mellan Node-patchversioner.

Körtidsberoendena är medvetet få — OTPAuth, React, jsQR, Zustand, Framer Motion och Lucide — låsta av en incheckad lockfil. En CycloneDX-SBOM finns på begäran.

Vi är en liten oberoende leverantör. Om något av följande är ett absolut krav i er process är det bättre att ni vet det nu än tre veckor in i en utvärdering:

• Ingen SOC 2-, ISO 27001- eller motsvarande certifiering
• Inget externt penetrationstest beställt hittills
• Inget betalt bug bounty-program

Det vi erbjuder i stället är full insyn i källkoden, ett verifierbart bygge, en minimal behörighetsyta och ingen serverinfrastruktur som skulle kunna hålla era data till att börja med.

Sårbarhetsrapporter och säkerhetsfrågor: security@authenticator.sh. Vår policy för ansvarsfullt röjande, omfattning, svarstider och safe harbour-villkor finns på sidan säkerhetspolicy; vad som lagras och vad som lämnar enheten står i integritetspolicyn.

Vi svarar gärna på ett skriftligt leverantörsformulär eller går igenom koden tillsammans med ett säkerhetsteam.

För allt som inte rör säkerhet — installation, kontoåterställning, faktureringsfrågor vid en utrullning — se support. Skicka inte sårbarhetsrapporter dit; den brevlådan hanteras inte som konfidentiell.