image

Chromium Edge gaat voor gestolen wachtwoorden waarschuwen

maandag 30 maart 2020, 20:41 door Redactie, 9 reacties

Microsoft heeft een nieuwe feature voor Chromium Edge aangekondigd die gebruikers waarschuwt als één van hun wachtwoorden bij een website is gestolen. De feature heet Password Monitor en vergelijkt wachtwoorden die in de browser zijn opgeslagen met wachtwoorden die bij websites zijn gestolen. Wanneer Chromium Edge ontdekt dat het wachtwoord van de gebruiker is gestolen krijgt die een waarschuwing te zien.

In de waarschuwing staat informatie over de website in kwestie en een link om het betreffende gestolen wachtwoord te wijzigen. Via een dashboard is het mogelijk om een overzicht van alle gestolen wachtwoorden te krijgen en van welke websites gebruikers de waarschuwing hebben genegeerd. Gebruikers moeten de feature straks wel zelf inschakelen. Standaard staat die namelijk uitgeschakeld. Microsoft verwacht dat Password Monitor de komende maanden aan de testversie van Chromium Edge wordt toegevoegd. De nieuwste Edge-versie is op Chromium gebaseerd, de door Google ontwikkelde opensourcebrowser die de basis voor Chrome en andere browsers vormt. De feature zal niet in de oude Edge-versie verschijnen, die standaard met Windows 10 wordt geleverd.

Waar Microsoft de informatie over gestolen wachtwoorden vandaan haalt is nu nog niet bekendgemaakt, alsmede hoe de feature technisch werkt. Google Chrome en Mozilla Firefox beschikken al over een dergelijke feature. Mozilla maakt hiervoor gebruik van de datalekzoekmachine Have I Been Pwned. Google liet alleen weten dat de dataset die het gebruikt meer dan 4 miljard gestolen wachtwoorden bevat.

Wanneer gebruikers bij Chrome inloggen verstuurt de browser een "anonieme hash-prefix" van de inloggegevens naar Google. Vervolgens wordt in een database naar alle anonieme hash-prefixes gezocht die overeen komen met die van de gebruiker. Vervolgens wordt er lokaal op het systeem van de gebruiker naar de volledige hashes gekeken en welk wachtwoord hierbij hoort. Als laatste krijgt de gebruiker de waarschuwing te zien en het verzoek om zijn wachtwoord te wijzigen.

Image

Reacties (9)
31-03-2020, 09:38 door Erik van Straten
Welja, laten we hashes ook van nog niet gestolen wachtwoorden naar Internet roeptoeteren zodat die hashes (bijv. via onbeveiligde S3-buckets of gehackte have-I-been-pwned servers) in foute handen vallen en worden gekraakt.

Goed idee dit! NOT
31-03-2020, 09:56 door Prx
Door Erik van Straten: Welja, laten we hashes ook van nog niet gestolen wachtwoorden naar Internet roeptoeteren zodat die hashes (bijv. via onbeveiligde S3-buckets of gehackte have-I-been-pwned servers) in foute handen vallen en worden gekraakt.

Goed idee dit! NOT

Als de implementatie net zo is als die in Chrome, waarmee dus de anonymity implementation gebruikt wordt, dan zie ik er weinig gevaar in.

https://www.troyhunt.com/ive-just-launched-pwned-passwords-version-2/

In dat geval gaat namelijk niet de hele hash over de lijn heen, maar dus alleen de eerste 5 chars. Daarna is het aan de client om te implementeren en te controleren dat de daadwerkelijk ingevoerde hash niet overeen komt.
31-03-2020, 11:07 door Anoniem
Als Chrome en Firefox het al ook doen, waarom moet er dan weer negatief gedaan worden als Windows Edge hetzelfde gaat doen?
31-03-2020, 11:17 door Anoniem

Als de implementatie net zo is als die in Chrome, waarmee dus de anonymity implementation gebruikt wordt, dan zie ik er weinig gevaar in.

https://www.troyhunt.com/ive-just-launched-pwned-passwords-version-2/

In dat geval gaat namelijk niet de hele hash over de lijn heen, maar dus alleen de eerste 5 chars. Daarna is het aan de client om te implementeren en te controleren dat de daadwerkelijk ingevoerde hash niet overeen komt.

Daar is wel wat op af te dingen. Stel je hebt 3 wachtwoorden, eerste 5 posities worden verstuurd:

1: aaaaa[aaaaaaaaaaaaaaaaaaaaaaaaaaa]
2: bbbbb[bbbbbbbbbbbbbbbbbbbbbbbbbbb]
3: ccccc[ccccccccccccccccccccccccccc]

Google (of MS) doet look-up en stuur alle wachtwoorden die matchen op aaaaa, bbbbb en ccccc terug, bijvoorbeeld 3 potientele wachtwoorden per stuk. Clientside wordt vastgesteld dat 1 van de 3 opties voor aaaaa klopt. Deze wijzig je: nieuwe hash is dddddddddddddddddddddddddddddddd. Volgende keer dat je een check doet wordt niet aaaaa maar ddddd verstuurd. Daarmee weet Google dat het aaaaa gelekt was en in de set van drie zit. Misschien niet relevant meer voor account 1, maar wel voor de rest als de wachtwoorden erop lijken (doen de meeste mensen). Google, en anderen die dit mechanisme gebruiken, kunnen dus een custom wachtwoordlijst maken voor jouw profiel. Datamining++ :)
31-03-2020, 11:50 door Erik van Straten - Bijgewerkt: 31-03-2020, 11:55
TL;DR: Ook met een tot 20 bits "beperkte" lengte van een hash van een wachtwoord geef je enorm veel prijs over dat wachtwoord. Sowieso kunnen cybercriminelen hierdoor enorme aantallen mogelijke wachtwoorden uitsluiten.
Aanvankelijk zullen nog niet veel mensen hun "foute" wachtwoord hebben gewijzigd, en is de kans groot dat de hash van hun wachtwoord nog wel voorkomt in de haveibeenpwnded database. Later worden aanvallen nog eenvoudiger, namelijk doordat cybercriminelen ook nog eens de "foute" wachtwoorden (in de haveibeenpwned database) kunnen uitsluiten.

Details
Troy Hunt maakt volgens mij een grote denkfout. In https://www.troyhunt.com/ive-just-launched-pwned-passwords-version-2/ staat onder meer:
The SHA-1 hash of that string is "21BD12DC183F740EE76F27B78EB39C8AD972A757" so what we're going to do is take just the first 5 characters, in this case that means "21BD1". That gets sent to the Pwned Passwords API and it responds with 475 hash suffixes (that is everything after "21BD1") and a count of how many times the original password has been seen.
[...]
Now keep in mind that as far as I'm concerned, the partial hash I was sent could be any one of 475 different possible values. Or it could be something totally different, I simply don't know and therein lies the anonymity value.

For the sake of perspective, here are some stats on what this means for the data within Pwned Passwords:

1. Every hash prefix from 00000 to FFFFF is populated with data (16^5 combinations)
2. The average number of hashes returned is 478
3. The smallest is 381 (hash prefixes "E0812" and "E613D")
4. The largest is 584 (hash prefixes "00000" and "4A4E8")

Een aanvaller die de eerste 5 nibbles (hexadecimale karakters, elke waarvan 4 bits representeert) in handen krijgt, weet het volgende:
A) Ofwel je gebruikt een "slecht" wachtwoord dat bekend is bij HaveIBeenPwned, dan zijn er gemiddeld 478/2 = 239 pogingen nodig om in jouw account in te breken. Nb. veel te weinig servers implementeren een account lockout policy die zo'n aanval binnen een realistische tijdspanne (enkele weken voor een high profile account) onmogelijk maakt;
B) Ofwel je gebruikt een "goed" wachtwoord dat niet bekend is bij HaveIBeenPwned.

Juist ALS je al enige tijd een browser gebruikt die hierop checkt, is de kans groot dat het NIET gaat om een wachtwoord als bedoeld achter A). Aanvallers kunnen dan volstaan met het maken van een rainbow tables van wachtwoorden die NIET voorkomen in de database van HaveIBeenPwned, te beginnen met korte wachtwoorden, maar denk hierbij ook aan (voor de hand liggende) passphrases bestaande uit bekende woorden.

Voorbeelden
1) De SHA-1 hash van "1Gehe!m" (zonder "") is D3031CD314B1948127DCA31C5AFF8140875BE9EA en komt niet voor in https://downloads.pwnedpasswords.com/passwords/pwned-passwords-sha1-ordered-by-hash-v5.7z die ik op 2019-07-23 gedownload heb (uitgepakt ca. 24GB). In die file komen 543 regels voor die beginnen met "D3031".

Is "1Gehe!m" daarmee een goed wachtwoord (d.w.z. was dat zo voordat ik het hier publiceerde)? Volgens dit systeem wel - totdat een cybercrimineel leert dat de eerste 5 karakters van de SHA-1 hash van mijn wachtwoord "D3031" zijn EN weet dat ik Chromium Edge gebruik en dus dat het waarschijnlijk niet een van die 543 gelekte wachtwoorden is. Dat scheelt een boel onnodige brute force pogingen!

2) De SHA-1 hash van "I like football!" is 78EBED76F31C727A3430002B52518351DDF94470. Ook deze komt niet voor in die file. Wel komen er 472 regels in voor die beginnen met "78EBE". Dit soort passphrases zijn m.i. best voor de hand liggend (vervang football door andere sporten, namen etc. - er staat welliswaar geen cijfer in, maar wel een hoofdletter en een leesteken - waarmee het aan veel password policies zal voldoen).

Conclusie: zie de TL;DR: bovenaan. Een veel gemaakte fout door ICT-ers die denken te beveiligen is dat ze niet omgekeerd denken en niet vanuit het perspectief van een aanvaller redeneren. Iets dat, toegegeven, best lastig is, maar wel noodzakelijk; anders schiet je -voor je het weet- in je eigen voet. Ik vermoed dat, zoals zo vaak, het risico onvoldoende wordt meegenomen dat die 5-char-lange-hashes in verkeerde handen kunnen vallen, en/of men denkt dat een aanvaller toch niets heeft aan "maar" 5 karakters.

Door Anoniem: Als Chrome en Firefox het al ook doen, waarom moet er dan weer negatief gedaan worden als Windows Edge hetzelfde gaat doen?
Je mag me negatief noemen, maar ik wil graag goed beveiligen. En ik wist niet dat Chrome en Firefox dit al deden, ik zal er eens induiken.
02-04-2020, 12:57 door eMilt
Door Erik van Straten:Is "1Gehe!m" daarmee een goed wachtwoord (d.w.z. was dat zo voordat ik het hier publiceerde)? Volgens dit systeem wel - totdat een cybercrimineel leert dat de eerste 5 karakters van de SHA-1 hash van mijn wachtwoord "D3031" zijn EN weet dat ik Chromium Edge gebruik en dus dat het waarschijnlijk niet een van die 543 gelekte wachtwoorden is. Dat scheelt een boel onnodige brute force pogingen!

Allereerst, hoe zou een cybercrimineel moeten uitvinden wat de eerste 5 karakters van de SHA-1 van jouw wachtwoord is? De request gebeurd over https dus dan zou hij/zij al in je browser moeten zitten op die request te kunnen onderscheppen (en dan ben je toch al de Sjaak).

Ten tweede: stel dat hij inderdaad die request en ook nog de response ziet. Wat bewijst dat dan eigenlijk? Laten we inderdaad aannemen dat je hieruit de conclusie kan trekken dat de SHA-1 hash van jouw wachtwoord dus inderdaad niet bij die 543 hashes zit. So what? 543 gevallen die het niet zijn terwijl er nog een miljard-triljoen-miljoen-weet-ik-veel hashes die het nog wel kunnen zijn. Je hebt slechts 20 bits van de 160 bits van de hash vrijgegeven met die request. Van die 1,39 x 10^42 combinaties kan je er dan vast 543 wegstrepen. Dat helpt ;-).
02-04-2020, 15:34 door Erik van Straten
Door eMilt:
Door Erik van Straten:Is "1Gehe!m" daarmee een goed wachtwoord (d.w.z. was dat zo voordat ik het hier publiceerde)? Volgens dit systeem wel - totdat een cybercrimineel leert dat de eerste 5 karakters van de SHA-1 hash van mijn wachtwoord "D3031" zijn EN weet dat ik Chromium Edge gebruik en dus dat het waarschijnlijk niet een van die 543 gelekte wachtwoorden is. Dat scheelt een boel onnodige brute force pogingen!

Allereerst, hoe zou een cybercrimineel moeten uitvinden wat de eerste 5 karakters van de SHA-1 van jouw wachtwoord is?
Zie mijn eerste bijdrage bovenaan deze pagina. Ik schreef niet voor niets in mijn bijdrage die jij gedeeltelijk aanhaalt:
Door Erik van Straten: Ik vermoed dat, zoals zo vaak, het risico onvoldoende wordt meegenomen dat die 5-char-lange-hashes in verkeerde handen kunnen vallen, en/of men denkt dat een aanvaller toch niets heeft aan "maar" 5 karakters.

Het zou mij enorm verbazen als die 5-char hashes niet door de derde partij(en), die ze in handen krijgen, worden bewaard voor statistische doeleinden. De verleiding is dan groot om ook het logon-ID daarbij te bewaren. Ook een foute (evt. omgekochte) beheerder die snapt wat ik snap (en jij kennelijk niet) zou dit kunnen doen. De lijst van incidenten waarbij partijen "per ongeluk" vertrouwelijke gegevens bleken te bewaren, is lang genoeg om te weten dat dit niets met "onbedoeld" te maken heeft.

Door eMilt: De request gebeurd over https dus dan zou hij/zij al in je browser moeten zitten op die request te kunnen onderscheppen (en dan ben je toch al de Sjaak).
Natuurlijk ben je de Sjaak als jouw browser niet safe is (dan weet de aanvaller meteen jouw wachtwoord i.p.v. de hash ervan of een deel van die hash). Het gaat, vanzelfsprekend lijkt mij, om de infrastructuur andere kant van de https verbinding.

Door eMilt: Ten tweede: stel dat hij inderdaad die request en ook nog de response ziet. Wat bewijst dat dan eigenlijk? Laten we inderdaad aannemen dat je hieruit de conclusie kan trekken dat de SHA-1 hash van jouw wachtwoord dus inderdaad niet bij die 543 hashes zit. So what? 543 gevallen die het niet zijn terwijl er nog een miljard-triljoen-miljoen-weet-ik-veel hashes die het nog wel kunnen zijn. Je hebt slechts 20 bits van de 160 bits van de hash vrijgegeven met die request. Van die 1,39 x 10^42 combinaties kan je er dan vast 543 wegstrepen. Dat helpt ;-).
Lees je eens in op rainbow tables. Die vul je hooguit met hashes van alle mogelijke permutaties van karakters in zeer korte wachtwoorden, maar bij voorkeur met hashes van typisch door mensen gekozen wachtwoorden (ongeacht de wachtwoordlengte).

Als mensen absoluut random wachtwoorden van 12 chars of zo zouden gebruiken, zouden rainbow tables onrealistisch groot worden. Het feit dat rainbow tables succesvol zijn komt doordat de meeste mensen totaal niet creatief zijn bij het bedenken van wachtwoorden.

Overigens gebruik ik Firefox ESR en daar zit deze "feature" nog niet in. Wel in Firefox 70 en later, maar alleen als je LockWise gebruikt - en dat doe ik sowieso niet. Overigens lijken de 5-char hashes naar monitor.firefox.com te gaan, die domeinnaam had eergisteren een IP-adres van Google (ik heb vandaag niet gecheckt).

Het is simpelweg onverstandig om welke informatie dan ook over jouw wachtwoorden met derden te delen. Hooguit kun je zoiets lokaal draaien. Met een bloom-filter hoeft de database ook niet zo gigantisch groot te zijn (hoe kleiner, hoe meer false positives), en bovendien is het niet zo heel erg als je een wachtwoord hergebruikt dat iemand anders ooit voor één account gebruikt heeft.

Ik vermoed dat het een stuk veiliger is als je lokaal checkt op de 10.000 meest gebruikte wachtwoorden, dan dat je 5 karakters van de SHA-1 hash van jouw wachtwoord naar een derde partij stuurt - zeker als je niet precies weet wie die derde partii is (of partijen zijn) en dus ook geen idee hebt of je die partij(en), diens mederwerkers en de beveiliging van de gebruikte systemen kunt vertrouwen.
02-04-2020, 21:14 door Anoniem
Door Erik van Straten: Welja, laten we hashes ook van nog niet gestolen wachtwoorden naar Internet roeptoeteren zodat die hashes (bijv. via onbeveiligde S3-buckets of gehackte have-I-been-pwned servers) in foute handen vallen en worden gekraakt.

Goed idee dit! NOT

Er zijn ondertussen zoveel gestolen wachtwoorden, dat elke mogelijke hash prefix van 5 van de 32 karakters meer dan 200 resultaten weergeeft.
03-04-2020, 06:09 door Erik van Straten
Door Anoniem:
Door Erik van Straten: Welja, laten we hashes ook van nog niet gestolen wachtwoorden naar Internet roeptoeteren zodat die hashes (bijv. via onbeveiligde S3-buckets of gehackte have-I-been-pwned servers) in foute handen vallen en worden gekraakt.

Goed idee dit! NOT

Er zijn ondertussen zoveel gestolen wachtwoorden, dat elke mogelijke hash prefix van 5 van de 32 karakters meer dan 200 resultaten weergeeft.
Als je even verder had gekeken dan jouw anonieme neus lang is, had je in een volgende reactie van mij hierboven kunnen zien dat dit zelfs 381 is.

En dan had je ook mijn argumenten kunnen lezen waarom ik denk dat het "hoe meer, hoe slechter" is in deze situatie.

Iets wat ik fout kan hebben en graag inhoudelijk over wil discussiëren, maar dit soort onbenullige reacties halen mijn theorie niet onderuit - integendeel: de meeste mensen gebruiken hun hersens niet of onvoldoende bij security-vraagstukken. Reageerders hier maar helaas ook bedenkers en implementeerders van dit soort "beveiligingsmaatregelen".
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.