Om het gebruiksgemak te vergroten, de website te kunnen analyseren en om advertenties te kunnen beheren maakt Security.NL gebruik van cookies. Door gebruik te blijven maken van deze website, of door op de akkoord button te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer weten over cookies? Bekijk dan ons cookieoverzicht.
Nieuws Achtergrond Community
Inloggen | Registreren
Nieuws
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

Consumentenbond: commerciële dna-tests slordig met privacy
Burgemeesters willen experimenteren met internetverbod
Reacties (9)
Reageer met quote
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
Reageer met quote
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.
Reageer met quote
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?
Reageer met quote
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++ :)
Reageer met quote
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.
Reageer met quote
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 ;-).
Reageer met quote
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.
Reageer met quote
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.
Reageer met quote
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
Ondersteunde bbcodes
Bold: [b]bold text[/b]
Italic: [i]italic text[/i]
Underline: [u]underlined text[/u]
Quote: [quote]quoted text[/quote]
URL: [url]https://www.security.nl[/url]
Config: [config]config text[/config]
Code: [code]code text[/code]

Je bent niet ingelogd en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.

Je reactie is verstuurd en wordt zo spoedig mogelijk gemodereerd.

Verder
captcha
Nieuwe code
Preview Reageren
Zoeken
search
Vacature
Image

Senior Security Consultant

Als security consultant bij Cegeka speel je een uitermate belangrijke rol in het veilig houden van de bedrijven in Nederland en de Nederlandse maatschappij. Vandaar ook dat Cegeka dit hoog op de agenda heeft staan. Wij doen dit door, in close cooperation, onze klanten advies te geven op strategisch, tactisch en operationeel niveau.

Lees meer

Wat baart jou momenteel meer zorgen, traditionele criminaliteit of cybercrime?

12 reacties
Aantal stemmen: 1002
Image
BYOD
04-03-2021 door Anoniem

Wanneer mensen een eigen device (BYOD) mee nemen naar werk: hoe bescherm jullie je daartegen? (Ben zelf tegen het gebruik van ...

19 reacties
Lees meer
Is een laptop die via de werkkostenregeling wordt vergoed een privélaptop?
03-03-2021 door Arnoud Engelfriet

Juridische vraag: Bij ons bedrijf is gekozen voor bring-your-own-device, waarbij mensen zelf privé een laptop mogen kopen en ...

19 reacties
Lees meer
De verkiezingsprogramma's doorgelicht: Deel 4 digitalisering
20-02-2021 door Redactie

Een digitaal paspoort, recht op betaalbaar en snel internet, 'digitale inburgering' of digitaal stemmen, het zijn slechts een ...

8 reacties
Lees meer
Certified Secure LIVE Online training
Nieuwe Huisregels en Privacy Policy

Op 5 december 2017 hebben we een nieuwe versie van onze huisregels en privacy policy ingevoerd. Om verder te kunnen gaan dien je eenmalig akkoord te gaan met de nieuwe huisregels van Security.NL.

Op 24 mei 2018 hebben we, in het kader van de AVG, onze privacy policy bijgewerkt. Om verder te kunnen gaan dien je eenmalig akkoord te gaan met de bijgewerkte privacy policy. Heb je vragen neem dan contact op met info@security.nl.

Verzenden
Privacy Policy

Op 24 mei 2018 hebben we, in het kader van de AVG, onze privacy policy bijgewerkt. Om verder te kunnen gaan dien je eenmalig akkoord te gaan met de bijgewerkte privacy policy. Heb je vragen neem dan contact op met info@security.nl.

Verzenden
Inloggen

Bedankt! Je kunt nu inloggen op je account.

Wachtwoord vergeten?
Nieuwe code captcha
Inloggen

Wachtwoord Vergeten

Wanneer je hieronder het e-mailadres van je account opgeeft wordt er een nieuwe activatielink naar je gestuurd. Deze link kun je gebruiken om een nieuw wachtwoord in te stellen.

Nieuwe code captcha
Stuur link

Password Reset

Wanneer je het juiste e-mailadres hebt opgegeven ontvang je automatisch een nieuwe activatielink. Deze link kan je gebruiken om een nieuw wachtwoord in te stellen.

Sluiten
Registreren bij Security.NL

Geef je e-mailadres op en kies een alias van maximaal 30 karakters.

Nieuwe code captcha
Verzenden

Registreren

Je hebt je succesvol aangemeld. Voordat je je account kunt gebruiken moet deze eerst geactiveerd worden. Dit kan je zelf doen middels de activatielink die naar het opgegeven e-mailadres is verstuurd.

Sluiten
Over Security.NL
Huisregels
Privacy Policy
Adverteren
© 2001-2021 Security.nl - The Security Council
RSS Twitter