Maak kennis met BreachWatch van Keeper

BreachWatch is een krachtige, veilige add-on die het internet en het dark web controleert op gelekte accounts die overeenkomen met records die zijn opgeslagen in uw Keeper Vault.

BreachWatch biedt de meest uitgebreide bewaking voor het publiek en heeft een database van meer dan een miljard records, terwijl de geavanceerde zero-knowledge beveiligingsarchitectuur van Keeper blijft behouden.

Overzicht

BreachWatch waarschuwt u, zodat u direct actie kunt ondernemen om uzelf te beschermen tegen hackers. Na activatie controleert BreachWatch voortdurend op gecompromitteerde inloggegevens. We houden meer dan een miljard bekende wachtwoorden bij en voegen voortdurend nieuwe gegevens toe wanneer er inbreuken worden ontdekt op het dark web.

Registreren

Registreren is eenvoudig. Ga vanaf uw mobiele apparaat naar het BreachWatch-scherm en volg de instructies op het scherm. U kunt BreachWatch ook rechtstreeks kopen op de website van Keeper Security.

Na registratie voert BreachWatch een lokale scan van wachtwoorden uit die momenteel zijn opgeslagen in uw Keeper-kluis. Klanten krijgen een melding als hun accountgegevens overeenkomen met inloggegevens die een hoog risico lopen.

Functies van BreachWatch

1. Klanten krijgen automatisch een melding als een wachtwoord in hun kluis overeenkomt met een gelekt wachtwoord.
2. Het gelekte wachtwoord wordt in de app hersteld door het wachtwoord op de getroffen site of dienst te rouleren.
3. Keeper houdt de resolutiegeschiedenis bij van elk gelekt wachtwoord voor historische controle.

Demovideo

Bekijk hier hoe BreachWatch werkt op iOS:

BreachWatch is ook beschikbaar in de Keeper Webkluis en Desktop-app:

Beveiligingsarchitectuur van BreachWatch

Beveiligingsoverzicht

BreachWatch is een zero-knowledge architectuur die een aantal gelaagde technieken gebruikt om de gegevens van onze klanten te beveiligen. Samengevat:

1. Een veilige, versleutelde, cryptografische hash-functie en anonimisering (hieronder beschreven) worden gebruikt om wachtwoorden te vergelijken met een database met gelekte accountgegevens.

2. Wachtwoorden van klanten worden verwerkt met een hardwarebeveiligingsmodule (HSM) en een niet-exporteerbare geheime sleutel voordat ze worden gecontroleerd op gelekte wachtwoorden of worden opgeslagen op BreachWatch-servers.

3. Klanten van Keeper communiceren met BreachWatch via geanonimiseerde BreachWatch-ID’s die niet gekoppeld zijn aan andere Keeper-klantidentificatoren.

4. BreachWatch scheidt gebruikersnamen en wachtwoorden in aparte services met afzonderlijke, geanonimiseerde ID’s om gebruikersnamen en domeinen los te koppelen van wachtwoorden.

5. Klanten van BreachWatch uploaden nooit domeingegevens; ze downloaden alleen domeinen (de veiligste manier om persoonlijke gegevens op te vragen).

Afbeelding 1. Het pad van de gehashte wachtwoordgegevens van een klant via BreachWatch. Alleen wachtwoorden die zijn versterkt met een HSM en een niet-exporteerbare sleutel worden opgeslagen op BreachWatch-servers. Klanten van BreachWatch gebruiken geanonimiseerde ID’s wanneer ze communiceren met BreachWatch-servers.

Gelekte accounts veilig identificeren

Het privé vergelijken van klantgegevens met een grote database van gelekte gegevens is een technische uitdaging. De oplossing moet zowel veilig als efficiënt berekenbaar zijn met de huidige middelen, waaronder rekenkracht en bandbreedte. Over het algemeen is dit een concreet voorbeeld van een privé-set snijpunten of een probleem met het ophalen van privé-informatie. Klanten van Keeper hebben een lokale database met domeinnamen, gebruikersnamen en wachtwoorden. BreachWatch heeft een grote database met dezelfde items. Een essentiële vereiste van onze oplossing is een beveiligingsmodel dat kan bepalen welke wachtwoorden kwetsbaar zijn zonder deze gegevens bloot te stellen aan de BreachWatch-service.

De eenvoudigste oplossing voor het probleem van het privé ophalen van gegevens is dat de app van de klant de dataset downloadt en de vergelijking lokaal uitvoert. Dit is haalbaar voor domeinvergelijkingen (kleine set), maar de set van gelekte gebruikersnamen en wachtwoorden bestaat uit meer dan een miljard datapunten. Het is niet praktisch of mogelijk om zoveel gegevens rechtstreeks over te zetten naar de apparaten van de klant.

Technieken zoals versleutelde Bloom-filters [1] kunnen de downloadgroottes verkleinen en alsnog verwerken via de klant om de hoogste niveaus van gegevensbeveiliging te behouden. Een Bloom-filter dat over datasets van deze omvang wordt gemaakt, is nog steeds te groot voor de meeste klantapparaten. Bovendien moet het Bloom-filter elke week worden vernieuwd wanneer de database met inbreuken wordt bijgewerkt.

Bepaalde systemen gebruiken k-anonimiteit [2] via ingekorte, ‘unsalted’ wachtwoord-hashes, maar deze techniek is niet veilig. In plaats van wachtwoorden (of wachtwoord-hashes) te uploaden naar de server ter verificatie, uploaden klanten dus een ingekorte hash van elk wachtwoord (bijvoorbeeld de eerste 20 bits) naar de server. Deze ingekorte hash komt overeen met een iets grotere set wachtwoorden die worden gedownload en geverifieerd op het klantapparaat. Het probleem met deze aanpak is dat de grootte van de gedownloade set overeenkomt met de dubbelzinnigheid van de server (of de aanvaller). Als een klant dus honderd wachtwoorden moet downloaden voor elke geüploade ingekorte hash, dan hoeft de aanvaller maar honderd verschillende wachtwoorden te controleren als de ingekorte hash van een klant wordt blootgesteld (of gestolen van een server). Als een aanvaller vijf wachtwoorden per dag kan testen zonder een account te vergrendelen, dan kan hij binnen twintig dagen toegang krijgen tot een account.

Afbeelding 2. Klantdomeinen worden lokaal gecontroleerd: de veiligste techniek in de branche voor het privé ophalen van gegevens.

De oplossing van BreachWatch

Om een veilige service te waarborgen, splitste Keeper BreachWatch op in drie services, namelijk voor het verifiëren van domeinen, gebruikersnamen en wachtwoorden. Klantapplicaties van Keeper nemen contact op met elk van deze backend-services via een versleutelde REST API.

Domeinen controleren

Domeinverificatie is de eenvoudigste oplossing van de drie controles die we uitvoeren. Klanten van BreachWatch downloaden een lijst met gelekte domeinen en voeren de controle lokaal uit. Dit is de eenvoudigste (en veiligste) oplossing voor het privé ophalen van gegevens. Klanten downloaden regelmatig bijgewerkte lijsten van nieuwe domeinen wanneer deze worden toegevoegd aan onze BreachWatch-service.

Gebruikersnaam en wachtwoord

Het verifiëren van gebruikersnamen en wachtwoorden is complexer, omdat deze datasets erg groot zijn. We moeten gebruikersnamen en wachtwoorden offline testen om klanten te kunnen waarschuwen als een nieuw lek een account in gevaar heeft gebracht. Voor deze services maken klantapparaten verbinding met BreachWatch en uploaden een lijst met gehashte gebruikersnamen (of wachtwoorden) net als een door de klant geselecteerde, willekeurige identificatie (afzonderlijke identificatie voor de verificatieservices voor gebruikersnamen en wachtwoorden). Deze wachtwoord-hashes worden bij het uploaden verwerkt met HMAC [3] via een hardwarebeveiligingsmodule (HSM) en een geheime sleutel die is opgeslagen in de HSM en gemarkeerd als niet-exporteerbaar (wat betekent dat de HSM de HMAC alleen lokaal zal verwerken en de sleutel niet kan worden geëxtraheerd). Deze door HMAC ingevoerde gebruikersnamen of wachtwoorden worden vergeleken met de datasets voor inbreuken die met dezelfde HMAC en sleutel zijn verwerkt. Overeenkomsten worden gemeld aan het klantapparaat. Waarden die niet overeenkomen, worden opgeslagen naast de geanonimiseerde ID van de klant.

Wanneer nieuwe gelekte gebruikersnamen en wachtwoorden aan het systeem worden toegevoegd, worden ze verwerkt met HMAC op de HSM, toegevoegd aan de BreachWatch dataset en vergeleken met de opgeslagen klantwaarden. Elke overeenkomst plaatst een bericht voor die klant-ID in de wachtrij.

Klanten melden zich regelmatig aan bij BreachWatch en presenteren hun BreachWatch-ID’s. Berichten in de wachtrij worden gedownload en klanten uploaden nieuwe of gewijzigde gebruikersnamen en wachtwoorden die op dezelfde manier worden verwerkt.

De beveiliging van de BreachWatch-services is trust-on-first-use (TOFU). Klanten moeten ervan uitgaan dat de BreachWatch-server niet kwaadaardig is (dus niet actief gecompromitteerd door een aanvaller) wanneer ze hun gehashte waarden uploaden. Zodra deze waarden met een HSM zijn verwerkt, zijn ze beveiligd tegen offline kraakpogingen. Als een aanvaller dus de dataset met opgeslagen klantwaarden steelt, kunnen deze waarden niet offline worden gekraakt zonder de HMAC-sleutel die is opgeslagen in de HSM.

De veiligste oplossing op de markt

Met Keeper BreachWatch kunnen klanten accounts identificeren en ontvangen ze waarschuwingen over accounts die het risico lopen op een wachtwoordlek. Het uitvoeren van deze controle in een zero-knowledge omgeving is extreem moeilijk om te ontwikkelen, maar het engineeringteam van Keeper stelt de veiligheid van de klant op de eerste plaats.

BreachWatch is veiliger dan systemen die platte (of ingekorte) hashes opslaan of die vereisen dat klanten alle inloggegevens opnieuw uploaden telkens als er een nieuw lek wordt ontdekt. BreachWatch biedt zowel veilige identificatie van inbreuken als sterke beveiliging.

Veelgestelde vragen

Contact

Neem bij vragen over de service Keeper BreachWatch of de beveiligingsinfrastructuur contact op met ons beveiligingsteam via security@keepersecurity.com. Keeper Security beheert een openbaar programma voor het openbaar maken van kwetsbaarheden in samenwerking met Bugcrowd dat kan worden geopend op https://bugcrowd.com/keepersecurity.

Referenties

[1] Privacy-Enhanced Searches Using Encrypted Bloom Filters. https://mice.cs.columbia.edu/getTechreport.php?techreportID=483

[2] https://blog.cloudflare.com/validating-leaked-passwords-with-k-anonymity/

[3] HMAC. https://cseweb.ucsd.edu/~mihir/papers/kmd5.pdf