FBI deelt voortaan uitgelekte wachtwoorden met Have I Been Pwned

De FBI gaat uitgelekte wachtwoorden die het tijdens onderzoeken tegengekomen is, in het vervolg delen met de website Have I Been Pwned. Op die manier wil de FBI mensen proactief waarschuwen dat hun wachtwoorden uitgelekt zijn.

Volgens initiatiefnemer Troy Hunt van Have I Been Pwned heeft de FBI onlangs contact opgenomen met hem om samen te werken, wat hij totaal niet had verwacht. De dienst gaat voortaan buitgemaakte wachtwoorden die het tegenkomt bij forensisch en digitaal onderzoek, delen met HIBP via de Pwned Passwords-feature. Op die manier hoopt de FBI meer mensen te bereiken van wie wachtwoorden buitgemaakt zijn.

De wachtwoorden die de FBI met Have I Been Pwned deelt, zullen worden voorzien van een SHA-1- en NTLM-hashparen, zodat ook Troy Hunt de wachtwoorden niet in plain text heeft. Er komt een directe route van de FBI naar HIBP voor het delen van uitgelekte wachtwoorden.

Om de wachtwoorden zo snel mogelijk toegankelijk te maken voor gebruikers, gaat Hunt werken aan een stuk opensourcecode. Hij roept de community op om hem daarbij te helpen. Met dat verzoek maakt Hunt ook bekend dat Pwned Passwords voortaan open source is via de .NET Foundation. Het was al langer bekend dat Have I Been Pwned op termijn open source moest worden.

Tweakers sprak Troy Hunt in januari uitgebreid in een interview, waarin hij vertelt hoe HIBP tot stand gekomen is, hoe hij de site, die inmiddels bijna een miljard maandelijkse requests heeft, nog steeds in zijn vrije tijd draait en hoe hij van plan is om steeds meer van de site te automatiseren.

Reacties (129)

[Falcon]

Wie is eigenljik eigenaar van HIBP en hoe zit dit eigenlijk juridisch? Iemand een idee?

[RobbieB]

Troy Hunt.

Daar lopen ook interessante discussies over bv. in het kader van GDPR, want in de basis verwerkt HIBP persoonlijke data (emailadressen) zonder dat het daar enige vorm van toestemming voor heeft van de eigenaar. Volgens Hunt is hier het publieke belang belangrijker dan de Privacy wet, waardoor hij er mee doorgaat, maar privacy voorvechters vinden dat dit niet correct is, o.a. omdat je van ieder e-mailadres kan zien waar ze een account hebben (indien die site gebreached is geweest).

[Reactie gewijzigd door RobbieB op 23 juli 2024 08:10]

[iam2noob4u]

Het publieke belang hoeft niet belangrijker te zijn dan de AVG. De AVG stelt dat er een grondslag moet zijn. Het publieke belang is in dit geval die grondslag. De vraag is natuurlijk of die voldoende is (lijkt mij van wel), maar die kan alleen een beoordelingsinstantie beantwoorden.

[jdh009]

Vanuit dat oogpunt, Zou hij de site dan niet privacyvriendelijker kunnen maken door een E-mail verificatie in te voeren? Wanneer je iets opzoekt krijg je een mail met een link naar de resultaten.

[Sleepkever]

Dat klinkt wel als een goed idee. Maar voor je privacy is dat natuurlijk wel vrij nutteloos, al die data is namelijk al "publiek" beschikbaar op de uitgelekte lijsten. Het enige wat die site doet is er een mooi frontendje voor zetten op een vertrouwde plek.

[Reactie gewijzigd door Sleepkever op 23 juli 2024 08:10]

[P_Tingen]

Dat is waar, maar HBIP maakt het wel een stuk toegankelijker. Ik zou zo 1,2,3 niet weten waar ik lijsten met uitgelekte ww zou kunnen vinden.

Ik zou me voor kunnen stellen dat er domeinnamen tussen zitten op HBIP waarvan je niet persé wil dat anderen dat weten, pornosites bijvoorbeeld, maar ook domeinen als "benikgayofniet.nl", "ongewenstzwanger.nl" of "soatest.nl". Kan best pijnlijk zijn.

[Reactie gewijzigd door P_Tingen op 23 juli 2024 08:10]

[TjerkH]

Ik heb zojuist op een aantal emailadressen van familie en vrienden gezocht, daarbij ben ik sites/apps tegen gekomen zoals:

MyHeritage
Evony
Dropbox
Lifeboat (Minecraft community)
MyFitnessPal
Canva
Zynga
Money Bookers
Apollo (sales engagement)

Dit zijn zo'n 6 personen, waarbij sommige sites bij meerdere mensen naar voren kwam, ik vind het toch best interessant dat ik daar zomaar bij kan

[LaitSolaire]

Het wordt helemaal problematisch als op de lijst van datalekken sites komen te staan die iemand publiekelijk te kakken kunnen zetten.

Valt dit überhaupt op te lossen? Zou een account op HIBP aanmaken kunnen voorkomen dat anderen kunnen zien waar je bent geweest? [this email address requires an account for verification] Het lijkt me iig een nachtmerrie om dat te managen.

[Alex3]

Meerdere e-mailadressen gebruiken. Mijn familie en vrienden kennen niet al mijn adressen...

[Nazlive]

Misschien zou een oplossing kunnen zijn om als je op een email wil zoeken dat je een verficicatie naar dat mail adres krijgt en dan pas het overzicht krijgt?

[Carakas]

Dat werkt al zo voor hele domeinen te scannen. Maar zou inderdaad een goede uitbreiding zijn

[locke960]

Voor zover ik weet duiken gevoelige domeinen niet op in een normale search. Om die te krijgen moet je je aanmelden voor de e-mail notificatie service.

Maar ook wat valt onder gevoelig is subjectief, dus het blijft een punt van discussie.

[The Zep Man]

Dat klinkt wel als een goed idee, maar voor je privacy is dat natuurlijk wel vrij nutteloos. Al die data is namelijk al "publiek" beschikbaar op de uitgelekte lijsten.

Dat de data al uitgelekt is houdt niet in dat legitieme partijen hier illegitiem mee om mogen gaan.

[mphilipp]

Precies. En als mensen het naar vinden dat hun 'lotje123' wachtwoord overal staat, moeten ze maar met gezwinde spoed hun wachtwoord wijzigen in iets dat moeilijker te kraken is. Het is namelijk erg moeilijk door te dringen tot mensen die online beveiliging niet serieus nemen. Ik heb hier zo'n vriendin zitten die gewoon doorgaat met haar simpele wachtwoorden en totaal niet begrijpt dat er zomaar misbruik van die gegevens kan worden gemaakt. Laten zien dat haar mailadres óók voorkomt in de databases van haveibeenpowned maakte weinig indruk. Misschien dat dit wél helpt. Breekijzer methoden. De tijd van zachte handschoenen is voorbij denk ik .

[Sleepkever]

https://scatteredsecrets.com/ is misschien nog wel een leuke dan. Die hebben naast de lekken ook de simpel te decrypten wachtwoorden alvast voor je. Die maken echter wel gebruik van e-mail verificatie zodat niet iedereen zomaar alles in kan zien van anderen.

[bluewalk]

Dit is al wel het geval als je domeinen wilt opvragen (bv je eigen domein), dan komt er verificatie via het standaard hostmaster@domein of postmaster@domein binnen.

Het zou mij inziens goed zijn om dit ook voor enkele email queries te doen, zo kan alleen de eigenaar zien of er breaches zijn i.p.v. elk willekeurig persoon.

[Stijnvi]

Dat lijkt mij inderdaad de beste oplossing, en dat lijkt mij ook redelijk makkelijk te implementeren

[gooos]

Maar wat is het belang van het publiek om het van elk mailadres te kunnen opvragen waar enkel het kunnen opvragen van je eigen gegevens al toereikend is...

Nu stel je het publiekelijk inzicht aan welke sites jou mailadres is gekoppeld boven het recht op privacy zodat niet iedereen kan zien bij welke sites (met een bekend lek) je een account hebt. Lijkt me niet helemaal de juiste / gewenste manier van het uitleggen van zwaarwegend publiekelijk belang.

[sus]

Maar… het *is* al publiek. Lijstjes kan je overal vinden, het enige wat hij doet is er een mooi jasje en een makkelijke zoekopdracht omheen hangen.

Als ik de ruwe data dumps bekijk kan ik ook van alle mailadressen zien op welke websites ze gebruikt zijn.

Op dat vlak is wat hij doet en aanbiedt exact hetzelfde als een ruwe datadump.

[The Zep Man]

Maar… het *is* al publiek.

De AVG discrimineert niet op waar data vandaan komt of waar het beschikbaar is. Het maakt enkel een onderscheid gebaseerd op wat voor data verwerkt wordt (persoonsgegevens of geen persoonsgegevens).

[Reactie gewijzigd door The Zep Man op 23 juli 2024 08:10]

[gooos]

Eens, maar toch... hoeveel (gewone) mensen nemen nu de moeite om die bronnen echt te achterhalen, te downloaden, en vervolgens uit te pluizen?

HIBP biedt wat dat betreft laagdrempelige toegang tot de data. Dat is te prijzen en er valt tegelijkertijd wat op af te dingen op de manier waarop dit gebeurd.

Mensen met verkeerde bedoelingen hebben sowieso al een grotere drijfveer om zulke data, in grote hoeveelheid, in handen te krijgen.

[[eNeRGy]]

Ik vraag me af of GDPR hiervoor geldt... of iig met deze situatie rekening heeft gehouden.

Want jij hebt jouw gegevens nooit bij hem ondergebracht, dus hij verwerkt niet de gegevens in relatie tot jou.
Het is ook niet in vertrouwen aan hem gegeven, want het zijn juist gelekte gegevens die te vinden zijn. Daar
heeft iemand wel de GPDR overtreden, maar dit is de data die daar een gevolg van is.

Enige punt wat gemaakt kan worden is dat ze tot een persoon herleid kunnen worden.
Misschien is het implementeren van het recht-om-vergeten-te-worden genoeg in dit geval.

[The Zep Man]

Ik vraag me af of GDPR hiervoor geldt... of iig met deze situatie rekening heeft gehouden.

De AVG geldt zeker.

Want jij hebt jouw gegevens nooit bij hem ondergebracht, dus hij verwerkt niet de gegevens in relatie tot jou.

Een e-mailadres is nog steeds een persoonsgegeven. Hij verwerkt persoonsgegevens. Dat alleen al maakt dat de GDPR van toepassing is.

Het is ook niet in vertrouwen aan hem gegeven, want het zijn juist gelekte gegevens die te vinden zijn. Daar heeft iemand wel de GPDR overtreden, maar dit is de data die daar een gevolg van is.

Zowel de 'lekker' als Hunt verwerken persoonsgegevens. Het één sluit het ander niet uit.

Enige punt wat gemaakt kan worden is dat ze tot een persoon herleid kunnen worden.

Direct of indirect, dat alleen is voldoende om de data als persoonsgegevens aan te merken, die verwerkt worden.

Misschien is het implementeren van het recht-om-vergeten-te-worden genoeg in dit geval.

Je hebt veel meer rechten dan enkel vergeten te worden. Denk alleen al aan:
• Het recht om inzicht te krijgen in welke data van jou verwerkt wordt.
• Het recht om jouw data op te vragen in een gestructureerd formaat.
• Het recht om jouw data te laten wijzigen wanneer het incorrect is.

Verder denk ik dat 'publiek belang' voor de rechtbank geen excuus zal zijn als een gebruiker een verzoek doet om diens eigen data te laten verwijderen.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 08:10]

[oZy]

Als ik het email adres [e-mail] registreer.. is dat dan een persoonsgeven van jou of van mij?

Is een e-mailadres per definitie een persoonsgegeven zoals je zo stellig beweert?

[Bor]

Conclusie

Niet elk e-mailadres wordt beschouwd als een persoonsgegeven. E-mailadressen worden echter wel beschouwd als persoonsgegevens wanneer deze identificeerbare informatie omtrent natuurlijke personen bevatten. Veel e-mailadressen zijn op zo’n manier vormgegeven, dat de persoon die het e-mailadres gebruikt geïdentificeerd kan worden. Dit is het geval wanneer een e-mailadres de naam of werkplaats van een natuurlijke persoon bevat. Om deze reden zal een groot deel van de e-mailadressen als persoonsgegevens beschouwd worden. Het is moeilijk voor ondernemingen om een onderscheid te maken tussen e-mailadressen die beschouwd worden als persoonsgegevens en e-mailadressen die niet zo beschouwd worden, aangezien dit helemaal afhankelijk is van de manier waarop het e-mailadres vormgegeven is. Het is dan ook aannemelijk dat ondernemingen die e-mailadressen verwerken, e-mailadressen tegenkomen die als persoonsgegevens beschouwd moeten worden. Dit betekent dat deze ondernemingen onder de reikwijdte van de AVG vallen en dat zij een privacybeleid op moeten stellen dat in overeenstemming met de AVG is.

Bron: https://lawandmore.nl/blo...de-reikwijdte-van-de-avg/

[oZy]

Veel natuurlijke personen geven hun e-mailadres vorm op een manier dat het e-mailadres beschouwd moet worden als een persoonsgegeven. Dat is bijvoorbeeld het geval wanneer een e-mailadres op de volgende manier ingericht is: [e-mail]. Dit e-mailadres openbaart de voor- en achternaam van de natuurlijke persoon die het adres gebruikt. Deze persoon kan dus geïdentificeerd worden aan de hand van dit e-mailadres.

Het is nog steeds te kort door de bocht. Ik heet geen Jan Janssen en alsnog krijg ik vaak zat e-mails die bestemd zijn voor iemand met dezelfde naam. Als je alleen een voor en achternaam hebt en verder geen kennis van de persoon achter het mail adres hebt kun je het in heel veel gevallen nog steeds niet tot een natuurlijk persoon herleiden.

Ik snap de bezwaren wel betreft het scrapen van de mailadressen gekoppeld aan bepaalde sites (ook al zijn de intenties goed bedoeld) maar ik denk niet dat het "emailadres = persoonsgegeven" argument stand zou houden in dit geval.

[silexh]

Je hebt veel meer rechten dan enkel vergeten te worden. Denk alleen al aan:
• Het recht om inzicht te krijgen in welke data van jou verwerkt wordt.
• Het recht om jouw data op te vragen in een gestructureerd formaat.
• Het recht om jouw data te laten wijzigen wanneer het incorrect is.

Het interessante is natuurlijk dat de eerste twee punten al ongeveer bestaan: het hele doel van de service is om een overzicht van jouw data te krijgen, en de webpagina haalt dit op in JSON. Ik zie nog niet helemaal hoe correctie zou werken (een lek toevoegen?). Het belangrijkste recht blijft dan die om vergeten te worden, wat mij zeker op zijn plaats lijkt. Wel is het natuurlijk wat onzinnig, omdat 1) de data al publiek is, en 2) je gegevens er bij nieuwe lekken opnieuw in komen.

Verder denk ik dat 'publiek belang' voor de rechtbank geen excuus zal zijn als een gebruiker een verzoek doet om diens eigen data te laten verwijderen.

Eens, hoewel de grondslag waarschijnlijk gerechtvaardigd belang zou zijn (denk ik).

[Reactie gewijzigd door silexh op 23 juli 2024 08:10]

[runnershigh]

Ik zie nog niet helemaal hoe correctie zou werken

Als je je gelekte wachtwoord hebt gewijzigd, kun je het nieuwe wachtwoord naar HIBP sturen.

[Stijnvi]

Het recht om vergeten te worden lijkt me ook niet heel relevant, want er wordt maar één gegeven opgeslagen (het e-mailadres), wat nergens anders aan gelinkt is
Een adres is ook een persoonsgegeven, maar Google Maps etc. laten ook alle adressen ter wereld zien
Volgens dezelfde redenatie zou dit dan ook niet mogen

[biteMark]

Oh FFS, laat mensen eens blij zijn dat een dienst als deze bestaat! Zijn er serieus mensen die niet willen dat ik kan zien dat mijn wachtwoorden gelekt zijn? Laat ze zich lekker uitschrijven (er is gewoon een opt-out optie) en zich met hun eigen zaken bemoeien. Ze vergeten waarschijnlijk dat, behalve HIBP, iedereen op de hele fucking wereld in potentie bij je gelekte wachtwoorden kan - in plain text. Dat moet je toch juist willen weten?

[blackjack21]

Als het comfort de AVG wilt opereren moet het opt-in zijn. Dan mag jij je aanmelden om te zien of jouw wachtwoorden gehacked zijn.

Omdat jij iets wilt zien moeten de persoonsgegevens van vele miljoenen personen geschaad worden?

Opt-out = fout, hoe handig de dienst ook mag zijn.

[EraYaN]

Dat is natuurlijk niet hoe data lekken werken, opt-out, ik denk dat je dat ook wel snapt. Maar begin vooral een proces tegen deze man, een interessante casus.

[biteMark]

Opt-out = fout, hoe handig de dienst ook mag zijn.

Pijnlijke slagzinnetjes daargelaten ben ik het daar normaal gesproken ook heel erg mee eens. Echter zou dat in dit geval betekenen dat pas vanaf dat moment HIBP mijn gelekte wachtwoorden mag verzamelen, eerder gelekte wachtwoorden zijn onmogelijk te achterhalen (tenzij ze een kopie van de lekken bewaren, wat dus niet zou mogen).

Als gevolg daarvan zou iedereen die dat wil zich zo snel mogelijk moeten inschrijven om niet de boot te missen bij het eerste het beste volgende opgenomen lek. Dat zou voor mensen als mijn ouders, mijn buren en basically iedereen die zich niet zoveel met computers bezig houdt behoorlijke gevolgen kunnen hebben en waarschijnlijk zou er een behoorlijke internationale campagne nodig zijn om zoveel mogelijk mensen op de hoogte te brengen én te overtuigen dat het belangrijk is om je in te schrijven. Dat zou best een drempel kunnen zijn waardoor veel mensen er voor kiezen het niet te doen (want: gedoe).

Zoals het nu is kan iedereen zonder gedoe checken of zijn of haar wachtwoord gelekt is en wie dat niet wil kan zich uitschrijven. Lijkt me prima.

[kodak]

Daarom heeft handhaving zoals politie en fbi dus de taak om slachtoffers te informeren. Dat hibp het dan maar doet wil niet zeggen dat het dus maar redelijker is.

[biteMark]

Maar aangezien internationale autoriteiten dat verzaken is het fijn dat HIBP het wél doet

[kodak]

Dat is fijn voor de personen die dat wel handig vinden, bijvoorbeeld omdat ze niet meer geld uit willen geven aan handhaving of de wet niet zo heel belangrijk vinden als het ze zelf beter uit komt. Er is niet zomaar vanuit de wet geregeld wie handhaving hoort te doen of dat je recht over je eigen gegevens hoort te hebben.

[biteMark]

Heb je ook, via de opt-out

[kodak]

En dat is dus het omgekeerde van wat de bedoeling is als iemand wil voorkomen dat anderen maar met je persoonsgegevens doen way ze zelf willen.

[biteMark]

*Zucht*

[Floort]

Dat HIBP persoonsgegevens verwerkt is overduidelijk. Combinaties van e-mail adressen en wachtwoorden zijn op enkele uitzondering na gewoon persoonsgegevens. Maar of de AVG van toepassing is hangt ook af van de vraag of art. 3(2)(a) AVG van toepassing is, namelijk of HIBP zijn dienst aanbied aan betrokkenen in de unie. Het is daarvoor niet genoeg als de website benaderbaar is vanuit de unie. Dat is een genuanceerde discussie waar je in die geval denk ik redelijkerwijs van mening over kan verschillen. Ik denk dat een dergelijke dienst onder de AVG wel zou mogen met een gerechtvaardigd belang. De verwerking is namelijk ook in het belang van de betrokkenen, mits de verwerking zorgvuldig gebeurt. De betrokkenen moeten natuurlijk wel conform art. 14 geïnformeerd worden over de verwerking.

[The Zep Man]

Maar of de AVG van toepassing is hangt ook af van de vraag of art. 3(2)(a) AVG van toepassing is, namelijk of HIBP zijn dienst aanbied aan betrokkenen in de unie. Het is daarvoor niet genoeg als de website benaderbaar is vanuit de unie. Dat is een genuanceerde discussie waar je in die geval denk ik redelijkerwijs van mening over kan verschillen.

HIBP verwerkt persoonsgegevens van EU burgers, en de diensten op de site worden aangeboden aan EU burgers. Dat is voldoende. HIBP doet verder niets dat (in redelijkheid en billijkheid) voorkomt dat EU burgers de betreffende dienst gebruiken.

Dit is dan ook een reden waarom sommige Amerikaanse sites geoblocks instellen om EU burgers te weren. Zij kunnen of willen niet met de AVG omgaan.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 08:10]

[Floort]

Artikel 3(1): Niet van toepassing omdat de verantwoordelijke niet gevestigd is in de unie. Dat kan de AVG alsnog van toepassing zijn als de uitzonderingen 3(2), (a) of (b) van toe passing zijn. Uitzondering (a) heb ik net benoemd. Uitzondering (b) is van toepassing als het gaat om het monitoren van gedrag van betrokkenen in de unie, waar hier denk ik geen sprake van is. Of de dienst gericht is aan betrokkenen in de unie is ingewikkelder dan alleen de vraag of de website beschikbaar is in de unie. Zie daarvoor overweging 23 van de AVG. Ik denk dat je een redelijk argument kan maken dat dat bij HIBP het geval is, maar ik heb precies dit geval besproken met een goede jurist die van mening is dat dat niet het geval is.
Het relevante stukje uit overweging 23:

Whereas the mere accessibility of the controller’s, processor’s or an intermediary’s website in the Union, of an email address or of other contact details, or the use of a language generally used in the third country where the controller is established, is insufficient to ascertain such intention, factors such as the use of a language or a currency generally used in one or more Member States with the possibility of ordering goods and services in that other language, or the mentioning of customers or users who are in the Union, may make it apparent that the controller envisages offering goods or services to data subjects in the Union.

[Reactie gewijzigd door Floort op 23 juli 2024 08:10]

[Stijnvi]

Een woonadres is ook een persoonsgegeven
Google Maps laat alle adressen ter wereld zien
Dat zou dan ook illegaal zijn...
HIBP laat bovendien geen wachtwoorden zien, en ook niet in combinatie met een e-mailadres
Het laat zelfs niet eens een database zien met alle gehackte e-mailadressen
Het laat alleen zien of het e-mailadres wat jij invoert voorkomt in een gehackte database, en zo ja, in welke

[Floort]

Er zijn best veel manieren om rechtmatig persoonsgegevens te verwerken. Waar komt de gedachte vandaan dat als iets persoonsgegevens zijn dat de verwerking daarom illegaal zou zijn? Ik zie het vaker terugkomen. Ik zie ook een behoorlijk lange discussie over publiek belang, een grondslag die om meerdere redenen niet op HIBP van toepassing kan zijn. Een dienst als HIBP kan bijna niet anders dan werken met een gerechtvaardigd belang (art. 6(1)(f) AVG) als grondslag als de AVG al van toepassing is. En mits dat zorgvuldig is ingericht denk ik dat het onder de AVG ook rechtmatig zou kunnen. Maar in de praktijk zie ik een aantal vergelijkbare diensten wel duidelijk in strijd met de AVG handelen.

[kodak]

Indien HIBP persoonsgegevens van Nederlanders verwerkt en ondertussen ook gebruikt om er zelf van te profiteren (lucratieve sponsering, voordeel om businessclass internationaal te reizen naar bijeenkomsten om ook persoonlijk te netwerken) is een rechtvaardigheid op andermans gelekte persoonsgegevens niet makkelijk te geven. Dus waar zit het evenwicht dan als er wetgeving is aangenomen die bescherming verwacht tenzij. Als je er een beetje goed mee doet is het wel prima lijkt me te kort door de bocht.

[Floort]

Ik denk dat HIBP-achtige diensten een voorbeeld zijn van diensten die voornamelijk in het belang van de betrokkenen zijn. Ik zou de analyse beginnen met het nut en de risico's voor betrokkenen bij de verwerking bij HIBP en die vergelijken met de situatie waarbij de gegevens alleen in bulk voor allerlei mensen beschikbaar zijn zonder dat de betrokkenen gewaarschuwd worden.

[Reactie gewijzigd door Floort op 23 juli 2024 08:10]

[kodak]

Hoe voorkom je daarbij dan dat vooringenomenheid over belang een rol gaat spelen? De wet stelt niet dat bescherming vooral over nut of risico's hoort te gaan.

[Floort]

Poeh.. daar vraag je een hoop in een keer. Het is primair aan de verantwoordelijke om die belangenafweging te maken én te documenteren. Afhankelijk van de verwerking en de keuzes van de verantwoordelijke kan er een FG in dienst zijn om toezicht te houden. De betrokkenen moeten (art. 14) ook geïnformeerd worden over de verwerking en die kunnen klagen bij de verantwoordelijke, de FG, de AP of zelf naar de rechter stappen. Dan kan de AP ook nog op eigen initiatief toezicht houden en daarbij eventueel een zaak voor de rechter brengen. Dat is niet het volledige plaatje, maar dat zijn wel enkele onderdelen van het toezichtsstelsel die eventuele vooringenomenheid kunnen opmerken en corrigeren.

Artikel 6(1)(f) spreekt expliciet van een afweging van belangen. De voordelen en risico's van de verantwoordelijke en de betrokkenen spelen mee in die afweging. Maar ook andere zaken zoals de voorzienbaarheid van de verwerking speelt mee. Overweging 47 van de AVG bevat daarover wat meer context.

Maar als je punt is dat de f-grondslag niet een glasheldere checklist bevat van voorwaarden waar je aan moet voldoen en dat het daardoor aan interpretatie onderhevig is: dat klopt.

[kodak]

Het zou hoe dan ook de moeite waard zijn dat dit initiatief door een toezichthouder te laten onderzoeken. Waarbij dat in volledige openheid plaats heeft, als het argument is dat het in ieders belang zou zijn. Ik vrees alleen dat zowel hibp en toezichthouders er hun vingers niet aan willen branden omdat het ze beter uit komt.

[gooos]

Het zou inderdaad netter zijn als je eerst een toegangscode moet opvragen die naar je mailbox gezonden wordt zodat niet iedereen elk mailadres kan bekijken.

Of dat je een account kan aanmaken waar je meerdere mailadressen, na verificatie, aan kan toevoegen.

Dat zou het allemaal wat meer GDPR compliant maken.

[bombadil]

Troy en zn .com domein zijn toch helemaal niet in Europa gebaseerd. Derhalve valt hij toch niet onder de Nederlandse AVG, EU GPDR?

Anders neem ik aan dat je net zo goed kan stellen dat je met een website onder alle wetten in heel de wereld zal vallen?

[RobbieB]

Hij verwerkt gegevens van mensen in de EU, dus heeft zich aan de Europese wetgeving te houden. En ja, dat geldt voor alle landen in de hele wereld.

[Reactie gewijzigd door RobbieB op 23 juli 2024 08:10]

[EraYaN]

Hij hoeft zich natuurlijk alleen aan de EU wetgeving te houden als hij hier ooit wil komen, anders heeft het allemaal vrij weinig tanden natuurlijk.

[Falcon]

Exact, die hoek zat ik ook te denken.

[Frame164]

En heeft Hunt voor zijn claim ook een juridische basis? Of vind hij het gewoon?

[CobraVE]

Het is belangrijker om te weten of je wachtwoorden nog veilig zijn dan dat het is om je email adres geheim te houden (iets wat toch al publiekelijk is in de meeste gevallen)

[Djordjo]

Daar lopen ook interessante discussies over bv. in het kader van GDPR, want in de basis verwerkt HIBP persoonlijke data (emailadressen) zonder dat het daar enige vorm van toestemming voor heeft van de eigenaar.

Toestemming is slechts één van de gronden om persoonsgegevens te mogen verwerken.

[RoestVrijStaal]

o.a. omdat je van ieder e-mailadres kan zien waar ze een account hebben (indien die site gebreached is geweest).

Ik vraag me daarom ook af wat het nut is om zo'n breach langer na 5 jaar na publicatie op HIBP online per e-mailadres of telefoonnummer opzoekbaar te houden.

[honey]

Ik heb altijd het gevoel bij dit soort initiatieven dat het ook een ideaal platform is om werkende wachtwoorden en e-mail adressen te harvesten.

[aikebah]

Behalve dan dat het dat bij HIBP niet is voor wachtwoorden, die zijn er namelijk niet te vinden. Enkel wachtwoord hashes.

[honey]

Je vult toch een e-mail adres in of een wachtwoord?

[aikebah]

als je een wachtwoord invult dan hasht je browser (javascript) dat wachtwoord op je systeem en stuurt een deel van de hash (eerste 5 karakters) naar HIBP. HIBP stuurt de subset van hashes die daarme beginnen en in de database staan terug naar de javascipt en javascript kijkt of jouw hash in die subset staat. Zo ja, dan wordt aangenomen dat je wachtwoord voorkomt in gelekte plaintext of decrypted passwords. (je kunt ook de domme pech van een hash-collision hebben)

https://www.troyhunt.com/...wned-passwords-version-2/

[jaspro]

De eigenaar is Troy Hunt (https://www.troyhunt.com/about/)

[FrostyPeet]

Ik vraag me af wat het nut zal zijn van HIBP als later ons halve land erin staat. Het zou nu toch bekend moeten zijn dat wachtwoorden elke x maanden gewijzigd dienen te worden?

Dat een wachtwoord 2 jaar geleden gelekt is, is dan minder relevant.

Misschien moet er een opschoning plaatsvinden na X jaar?

[RobbieB]

Wachtwoorden wijzigen is allang niet meer aan te raden en wordt door Microsoft al jaren afgeraden als adequate maatregel. Een ww dient alleen gewijzigd te worden als het gecompromitteerd is geraakt. En als je een afdoende veilig wachtwoord gebruikt (passphrase, veel tekens, etc.) en de site het goed genoeg beveiligd (moderne salted hash) dan loop je in principe 0 risico.

[Bor]

Wachtwoorden wijzigen is allang niet meer aan te raden en wordt door Microsoft al jaren afgeraden als adequate maatregel.

Dat is niet geheel waar. Dit lees je vaak maar het is wat kort door de bocht. Bij de artikelen waar dit in wordt aangegeven gaat men er namelijk ook vanuit dat er aanvullende maatregelen zijn zoals MFA, Azure AD Password Protection, verregaande analytics op inlogpogingen etc. Het ligt dusbehoorlijk genuanceerder.

Sterker nog; best practise wordt op Technet nog altijd aangegveven:

Best practices

Set Maximum password age to a value between 30 and 90 days, depending on your environment. This way, an attacker has a limited amount of time in which to compromise a user's password and have access to your network resources.

[Reactie gewijzigd door Bor op 23 juli 2024 08:10]

[Pixal]

Denk inderdaad dat het advies van Technet meer slaat op interne omgevingen waar verder geen extra vorm van authenticatie wordt toegepast. Kijk je naar de cloud diensten van MS dan heb ik begrepen dat Microsoft gewoon in lijn is met de NIST password policy.

Daaruit is geleerd dat wachtwoord expiry en complexity weinig waarde toevoegen. https://securityboulevard...onal-password-management/

Lengte van je ww is vooral belangrijk en natuurlijk een combinatie met 2FA.

[etiennebruines]

Het wordt alleen wel echt afgeraden, gebruikers te verplichten hun wachtwoorden na X tijd te wijzigen.

https://web.dev/sign-up-f...o-forced-password-updates

Zeker als het iedere keer een "nieuw" wachtwoord moet zijn, krijg je (zeker voor AD, omdat je dan nog niet in je password manager zit) dat er post-its op het beeldscherm worden geplakt met het wachtwoord erop.

Het kan best zijn dat het aan te raden is als gebruiker, om je wachtwoord te wijzigen - maar totdat dit geautomatiseerd loopt, zie ik het niet vaak gebeuren.

[Bor]

Ook daar is er veel meer nuance dan dat het alleen afgeraden wordt. Jouw link heeft het zelfs over "Don't force users to update their passwords arbitrarily." Het keyword hier is arbitrarily (based on random choice or personal whim, rather than any reason or system). Dat is vrijwel nooit een goed idee. Het bronartikel is ook gebaseerd op meer nuance en aanvullende maatregelen. Je kan niet zo maar 1 enkele regel uit zo'n advies pakken en de rest negeren / niet implementeren. Het systeem is zo sterk als de zwakste schakel.

[Reactie gewijzigd door Bor op 23 juli 2024 08:10]

[grobbel]

Precies. als mensen elke 3 dagen hun wachtwoord moeten gaan veranderen, dan gaan ze roteren (je mag na 10 keer weer terug naar een oud wachtwoord), of er nummers achter plakken. Dat is allemaal maar schijnveiligheid dus.

[Bor]

Dat valt te ondervangen door een minimum password age (ook best practice) en een een enforce password history. Het probleem zit hem veelal niet in de techniek maar in de gebruikers. Zo lang zij zich niet bewust genoeg zijn gaat geen enkel systeem helemaal afdoende werken. Het is prima om een wachtwoord te laten verlopen maar kies daarvoor wel een onderbouwde en hanteerbare waarde. Het is de afweging tussen veiligheid en gebruiksgemak. Het voorbeeld van 3 dagen lijkt mij geheel aan de verkeerde kant van het spectrum te zitten. Het blijft een risico afweging.

[CAPSLOCK2000]

Mijn eigen favoriete oplossing is de geldigheidsduur van het wachtwoord afhankelijk te maken van de kwaliteit van het wachtwoord.

Als de gebruiker om wat voor reden dan ook een slecht wachtwoord kiest dan is dat maar heel kort geldig. Soms is dat prima, soms wil je gewoon 'test123' als wachtwoord instellen om even iets te testen. Als zo'n account na 1 uur vanzelf wordt geblokkeerd dan is het risico van een makkelijk wachtwoord veel kleiner.
Dan gaan mensen vanzelf op zoek naar manieren om hun wachtwoord complexer te maken zodat het langer geldig is.

Als je zo'n systeem hebt kun je nog andere aspecten meenemen dan alleen het wachtwoord. Zo kun je minder streng zijn als mensen ook 2FA doen. Of je kan extra streng zijn als een wachtwoord wordt veranderd vanaf een buitenlands IP-adres of buiten kantooruren.

[Tralapo]

Zeker het geforceerd wijzigen zonder al te veel eisen heeft geen enkele zin. Op mijn vorige werk had je dan letterlijk kreten als "wow ik ben al bij welkom143, ik werk hier veel te lang!" door het kantoor op wijzigdag.

[RobbieB]

Fair enough, indien aanvullende maatregelen als MFA niet in place zijn dan kan het inderdaad een goede maatregel zijn, maar in de praktijk kiezen gebruikers voor opvolgende wachtwoorden (herfst2020!, winter2020!, lente2021!, bedrijfsnaam2021!, etc.), dan kun je beter verplichten lange wachtwoorden te gebruiken die ze nooit hoeven te wijzigen en daarnaast te monitoren op compromise...

[honey]

Ha, dit is exact hoe ik het doe. Ideaal.

[Gropah]

Het is maar net wat je als bron pakt. De NIST guidelines (die ook redelijk veel worden aangehaald) stelt namelijk juist dat een wachtwoord niet zou moeten verlopen tenzij er aanwijzingen zijn dat hij gecompromitteerd is.

De gedachte hier achter is (schat ik) dat als je elke x dagen een nieuwe moet instellen je snel wachtwoorden zoals Wachtwoord1 of WachtwoordMei krijgt en dat onveiliger is dan een wachtwoord lang aanhouden (mits hij niet bekend is).

[Bor]

De NIST guidelines stellen meer zaken rond wachtwoorden, je kan niet zo maar 1 deel daaruit cherry picken zonder de andere zaken ook in overweging te nemen. Uiteindelijk komt het neer op de gebruikers, welk systeem je ook kiest. Awareness is een zaak dat zeer regelmatig wordt onderschat. Zo lang gebruikers van een systeem zich niet doordrongen zijn van het belang van veiligheid zullen ze altijd zaken proberen om alles zo makkelijk mogelijk te maken, veelal met negatieve gevolgen. Denk aan de post-it's, het terug wijzigen van wachtwoorden naar een oudere, het delen van wachtwoorden met anderen etc.

[mjz2cool]

Je loopt nooit 0 risico, maar inderdaad, het regelmatig wijzigen van een wachtwoord heeft vaak als gevolg dat wachtwoorden eenvoudiger worden, om ze te kunnen onthouden. Volgens mij heeft Microsoft zelfs de optie voor het verplichten van het regelmatig wijzigen van wachtwoorden uit Windows Server gehaald.

[devices]

Niet uit AD tenminste, want ik moet bij mijn werkgever elke zoveel maanden mijn windows wachtwoord wijzigen.

[mjz2cool]

Het is ook in de nieuwste versies volgens mij, maar kan het ook verkeerd gelezen hebben.

[Bor]

Volgens mij heeft Microsoft zelfs de optie voor het verplichten van het regelmatig wijzigen van wachtwoorden uit Windows Server gehaald.

Hoe kom je daarbij? Microsoft stelt dat de max password age instellen best practice is voor Windows Server. Zie mijn eerdere reactie en Technet.

[mjz2cool]

Ze stellen juist dat die password expiration niet meer een best practice is.
https://docs.microsoft.co...-and-windows-server-v1903
Ik heb het artikel weer gevonden waar ik het in gelezen dacht te hebben, maar het gaat dus puur om hun security baseline, niet persé om het verwijderen van de policy uit Windows Server. Maar ze zeggen er dus wel dat password expiration achterhaald is.

[Bor]

Dat document ken ik. Het document wat je aanhaalt is een draft / voorstel voor aanpassingen. Het is goed om hier ook de reden mee te nemen waarom Microsoft voorstelt het uit de baseline te halen

By removing it from our baseline rather than recommending a particular value or no expiration, organizations can choose whatever best suits their perceived needs without contradicting our guidance. At the same time, we must reiterate that we strongly recommend additional protections even though they cannot be expressed in our baselines.

Kortom, Microsoft geeft hier aan dat het aan organisaties zelf is om te bepalen (op basis van een gedegen risico analyse). Zou zou je elk wachtwoordbeleid moeten oppakken. Wat past er goed voor jouw organisatie en gebruikers waarbij je wilt insteken op de gulden middenweg tussen veiligheid en gebruiksgemak. Niet in de laatste plaats omdat het gebruiksgemak ook van invloed zal zijn op de veiligheid.

[Reactie gewijzigd door Bor op 23 juli 2024 08:10]

[EraYaN]

Voor alle nieuwe Azure omgevingen staat het anders gewoon uit, ook die gesynchroniseerd worden met AD op Windows Server edities van Windows. De Security advisor geeft dat ook gewoon aan als je het wel ingesteld hebt. Het grootste probleem is dat mensen hun wachtwoorden gewoon gaan nummeren.

[Bor]

Azure heeft dan ook behoorlijk wat meer mogelijkheden om slechte wachtwoorden te filteren en misbruik te detecteren dan een on premise Active Directory. Je dient het per omgeving en toepassing te bekijken.

[gabba25]

Volgens mij zijn daar ook nog steeds de meningen over verdeeld. Wie heeft er gelijk? Want zal het voor zakelijk gebruik anders zijn?

[RobbieB]

Natuurlijk zijn de meningen verdeeld, dat is het idee van meningen. Maar als alle grote security partijen en autoriteiten zeggen dat dit achterhaald is, dan is het verstandig omdat over te nemen. Hoef je niet te doen natuurlijk als je een andere mening hebt, maar ik heb altijd geleerd om naar subject-experts te luisteren.

V.w.b. zakelijk gebruik zie ik het in de praktijk nog wel vaak terug, maar als je er dan op doorvraagt waarom is het antwoord vaak: Het staat in de security policy, dus we moeten het doen. Dat soort bedrijven die zijn gestopt met nadenken hebben overigens meestal wel grotere problemen dan een outdated password policy...

[mjz2cool]

Het idee is dat regelmatig gewijzigde wachtwoorden vaak simpeler zijn (een 3 in plaats van 2, dat soort dingen).

[Bor]

In reactie op @RobbieB

Daar zijn de meningen inderdaad over verdeeld.

Maar als alle grote security partijen en autoriteiten zeggen dat dit achterhaald is, dan is het verstandig omdat over te nemen.

Wat je hier stelt is niet feitelijk wat er aan de hand is. De security wereld, inclusief de grotere partijen en autoriteiten zijn verdeeld over dit punt. Niet in de laatste plaats door wat je hier ziet gebeuren; men bekijkt het advies als een losstaand punt terwijl het onderdeel is van een groter geheel. Sterker nog, als je de adviezen goed leest stellen ook vrijwel geen bedrijven of initiatieven over het algemeen dat het laten wijzigen van een wachtwoord niet werkt. De ene geeft dat het marginaal veiliger is en de ander hangt er een grotere waarde aan.

[Reactie gewijzigd door Bor op 23 juli 2024 08:10]

[densoN]

Het probleem is dat je niet altijd weet of een account comprimised is. Dat gecombineerd met het feit dat veel mensen er nog steeds de nare gewoonte op na houden om om wachtwoorden te hergebruiken is nog steeds reden genoeg om in een corporate omgeving een password rotation policy aan te houden.

Een goed voorbeeld hiervan is de hack bij linkedin. Met de credentials die daar zijn buitgemaakt heeft vervolgens een keten van hacks plaatsgevonden, waaronder de hack bij Dropbox. Ja er zijn ook nog steeds IT professionals die de best practices op het gebied van password management negeren.

Als laatste bestaat er ook nog steeds de kans dat hashed passworden worden buitgemaakt (zonder dat dit wordt bekend gemaakt) en kwaadwillende GPU clusters gebruiken om de hashes te kraken. Kijk je naar de cracking rates van bijvoorbeeld een enkele RTX 3090 weet je dat een wachtwoord van 8 karakters allang niet meer voldoende is. Met een complex password policy en een lengte van minimaal 12 karakters weet je dat de kans in ieder geval groter is dat het wachtwoord alweer gewijzigd is tegen de tijd dat de hash is gekraakt.

Ik zou dus zeker niet aanraden om het advies van Microsoft in deze op te volgen.

[batjes]

Microsoft is degene die mij verplicht elke 30-60 dagen ofzo mijn onsite wachtwoorden voor Azure aan te passen. Bedrijfsportaal dwingt me op mijn telefoon ook op elke 90 dagen het wachtwoord aan te passen.


@Bor https://www.security.nl/p...ord+wijzigen+onverstandig
Security.nl beweert anders, het regelmatig wijzigen van het wachtwoord werkt averechts. Dat zie ik in de praktijk ook terug. Men begint met "Wachtwoord" en na 30-90 dagen wordt dat "wachtwoord1" etc.
Of men schijft ze op, dat gebeurd nu ook veel.

Met 2 factor -remote- logins is het wachtwoord ook veel minder belangrijk geworden.

[Bor]

Met 2 factor -remote- logins is het wachtwoord ook veel minder belangrijk geworden.

Dat hoor je vaak maar is dat wel zo? Het is namelijk 1 van de 2 factoren. Je zou kunnen zeggen dat de waarde afneemt wanneer de 2e factor sterker is dan het wachtwoord zelf misschien.

Security.nl beweert anders

Dat is gebaseerd op de mening van 1 persoon, op basis van een enkele dataset uit 2010. De security wereld is continu in beweging waardoor je adviezen altijd goed dient af te wegen en dient te vertalen naar de eigens situatie op basis van een goede risicoanalyse.

Men begint met "Wachtwoord" en na 30-90 dagen wordt dat "wachtwoord1" etc.
Of men schijft ze op, dat gebeurd nu ook veel.

Dat wordt doorgaans ondervangen door te stellen dat een wachtwoord geen (delen van) eerder gebruikte (of elders gebruikte) wachtwoorden mag bevatten. Niet alles hoef en kan technisch afgedicht worden.

[batjes]

Met alleen een wachtwoord kan je met 2factor niet inloggen, je hebt ze beide nodig. De waarde van het wachtwoord wordt dan natuurlijk een stuk minder. Het is namelijk niet zo erg meer als een wachtwoord ergens rondslingerd oid.
Wij gebruiken dan ook de 2de factor die niet zonder de ICT afdeling over te zetten is naar een andere telefoon. Welke wij ook op afstand kunnen blokkeren.

Wachtwoord geschiedenis verplichten zorgt er alleen maar voor dat mensen wachtwoorden gaan opschrijven op post-its, wachtwoordloze excel/word documenten of op andere niet aanbevolen plekken.

Dat je een wachtwoord 1 of 2 keer per jaar laat verlopen is veel beter, dan kunnen veel meer gebruikers het wachtwoord zelf onthouden.

Ik werk elke dag met doorsnee gebruikers en wij hebben recent onze wachtwoord policies aangescherpt op verzoek van onze security afdeling.... Het resultaat is dat nu op kantoor, bij mensen thuis en waar dan ook allemaal wachtwoorden rondslingeren.

De veiligheid is alleen maar achteruit gegaan. Naast dat het ons onnodig veel werk opzadeld met al die mensen die constant hun wachtwoord vergeten of niet tijdig hun wachtwoord aanpassen.

Mijn praktijkervaring (bij meerdere -grote- organisaties) komt heel erg overeen met het security.nl artikel.

[Bor]

Een ww dient alleen gewijzigd te worden als het gecompromitteerd is geraakt.

Dit is een belangrijk punt. Wanneer een wachtwoord gecompromitteerd is geraakt ben je per definitie al te laat. Daarbij weet je soms / vaak niet direct dat een wachtwoord gecompromitteerd is geraakt en hebben vele bedrijven ook niet de middelen om hier effectief op toe te zien. Dit soort zaken gaan veelal uit van een ideale wereld. In de praktijk worden gecompromitteerde credentials op het dark web verhandeld en komt de eigenaar hiervan er pas heel laat of zelfs niet achter.

[CAPSLOCK2000]

Wachtwoorden wijzigen is allang niet meer aan te raden en wordt door Microsoft al jaren afgeraden als adequate maatregel. Een ww dient alleen gewijzigd te worden als het gecompromitteerd is geraakt. En als je een afdoende veilig wachtwoord gebruikt (passphrase, veel tekens, etc.) en de site het goed genoeg beveiligd (moderne salted hash) dan loop je in principe 0 risico.

Voor de duidelijkheid, het advies is om het periodiek veranderen van wachtwoorden niet meer te verplichten. Als mensen om wat voor reden dan ook hun wachtwoord willen veranderen is dat prima, maar je moet ze er niet toe dwingen als er geen directe aanleiding voor is.

Mensen hebben slechte geheugens en houden niet van dwang, ze voelen het al snel als pesterij van hun baas die niet om het personeel geeft, of zo iets . Die twee samen zorgen er voor dat mensen dan slechte wachtwoorden gaan kiezen (geen enkele complexiteitsregel houdt dat ooit echt tegen) en/of ze gaan opschrijven.

Als er een duidelijke reden is om een wachtwoord te (laten) veranderen dan werkt het anders. Dan schrikken mensen van de bedreiging en doen ze hun best om goed mee te werken, bv door een goed wachtwoord te kiezen of toch maar een password manager te installeren.

Dan is er nog een categorie mensen die er zelf voor kiest om regelmatig een nieuw wachtwoord te nemen. Daar is niks mis mee. Die zijn ook voldoende gemotiveerd om het goed te doen. Dat kun je dan maar beter respecteren dan de goede wil op het spel te zetten met dwang.

Ten slotte zit er aan iedere verandering van wachtwoord ook nog een risico vast. In de eerste plaats verlies van productiviteit omdat mensen opnieuw moeten inloggen, typefouten maken of hun nieuwe wachtwoord snel weer vergeten waardoor ze niet meer kunenn werken. Dat soort kosten horen er natuurlijk een beetje bij maar je moet het niet te gek maken als het toch niks oplevert.

Ten tweede omdat het veranderen van wachtwoorden ook het risico met zich meebrengt dat een slimme aanvaller een nieuw wachtwoord laat instellen door de helpdesk, of zo iets. Als het veranderen van wachtwoorden uitzonderlijk is dan valt zo iets op en zou je het kunnen monitoren. Als het veranderen van wachtwoorden dagelijkse praktijk is dan kun je het eigenlijk niet monitoren zonder helemaal overspoeld te worden door onschuldige meldingen.

[hiostu]

En wie gaat voor al zijn accounts op alle verschillende websites elke x maanden zijn wachtwoorden wijzigen? Ik ken niemand die het doet. Ik denk dat zelfs nog steeds 90% van alle mensen hetzelfde wachtwoord gebruikt voor verschillende diensten.

[gooos]

Eens. Ik gebruik voor en aantal verschillende categorieën websites (mail, bank, grote shops, kleine shops, grote sites, kleine sites, etc) wel verschillende basis wachtwoorden met daaraan een toevoeging per website.

Het is iets dat ik ook al jaren geleden o.a. mijn ouders heb aangeleerd waardoor de lengte van hun wachtwoorden is toegenomen en ze tegelijkertijd minder moeite hebben om de wachtwoorden te onthouden.

[Bor]

Ik gebruik voor en aantal verschillende categorieën websites (mail, bank, grote shops, kleine shops, grote sites, kleine sites, etc) wel verschillende basis wachtwoorden met daaraan een toevoeging per website.

Dan hoop ik voor je dat die toevoeging geen directe relatie heeft met de betreffende website. Is dat wel zo dan creëer je schijnveiligheid gezien je mogelijk maar 1 wachtwoord nodig hebt om te zien hoe de toevoeging is opgebouwd.

[gooos]

Helemaal mee eens, ik heb zelf inderdaad geen relaties tot de website zelf en heb de anderen dat ook ingeprent.

[Frame164]

Een account wordt niet veiliger door iedere 2 maanden een ander wachtwoord in te stellen. Als het nog steeds slechts wordt opgeslagen of wordt gekraakt middels brute force technieken maakt het niet uit of jouw wachtwoord d^788dh+khf en na 2 maanden wachtwoord&&&2 is.

[ajakkes]

Want gebruikersnaam - wachtwoord combinaties van 2 jaar geleden gaan hackers vandaag niet als eerste proberen om te kijken of het nog steeds mogelijk is.

Oh, mijn wachtwoord 123456 is gelekt, dan maak ik er nu 234567 van. Hmm, wachtwoord vergeten, het was toch 123456. Nou laat ik dat er maar weer van maken, want dat kan ik onthouden.

[Blokker_1999]

Zowel het regelmatig wisselen van wachtwoorden als het stellen van compexiteitseisen is al jaren achterhaald en daar willen vele experts vanaf.

Zorg voor een hoge entropie, met andere woorden, zeer lange wachtwoorden aka wachtzinnen.

Stel geen eisen aan complexiteit maat sta wel zoveel mogelijk karakters toe.

Ga niet eisen dat gebruikers regelmatig hun wachtwoord veranderen, dat zorgt alleen maar voor voorspelbaarheid van een deel van het wachtwoord.

En als eindgebruiker, gebruik overal een ander wachtwoord.


Ik zelf ken steeds minder en minder van mijn wachtwoorden. De toekomst is ook wachtwoordloos, maar zal gebruik maken van tokens, bijv. Een yubikey.

[Bor]

Zowel het regelmatig wisselen van wachtwoorden als het stellen van compexiteitseisen is al jaren achterhaald en daar willen vele experts vanaf.

Het punt ligt veel genuanceerder dan je hier stelt. Je gaat geheel voorbij aan de aanvullende adviezen die worden gegeven. Zie ook de eerdere reacties.

De toekomst is ook wachtwoordloos, maar zal gebruik maken van tokens, bijv. Een yubikey.

Een yubikey zonder aanvullende maatregelen is een enkele factor ipv multifactor authenticatie en daarmee niet noodzakelijk sterker (tot zelfs zwakker). Bezit van een token is in dit geval voldoende.

[Reactie gewijzigd door Bor op 23 juli 2024 08:10]

[maniak]

Vraag me af of ze ook wachtwoorden filteren. Denk bv aan wachtwoorden die door een password manager gegenereerd zijn. Beetje nutteloos om deze wachtwoorden ook op te slaan.

[Niekleair]

Dat is zeker niet nutteloos; als het b.v. een wachtwoord van de bank is lijkt me dat je best wilt weten dat die uitgelekt is. Hoewel je bij de wachtwoordfunctie van HIBP volgens mij alleen het wachtwoord zelf kunt zien en niet de bijbehorende gegevens, is in zo'n geval er een vrij grote kans dat het ook echt jouw wachtwoord is. Als je een lang en (zeer) sterk wachtwoord gebruikt; is de kans klein dat er toevallig 2x hetzelfde wachtwoord gegenereerd is; laat staan op de betreffende site. Hoewel het een ding is voor de aanvaller om uit te vogelen bij welk account dat wachtwoord dan weer hoort wil je in zo'n geval toch echt wel gewaarschuwd worden en je wachtwoord aanpassen.

[KruimelTuimel]

Mooi project, al vele malen gebruik gemaakt van de dienst en regelmatig e.e.a. moeten wijzigen, ik juich het alleen maar toe dat de FBI wachtwoorden gaat delen.
Een nieuw wachtwoord aanmaken met Keepass en toch even door de website halen om er zeker van te zijn dat het nog niet gePwned is geeft wat extra zekerheid

[Dostar]

Prachtig om te zien hoe eerst onze Nederlandse Politie samenwerkte met een campagne en nu zelfs de FBI. Ik juich dit soort samenwerkingen alleen maar toe, beter krachten bundelen ipv verdelen.
Ik raad nog steeds collega's, familie en vrienden deze website aan om af en toe een check te doen met hun privé mail adressen en om de zoveel tijd wachtwoorden te wijzigen (in samenwerking met bijvoorbeeld een Keepass).
Zelf ben ik ook nog eens iemand die het wachtwoordenbestand ook nog eens op slaat in een Veracrypt container (samen met zakelijke documenten zoals belastingzaken etc.). Beter paranoia zijn dan zonder zijwieltjes op het web fietsen. Alles dat aangesloten is met het grote enge WWW hoor je eigenlijk zelf goed te beschermen. Helaas jammer dat niet elk bedrijf of webshop zo over jouw gegevens denkt.

[Stpan]

Ik gebruik Dashlane als passwordmanager.
En Dashlane geeft mij updates vanuit 'databases op het internet' als een gebruikt username/password combinatie gehackt is. Ik vermoed dat dit een check met HIBP is.
Maar kan deze check dan wel plaatsvinden als HIBP alleen versleutelde gegevens krijgt?

[dez11de]

FBI wil dat target z’n wachtwoord wijzigt want dat geeft een window of opportinity.
FBI stuurt account info naar HIBP.
Target krijgt melding je wachtwoord is gehackt verander je wachtwoord.
FBI lift mee.

[AddictIT]

Het is niet zo dat HIBP een melding stuurt naar een e-mail adres dat in een dataset opduikt...
Dus dit is gewoon onzin wat je zegt.

[Bor]

Toch kan je wel een case bedenken waarbij je foutieve informatie invoert en daarmee een account als compromised flagged om vervolgens via een nepbericht de gebruiker op de hoogte te brengen dat zijn / haar wachtwoord niet meer veilig is. "Kijk maar op deze gerenommeerde website". Het is wellicht wat vergezocht maar niet ondenkbaar.

[DrBackBeat]

Ehm, jawel? Een van de grootste krachten van HIBP is dat je je mailadres kunt invullen zodat je een mail kunt ontvangen wanneer je in een gelekte dataset voorkomt. Dus het is geenzins onzin wat @dez11de zegt.

[dez11de]

Google en Apple gebruiken oa die site om hun gebruikers te waarschuwen.

[hrichard]

Proactief waarschuwen is volgens mij toch echt iets anders.

[Kiswum]

Het zou mooi zijn als je bepaalde breaches weg kunt halen, doordat je account allang niet meer is gekoppeld aan die dienst. Een voorbeeld is LinkedIn, die was gekoppeld aan mijn nickname hier. In werkelijkheid heb ik al 6 jaar of langer, een ander e-mail adres gekoppeld.

[Munchie]

Dat kan al via de Opt-Out: https://haveibeenpwned.com/OptOut

Als je hebt bevestigd eigenaar te zijn van het email adres kan je vervolgens kiezen uit:

Just remove my email address from public searchability.
Alleen jij kan de database doorzoeken op je eigen email adres als je hebt aangetoond eigenaar te zijn van het email adres.

Remove my email address from public searchability and remove the list of breaches it appears in
Hierbij wordt je email uit alle huidige en toekomstige leaks verwijdert. Je email wordt dus wel bewaard zodat het automatisch uit nieuwe leaks kan worden verwijdert.

Remove my email address completely
Zelfde als bovenstaande, alleen wordt je email niet bewaard, en kan het dus in nieuwe leaks verschijnen.

[Kiswum]

Bedankt voor je reactie, hier kan ik wel wat mee.

De 4e optie (die ik eigenlijk bedoel), is verwijderen van enkele breaches, doordat je daar geen actief account (meer) hebt.

Of ik het erg vind dat mijn e-mail adres ook door andere gecontroleerd kan worden, dat vind ik niet verontrustend. Ik denk dat ik, als Tweaker, er vrij snel bij ben als er ergens een lek is geweest. Daarnaast mogen vrienden gerust checken of ik op een lijst voorkom, zodat ik daarover geinformeerd kan worden. Ik hoef dus niet anoniem te blijven.

[DickvanMaurik]

Er komt een directe route van de FBI naar HBIP voor het delen van gelekte wachtwoorden.

HBIP?
Ik denk dat het HIBP moet zijn?

[Falcon]

Daar is een forum topic voor.

[madcon]

Niet iedereen is op de hoogte van dit forum topic. Het is niet alsof er een snelkoppeling naar dit forum staat onder elk nieuwbericht.

[qvotaxon]

Klopt, dit staat erboven. "Feedback".

[nitroke]

Nee, het staat ernaast. Linkje Feedback onder de auteur van het artikel... (alvast op een computer, mogelijkse niet op tablet of smartphone)

[madcon]

Klopt, maar ik denk dat dit voor voor lezers niet opvalt. Je moet het maar net een keer gezien hebben.
Wel staat er onder een nieuwsbericht wel een grote kop met "Geef je mening!". Dat springt gelijk in het oog.

[DickvanMaurik]

Ehm, ik bedoel t niet zo
Er is een spelfout, HBIP (Have Been I Powned) of HIBP (Have I Been Powned).

[Bergen]

Ja, dat snapt hij ook. Er is een forum-topic voor spelfouten: Spel- en tikfoutjes - en dus *geen* andere foutjes - deel 45

En met de "feedback" link naast een nieuwsbericht kun je rechtstreeks naar het subforum waar dat topic staat.

[Reactie gewijzigd door Bergen op 23 juli 2024 08:10]