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.

Als Chrome en Firefox het al ook doen, waarom moet er dan weer negatief gedaan worden als Windows Edge hetzelfde gaat doen?

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++ :)

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:

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.

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.

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 ;-).

Zie mijn eerste bijdrage bovenaan deze pagina. Ik schreef niet voor niets in mijn bijdrage die jij gedeeltelijk aanhaalt:

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.

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.

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.

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".