562.000 accounts XKCD-forum liggen op straat na hack

Het phpBB-forum van de webcomic XKCD is gehackt. 562.000 leden zijn daarbij getroffen. Gebruikersnamen, e-mailadressen, ip-adressen en md5-hashed wachtwoorden zijn uitgelekt. Volgens HaveIBeenPwned.com zat 58 procent van de mailadressen al in andere databases.

Het XKCD-forum is daarom offline totdat de omgeving weer veilig gemaakt kan worden. Data-analist Adam Davies leverde de gelekte buit aan HaveIBeenPwned, dat dienst doet als klokkenluider voor dit soort zaken. In een e-mail aan gebruikers meldt XKCD dat updates gepost zullen worden op echochamber.me, maar die site is eveneens down.

Volgens HaveIBeenPwned gebruikt het XKCD-forum de phpBB3-software. Gebruikers worden geadviseerd om eventuele gelijke of soortgelijke wachtwoorden op andere websites direct te wijzigen. Het hergebruiken van wachtwoorden is nooit een goed idee.

Correct Horse Battery Staple

Door Mark Hendrikman

Redacteur

01-09-2019 • 13:59

109

Submitter: Unstable Element

Reacties (109)

109
108
64
13
0
30

Sorteer op:

Weergave:

Net zoals bij vervuilend autorijden of het gebruik van plastic wordt ook bij paswoorden de schuld naar de gebruiker geduwd. Hoe een paswoord afgehandeld wordt aan de serverzijde is veel belangrijker dan wat het paswoord eigenlijk inhoudelijk is. Maar daarrond zijn er nog veel misverstanden, wanbeleid een totaal gebrek aan certificatie. Als jou complex en lang paswoord in plain text opgeslagen wordt op een server is het een waardeloze beveiliging. Het raden van het paswoord van een individu is een stompzinnige en zichtbare bezigheid terwijl het downloaden van een volledige userdatabase een onopvallende transfer van enkele seconden is.
Je moet er als gebruiker eigenlijk altijd vanuit gaan dat elke service jouw wachtwoord plaintext opslaat, en daar je wachtwoordmanagement op aanpassen. Vaak hoef je niet eens iets te hacken, als je een website opzet en daar mensen zo ver krijgt om te registreren (al dan niet met enige tegenprestatie) heb je hun username, e-mail en wachtwoord te pakken. Als je wachtwoorden hergebruikt kan ik daarmee waarschijnlijk je mailbox in en zo eventueel toegang krijgen tot nog veel meer zaken (digid, bank, etc). Als je niet hergebruikt is in dit geval de schade enkel tot dit forum beperkt.
In die situatie is ook een andere XKCD relevant.
Hoewel je gelijk hebt, geef je met jouw antwoord precies het probleem aan dat Billy ook aanstipt. Je laat de gebruiker het probleem van de site die een wachtwoord eist oplossen.
Helemaal niet. Het is in je eigen belang goed wachtwoord management te doen. Als ik ook maar op 1 manier jouw hergebruikte wachtwoord achterhaal, of dat nou via de post-it, een hack, social engineering of wat dan ook is, heb ik toegang tot jou volledig digitale leven.

Ja, het is een probleem dat sites hun wachtwoorden verkeerd opslaan en daar zijn gebruikers de dupe van. Maar het blijft je eigen verantwoordelijkheid om je risicio's te beperken door zelf goed wachtwoord management uit te voeren.
het sleutelbeleid van je voordeur heb je toch ook zelf in beheer? Of outsource je dat ook naar de fabrikant van je deur?
Het sleutelbeleid wel, maar hoe sterk je slot is weet je niet als consument zijnde. Zo was er een aantal jaar geleden een ophef over fietssloten. (https://www.lockpickinguniversiteit.nl/axa-fietssloten/) Je kan je sleutel nog zo veilig hebben bewaard als consument. Het slot zelf moet ook in orde zijn.

Het ligt aan de sitebeheerders om alle gegevens goed te beveiligen, en het ligt aan de gebruiker niet overal dezelfde sleutel voor te gebruiken omdat je dan een single point of failure hebt.


Als je door deze hack als consument al je wachtwoorden moet gaan wijzigen ligt dat bij de consument, maar je sleutel kan nog zo sterk en uniek zijn als je zonder moeite binnen kan komen omdat het raam openstaat maakt niemand die sterke sleutel iets uit.
leuke vergelijking, maar ook daarbij is het zo dat jij je sleutel beheerd, en als de slotenmaker jouw sleutel uit hun database lekt dan ben je bij dat feistslot net zo genaaid. En als je dan 200 fietsen hebt, dan probeer je daar ook bij elke fiets een andere sleutel te gebruiken.
Dat is exact wat ik bedoel, Als consument wordt je geacht een goede sleutel te hebben, maar ook dat je slot gewoon goed moet zijn. Het een sluit het ander niet uit.
voor sloten heb je een keurmerk, voor websites niet. Je hebt de veiligheid bij fietssloten dus in de hand door een goedgekeurd slot te kopen, alsnog ligt daar een grote invloed bij je zelf, zoals dat ook is bij wachtwoorden op het web.
AXA sloten hadden ook een keurmerk. En de sloten die lek waren werden ook nog door verzekeringen geadviseerd.

Keurmerken zeggen helemaal niets.
Zelfs als er keurmerken voor websites waren, blijft het een race, en elk keurmerk zou snel achterhaald zijn. Equifax was trouwens SOC 2 gecertificeerd, wat waarschijnlijk voorafgaand aan hun breach ook wel als argument aangedragen zal zijn voor hoe veilig ze wel niet zijn (waren).
Je hoeft je wachtwoord alleen te wijzigen als je het ook op andere sites gebruikt.
(en op kxcd, als je daar je account wilt behouden)
het sleutelbeleid van je voordeur heb je toch ook zelf in beheer? Of outsource je dat ook naar de fabrikant van je deur?
Het slotbeleid en niet het sleutelbeleid! Je ww hergebruiken is wellicht overal hetzelfde slot installeren, niet alleen thuis, maar ook bij de baas, in de kroeg, je locker bij de sportschool, die vage sex club, etc. Een slecht ww gebruiken is daarnaast nog eens equivalent aan zo een diskettebak slotje gebruiken, die we als we weer eens de sleuteltjes niet konden vinden openmaakte met een paperclip...

Het verschil met dergelijke (web) diensten is echter dat je 0,0 controle heb over wat voor deur je krijgt en wat voor slot daar op past. Een dun triplex deurtje ziet er aan de buitenkant in dit geval hetzelfde eruit als een bankkluisdeur. Er vanuit gaan dat die deur wel op orde is, is dom! Dus ook aan de user om voor elke login een uniek ww te gebruiken, ja dat is lastig, maar beter dan je indentiteit gestolen worden.
En wat denk je dat de gebruiker vanuit gaat? Dat het veilig wordt opgeslagen.
Dat is echt heel dom. Als jij wilt dat ik iets voor je doe, en ik vraag "okee, wil je dan even een pincode afspreken zodat ik volgende keer weet dat jij het bent?", geef je dan ook de code van je bankpas? Ik zal er zorgvuldig mee omgaan hoor!
En ik kan je pincode heel zorgvuldig opslaan, maar ik heb hem dan wel. En elke keer dat je aan mij moet aantonen dat jij het bent vertel je nogmaals je pincode aan me. Je zet 'm nog net niet in de krant, bij wijze van spreken.

[Reactie gewijzigd door DataGhost op 26 juli 2024 14:16]

Als gebruikers per website/service/whatever een uniek wachtwoord zouden gebruiken zou het nut van hashing bijna nihil zijn. Dus ergens is een zwak wachtwoord, ongeacht hoe de service hun data behandeld, een user-error. Dit plus het feit dat alle 'echt' belangrijke services nu ook al 2-step verification ondersteunen. Vind ik dat het nog steeds de fout van de gebruiker is als ze gehacked worden door middel van een leaked database.

[Reactie gewijzigd door Single Core op 26 juli 2024 14:16]

Niet helemaal waar natuurlijk. Een goede hashing van de wachtwoorden voorkomt dat bij een data breach er onmiddelijk misbruik kan gemaakt worden van die wachtwoorden. Met wat geluk is het daarna mogelijk om die inbraak te detecteren voordat er effectief misbruik gemaakt wordt van de ontvreemde data.
Ongeacht welke hashing method gebruikt wordt kan een zwak kort wachtwoord snel worden gebruteforced. De enige benodigdheden hiervoor zijn de hash, corresponderend algoritme en de hardware. Een kort wachtwoord gehashed met een goed algoritme blijft een kort wachtwoord.

Edit: oke, ik moet toegeven dat het gebruik van een goed algoritme dit proces uiteraard extreem vertraagd. Maar brute-force bij een kort wachtwoord blijft wel degelijk mogelijk.

[Reactie gewijzigd door n9iels op 26 juli 2024 14:16]

Daarom is het ook best practice om salting toe te voegen aan de hashfunctie
Salting is om te voorkomen dat hashtables gebruikt kunnen worden

Doordat je iets toevoegd, is de entropy ook groter, dus duur het brute force langer, maar dat is niet de primaire reden
Je voegt per definitie geen entropy toe want de salt is plaintext bekend. Je voegt wel data toe, dus het enige wat langer duurt is het "inlezen" van die data, maar in de praktijk is een salt eigenlijk nooit langer dan 1 kB dus dat is een druppel op een gloeiende plaat als je hardware minder dan 25 jaar oud is.
Salt kan ook algoritmisch gegenereerd worden per gebruiker en hoeft daarmee niet plaintext bekend te zijn.

Denk daarnaast ook aan private / public key constructies, waarmee je een wachtwoord kunt valideren.

[Reactie gewijzigd door djwice op 26 juli 2024 14:16]

Dat voegt ook geen entropy toe, en de gebruikersnaam (of net wat je uiteindelijk gebruikt) is wel plaintext bekend dus is het triviaal om daaruit het salt te krijgen.
Anders gezegd, het verlengt het bruteforcen niet met een meer-dan-constante factor, waar de lengte van het wachtwoord dat wel doet (exponentieel).
Denk daarnaast ook aan private / public key constructies, waarmee je een wachtwoord kunt valideren.
?? Is dat iets wat in de praktijk gebruikt wordt in de context van consumenten en websites? Het ging hier over het nut van hashing van unieke wachtwoorden, over de impact van korte wachtwoorden, en vervolgens over de vraag of een salt entropy toevoegt aan het wachtwoord en/of het bruteforcen verlengt.

[Reactie gewijzigd door DataGhost op 26 juli 2024 14:16]

Jij gaat uit van een salt dat plain tekst is opgeslagen, ik geef aan dat zulks niet hoeft, waarop jij weer je eerste veronderstelling als reactie geeft; input voor salt algoritme is plain text.

Die aanname is niet juist, dat hoeft dus niet. Ik geef een beetje context aan wat voor een algoritmes je dan kunt denken, maar ik geloof dat die niet aankomt, omdat ik te weinig context mee gaf voor jou om het verband te leggen. Sorry.
Ik reageerde op de opmerking dat je meer entropie krijgt als je een salt gebruikt, en ik stel dat dat onjuist is, omdat het salt of "plaintext" is (ergens opgeslagen) of op een deterministische manier uit een andere plaintext berekend kan worden, waardoor het salt effectief een constante is (want dat is een salt per definitie). Een uiteindelijk bekende constante heeft geen entropie. Dat is wat ik bedoel met "plaintext". En daardoor duurt bruteforcen niet langer (behoudens een *constante* tijdsfactor) met of zonder salt, dus korte wachtwoorden zijn slecht en daar verander je met een salt niks aan.

Geef me anders eens een voorbeeld van hoe jij een salt genereert die niet gebaseerd is op enige plaintext, maar waarmee je wel later kan controleren of de gebruiker nogmaals zijn originele wachtwoord heeft opgegeven? En je krijgt bonuspunten als je kan bewijzen dat je met dat salt entropie toevoegt.
Dat verbetert niks tegen een brute-force attack. Salting is alleen nuttig om rainbow tables buitenspel te zetten, en om het moeilijk te maken om te kijken of twee wachtwoorden uit verschillende dumps gelijk zijn of niet. Het salt moet ergens plaintext opgeslagen zijn, en of dat nou 1 byte is 1 megabyte lang is maakt niet uit voor een wachtwoord van 2 tekens. Je hoeft namelijk in beide gevallen maar 2 tekens te bruteforcen.

Ik ben het met Single Core eens, als je verschillende wachtwoorden gebruikt mogen ze het wat mij betreft plaintext opslaan (zolang het misbruik van die specifieke service geen nadelige gevolgen voor mij heeft). Het uitlekken van gegevens bij service A heeft voor mij dan geen impact op service B. Hashing is in eerste instantie ingezet om te voorkomen dat "jouw wachtwoord" inzichtelijk is voor jan en alleman, enerzijds omdat het nog niet gangbaar was om verschillende wachtwoorden te gebruiken, en anderzijds om te voorkomen dat je met een SQL injection de plaintext wachtwoorden in handen kan krijgen om die service (en andere) als een ander te misbruiken. Salting is daarna algemeen geworden omdat rainbow tables het idee achter hashing teniet deden. Zowel hashing als salting voegen in die zin dus geen complexiteit toe aan het bruteforcen van iets (met "geen complexiteit" bedoel ik "slechts een constante tijdsfactor"). Maar omdat het misbruik van een service doorgaans wel nadelige gevolgen voor mij kan hebben, ben ik wel blij als die technieken gebruikt worden, ook al heb ik zelf veilige en willekeurige wachtwoorden.
Als je naar 1 wachtwoord kijkt heb je gelijk. Kijk je echter naar je hele database, dan heeft het toevoegen van een salt wel degelijk een functie tegen brute-forcen. Door het toevoegen van een salt maak je eigenlijk een uniek 'algoritme' per wachtwoord. Met salt genereer je een hash en kun je dit proberen te matchen op 1 wachtwoord hash. Zonder salt kun je die hash vergelijken met alle wachtwoorden.

Doen we even de (compleet incorrecte aanname) dat er hier 500.000 unieke wachtwoorden zijn dan is dan heb je in het geval van het niet gebruiken van een salt ongeveer 500.000 keer sneller een match. Dat is een verschil tussen 1 dag en 1369 jaar.
Nog mooier is het als een deel van de salting per user in code wordt gedaan.
Dan is het bemachtigen van de database niet direct voldoende om op basis van salt+hash gelijk een werkend wachtwoord te kunnen bepalen, maar moet een hacker ook nog eerst zien te achterhalen hoe de salt exact wordt bepaald of moet hij toegang tot de broncode hebben.
Het is natuurlijk wel zo dat als deze salt-bepaling vervolgens bekend is deze gelijk ook geen toegevoegde waarde meer heeft.
We hebben het nu specifiek over wachtwoorden dus, blijft mijn statement waar, indien de gebruiker per site een uniek wachtwoord zou gebruiken zou dit niet uitmaken of het wachtwoord nu in plain-text hebben of niet. En kan deze ook niet gebruikt worden voor andere zaken.

Nu van die website zelf, deze is gehacked dus daar is uw data sowieso verloren ongeacht hoe veilig / uniek uw wachtwoord was.
Als gebruikers per website/service/whatever een uniek wachtwoord zouden gebruiken zou het nut van hashing bijna nihil zijn
Correct. Maar dat doet niemand. Waarom niet omdat het te moeilijk , te lastig of te veel tijd kost. En het ontslaat niemand van het goed en veilig opslaan van data.
Dat is het probleem, niemand doet het. Een password manager is een zeer handige tool...
Voor infrequent gebruikte logins is de waarschijnlijkheid groot dat de gebruiker het wachtwoord niet herinnerd.
Je hebt dan de volgende situatie:
* Gebruiker gebruikt altijd de wachtwoord reset procedure als hij wil inloggen. Dat is vaak het ontvangen van een e-mail met een link waarop geklikt moet worden.
* Hacker/koper van gehackte data raad wél het wachtwoord en logt in.

Dus voor infrequent gebuikt zou een site veiliger zijn door alleen een one time login procedure te hebben.
Hoe die procedure veiliger te maken dan het e-mailen van een link is de volgende puzzel die je mag oplossen.
Uiteraard in de praktijk zijn veel sites nu even veilig als zo'n reset e-mail.

[Reactie gewijzigd door djwice op 26 juli 2024 14:16]

Link mailen via een veilige verbinding.
Eventueel een speciale mailserver met 2fa.
Maar feitelijk is dat al mogelijk op allerlei diensten waar je met je Google, Facebook of ander account op kan inloggen.
Tenzij je wachtwoord al eerder uitgelekt is of je wachtwoord in de top 100 meestgebruikte wachtwoorden staat maakt je wachtwoord niet veel uit. 2FA/MFA en goed pogingen in de gaten houden werkt beter.
Stukje hierover: https://techcommunity.mic...oesn-t-matter/ba-p/731984
Net als de voorbeelden die je geeft moet het geen óf óf situatie, maar een én én situatie zijn. Zowel de consument als de producent/website moet hier mee bezig zijn.
Even offtopic: gebruik en afval van plastic ligt wel degelijk bij de eindgebruiker.
Regeringen geven af op plastic en overal ligt of drijft er plastic maar dat ligt niet aan de bedrijven die het maken want plastic is een fantastisch en duurzaam product. Het ligt aan de eindgebruiker, de mens dus. Zouden ze een beetje gezond verstand gebruiken dan zou het nu niet zo erg zijn. Maar neen ze gooien maar alles maar weg zonder nadenken en nu klagen ze de bedrijven aan?
Dat noem ik hypocrisie en dom.

[Reactie gewijzigd door LeStef op 26 juli 2024 14:16]

Dat is te kort door de bocht.

De bedrijven maken troep, wij hebben geen keuze. Hoe wil jij een stukje vlees bij de supermarkt halen zonder dat daar een plastic bakje en plastic sealtje om zit?
Of wil je beweren dat je dat plastic meerdere malen gebruikt omdat het zo zonde is weg te flikkeren?

Nee, 90% van het plastic is gewoon one-use->junk.
Dat ligt echt niet aan de mensen die geen keuze krijgen, maar aan de bedrijven die willens en wetens de atmosfeer volpompen en de zeeën volgooien.
Dat is een opmerking die nog korter door de bocht is.

Verpakken we het stukje vlees of de groente niet in plastic, dan blijft deze veel minder lang houdbaar. De plastic zorgt er in deze gevallen dus voor dat we het vlees en de groente langer kunnen bewaren wat er vervolgens weer voor zorgt dat er minder voedsel wordt verspild. Want dát is een hele grote bron van vervuiling.

Mensen hebben altijd een keuze. Hoeveel moeite kost het om je afval te scheiden of niet eens scheiden maar überhaupt even vast te houden om het in een prullenbak te gooien. Jij als consument bepaalt zelf wat je met je afval doet, een bedrijf gaat toch niet betalen om een butler achter je aan te laten lopen die de hele dag jouw afval opruimt..

[Reactie gewijzigd door Fidesnl op 26 juli 2024 14:16]

Ja, dat is een goede afweging die ik over het hoofd gezien heb, maar neemt niet weg dat het gros van het plastic one-use is.

Klein lijstje met voorbeeldjes:
Blister-verpakkingen zijn tegen diefstal, maar is one-use.
Vleesverpakkingen is om het vers te houden tot je het aanbruikt, one-use.
Om je vlees na openen vers te houden zijn er die kleine boterhamzakjes, die zijn vaak te zwak om meermalen te gebruiken en gaan 1 keer mee.
Diepvrieszakjes zijn vaak meermalen te gebruiken, mits de zakjes schoon/heel blijven en aangezien er vaak rauw vlees of rauw spul mee verpakt wordt gaat dat ook maar 1 keer mee.


Voor al deze dingen zijn eigenlijks geen betere dingen te verzinnen want we hebben al een werkende oplossing, dump het de oceaan in, we zitten nou eenmaal met dit plastic overschot en als we het niet inzien dat het one-use is dan blijven we wijzen naar anderen en gaan we geen oplossingen verzinnen.


-edit:
Je hebt zelf de keuze om plastic bakjes van bijvoorbeeld Tupperware te kopen die jaren (>10) meegaan en je vlees en kaas iedere dag vers houden.
Curver bakken for the win. Tupperware slechte ervaringen mee :P.

En om nog even wat on-topics toe te voegen, we hebben ook problemen met het recyclen van wachtwoorden :P.

Ik heb zelf een ander systeem aangenomen. Gewoon een paar keer per week/maand een nieuw wachtwoord aanvragen en even noteren. Of alleen wanneer ik de service/game nodig heb. Of helemaal niet een nieuw wachtwoord maken maar het voorgestelde stringetje te gebruiken.
Het e-mail adres waar al deze forgotten-pass-mailtjes op binnenkomen staat natuurlijk achter 2-factor en heeft natuurlijk een mogelijkheid de account terug over te nemen via recovery email bij een andere service.

[Reactie gewijzigd door Yezpahr op 26 juli 2024 14:16]

Ik zal hier kort op in gaan, maar daarna niet meer want dit nieuwsartikel gaat over gehackte accounts.
Vleesverpakkingen is om het vers te houden tot je het aanbruikt, one-use.
Door deze one-use verpakking blijft het langer houdbaar, waardoor het minder snel hoeft worden weggegooid, waardoor minder geproduceerd hoeft te worden enz. enz. Ik denk dat de voordelen van plastic in dit geval vele malen groter zijn dan de nadelen.
Om je vlees na openen vers te houden zijn er die kleine boterhamzakjes, die zijn vaak te zwak om meermalen te gebruiken en gaan 1 keer mee.
Je hebt zelf de keuze om plastic bakjes van bijvoorbeeld Tupperware te kopen die jaren (>10) meegaan en je vlees en kaas iedere dag vers houden. Waarschijnlijk is dit ook nog voor jezelf goedkoper dan iedere maand een nieuwe rol plastic zakjes te kopen.

Je moet zelf voor iedere situatie afwegen wat de juiste keuze is, maar daarvoor met je jezelf wel van tevoren goed informeren.

[Reactie gewijzigd door Fidesnl op 26 juli 2024 14:16]

Even offtopic: gebruik en afval van plastic ligt wel degelijk bij de eindgebruiker.
Als eindgebruiker kan ik niet kiezen of de producten die ik koop in plastic zitten of niet.

Als eindgebruiker hou ik elke snipper plastic apart, maar omdat fabrikanten tig soorten plastic door elkaar gebruiken, vaak ook nog in één verpakking en zelfs in combinatie met non-plastics (zoals gelamineerde melkpakken), is het recyclen ondoenlijk. Ook daar heb ik nul invloed op.

Dus ja, dat zijn toch echt hoofd-oorzaken die bij bedrijven en overheden liggen.

PET-flessen vervangen door afbreekbaar plastic is al jaren mogelijk, maar ja, dan wordt die fles cola 2 cent duurder. Dat kan natuurlijk niet.
Je hebt zeker een punt, maar PET is wel prima recyclebaar gelukkig en wordt ook volop ingezameld, o.a. vanwege het statiegeld en omdat het vrij makkelijk te scheiden is. 95% van de petflessen wordt zelfs gerecycled. Extreem ongelukkig voorbeeld dus...
Het is juist een prima voorbeeld. 95% recyling is prachtig, maar dat is van de grote flessen, omdat daar statiegeld op zit. De cijfers van het andere plastic zijn minder rooskleurig, maar zelfs als je alleen naar PET kijkt is dit maar een deel van het verhaal. Uit het artikel wat je linkt:
De huidige lage inzamel- en recyclingpercentages van kleine kunststof flesjes (20% en 18%) geven wat dit betreft geen aanleiding tot optimisme.
Kleine PET-flesjes zijn goed voor 13% van het zwerfafval en het duurt 1.000+ jaar voor het verkruimeld.
Gebruik van Plastic ligt in eerste instantie bij de producenten. Eaar ik een paar jaar terug nog een komkommer bij de supermarkt kon kopen zonder plastic er omheen is dat nu onmogelijk. Ik heb daar niet om gevraagd, het is me opgedrongen.
Ik gooi het dan wel weer netjes bij het plastic afval.
Jij als individu niet, maar als collectief kochten meer mensen de komkommers verpakt in plastic en minder degene zonder plastic. Mensen kopen groente en fruit wat er het perfectste uitziet en laten de minder dan perfecte exemplaren liggen. Daardoor gaan producenten er alles aan doen dat de producten zo goed mogelijk blijven en er zo perfect mogelijk uitzien. En een van de oplossingen was plastic verpakken. Dus uiteindelijk bepaalt de consument vaak het gedrag van de producent.
Door die plastic blijft je komkommer langer houdbaar, hoef je het minder snel weg te gooien, hoeven er minder komkommers geproduceerd te worden en dus ook minder vrachtauto's te rijden om de supermarkt te voorzien van nieuwe komkommers.
Moeten die producenten dan je handje vast houden dat je het plastic in het juiste Vuilbakje dumpt of gebruik je gezond boeren verstand? Dat bedoel ik. Wij als mens zijn het probleem niet de producenten. Hebben die toch geen schuld dat de eindgebruiker het maar overal stort.
Dat plastic is geen echt plastic maar waarschijnlijk een bio afbreekbare stof uit suiker of zetmeel. Als je het weggooit dan rot het zakje even snel als de inhoud.
Precies om dit soort gebeurtenissen maak ik al een geruime poos gebruik van een betaalde cloud base wachtwoord manager. Nooit meer wachtwoorden onthouden, overal een uniek wachtwoord en mijn huidige wachtwoord manager scant ook nog het internet af naar lekken. Indien jij voor een gelekte dienst een wachtwoord hebt opgeslagen krijg je een melding dat je je wachtwoord moet veranderen.

Kan het iedereen aanraden.
Maar hoe groot is de schade als nou net die ene manager gekraakt wordt? Dan is de schade niet te overzien, in tegenstelling tot wanneer je wachtwoord van 1 site uitlekt.
Password managers zijn veilig [punt] en daarmee uit. Ja uiteraard zit er een kern van waarheid in. Een password manager slaat gegevens op m.b.v. van encryptie op basis van jou hoofd wachtwoord, heb je een sterk hoofdwachtwoord is je data ook goed beveiligd. Zelfs als een manager wordt gekraak kan men niet bij jou kluis en lekken er geen wachtwoorden uit. Je bent hierbij dus afhankelijk van hoe goed het bedrijf waar jij de service afneemt zijn zaken op orde heeft. Maar als je bezorgd bent over dit risico kun je uiteraard ook gebruik maken van een open-source of offline password manager. En tot slot is er natuurlijk ook gewoon het wachtwoord boekje, daar is ook niks mis mee.

Ik ben hier redelijk fel in omdat het gebruik van een password manager, ondanks het door jou beschreven "risico", gewoon veel veiliger is dan overal hetzelfde zwakke korte wachtwoord. De kans dat dit zwakke wachtwoord op duikt in een lek als dit is vele malen groter dan dat een password manager wordt gekraakt.

[Reactie gewijzigd door n9iels op 26 juli 2024 14:16]

Dit inderdaad. Als je geen wachtwoordmanager gebruikt betekent dit dat je wachtwoorden hergebruikt. Een gemiddeld persoon heeft 150 tot 200 accounts. Daar kan je nooit allemaal een uniek wachtwoord voor onthouden.

Het hergebruik van wachtwoorden is een veel groter risico dan dat je password manager gekraakt wordt.
Ik zou al blij worden als mensen in ieder geval voor belangrijke zaken sterke en unieke wachtwoorden gebruiken. Bank, digid, email. Dat je vervolgens voor bijvoorbeeld wat random online fora een niet (geheel) uniek wachtwoord gebruikt is ze dan nog prima te vergeven. Zou nog blijer worden als mensen 2FA gebruiken, dan is zelfs password recycling een iets minder groot probleem (als online diensten eens wat beter over logins zouden informeren.). En ‘t liefst beiden, unieke wachtwoorden + 2FA, maar dat gaat hem helaas gewoon niet worden voor de meesten. ;(

[Reactie gewijzigd door WhatsappHack op 26 juli 2024 14:16]

Een gemiddeld persoon heeft 150 tot 200 accounts
Heb je daar een bron voor?

Ik schat dat ikzelf zo'n 30 heb. Dan zal ik vast een aantal vergeten, maar meer dan 50 zal het niet zijn. Ik ben wel kritisch waar ik een account aanmaak en of dat ook echt nodig is, maar ik zou niet direct verwachten dat ik heel erg onder gemiddeld zit met dat aantal.

Voor bank, email en digid heb ik unieke wachtwoorden die ik nergens anders gebruik. Voor minder belangrijke zaken gebruik ik wel een paar dezelfde. Ik weet wel dat ik eigenlijk zou moeten overstappen naar een wachtwoordmanager, maar heb daar nog nooit de tijd voor genomen.
Geen idee hoeveel ik er precies heb,
Maar VEEL meer dan 30

Ik denk dat ik alleen al 20 accounts heb voor dingen die ik echt nodig heb (verzekeringen, gwl, huur etc.)
Nog eens 20 a 30 voor dingen als email en websites die ik dagelijks/wekelijks gebruik.

Maar dan heb ik nog ontelbare websites waar ik ooit iets besteld heb, ooit iets heb willen lezen/downloaden waarvoor ik een account nodig heb. Of 20 jaar geleden actief op was, maar ondertussen nooit meer kom.

Zelfs mijn ouders, die zo min mogelijk met internet mee doen als ze mee weg kunenn komen, hebben ondertussen 2 a4 tjes vol met wachtwoorden.
Daar komt bij dat ik mijn wachtwoord manager maandelijks betaal en zij dus een constante stroom aan inkomsten hebben waarop zijn personeel kunnen aannemen. Daarnaast heeft het bedrijf nog een bug bounty programma waarmee er aangemoedigd wordt om lekken te zoeken in de software.
Dat levert alleen echt geen enkele garantie of perse hogere kwaliteit. Ik zou zelf sowieso geen belangrijke wachtwoorden stallen in iemand anders’ cloud. Lekker offline en zelf veilig back-uppen. ‘T liefst een opensource manager.
open source = niet veiliger dan closed source.

Open source geeft je enkel de mogelijkheid om de broncode in te zien, maar ik neem niet aan dat jij van TrueCrypt/VeraCrypt de broncode hebt bekeken alvorens daar je wachtwoorden in op te slaan..
Ik heb dan ook nergens gezegd dat opensource veiliger is dan proprietary code... Sterker nog, ik wijs mensen hier er al jaren op dat FOSS geen garantie/synoniem voor veiligheid is en daar kan je meerdere (zeer) uitgebreide comments van me op na lezen. ;)

Waarom zou ik m’n wachtwoorden trouwens in VeraCrypt opslaan? oO Dat is geen passwordmanager, lol. Sure je kan het ervoor gebruiken I guess, maar... Bijster gebruiksvriendelijk zou ik dat niet noemen.

[Reactie gewijzigd door WhatsappHack op 26 juli 2024 14:16]

En tot slot is er natuurlijk ook gewoon het wachtwoord boekje, daar is ook niks mis mee.
Dit is echt onderbelicht, en de veiligheid van ‘off-grid’ oplossingen anno 2019 wordt enorm onderschat door techies.

Een online passwordmanager (cloud of op een online device) is toegankelijk voor de hele wereld en duizenden hackers zijn continu bezig toegang te krijgen tot die services. Ook al wantrouw je de cloud en staat je password wallet op je telefoon of je PC ben je maar 1 exploit verwijderd van een transfer van die wallet naar anderen die ze op industriele schaal kunnen gaan kraken.

Daarentegen, wachtwoorden op papier zijn enkel toegankelijk voor mensen die fysieke toegang hebben tot je huis (da’s een nogal kleine subset) en nog eens weten waar dat papiertje ligt (een nog kleinere subset).

Phishing is een probleem dat je met geen van beide oplossingen oplost, overigens. Hoe veilig je je passwords ook opslaat, als je ze aan de verkeerde vertelt...idem met keyloggers en andere client-side hacks.
Dus jij bewaard je spaargeld ook in een sok onder je matras omdat duizenden hackers continue proberen banken hacken?

Overigens is mijn ervaring dat een mensen met een wachtwoordboekje ook heel lui kunnen worden. "Ja dat schrijf ik later wel op, ik gebruik nu gewoon even mijn standaard wachtwoord". Daarnaast vraag ik mij ook af wat mensen doen met dat boekje als ze op het werk een wachtwoord moeten intypen. Meenemen? Lijkt me nogal onveilig.
(In situaties waarin iemand al moeite heeft met het bedienen van een PC juich ik een wachtwoord boekje enkel toe. Het gebruik van een manager zal namelijk dan juist de boven genoemde situatie veroorzaken.)

Je bent nooit 100% veilig, zo simpel is het. Het gaat altijd om je threat model en wat voor jou van toepassing is. Als ik de risico's afweeg tussen ~150 account wachtwoorden onthouden, of ze in een kluis stoppen met een wachtwoordzin als wachtwoord, heb ik mijn keuze gemaakt. Daarnaast ook wetend dat ik 2FA heb waar mogelijk, wat weer een extra drempel erbij is.

[Reactie gewijzigd door n9iels op 26 juli 2024 14:16]

Dus jij bewaard je spaargeld ook in een sok onder je matras omdat duizenden hackers continue proberen banken hacken?
Dat is een werkelijk bizarre vergelijking - als de bank wordt beroofd ben je je geld niet kwijt. En het eerste wat inbrekers bij je thuis zoeken is cash. Bij wachtwoorden is de situatie werkelijk compleet anders.

Enne...mensen met een password manager kunnen ook gewoon lui zijn en wachtwoorden hergebruiken, dat verandert niks aan het risico. Net als phishing, zoals ik boven al schreef.

[Reactie gewijzigd door Dreamvoid op 26 juli 2024 14:16]

Ik heb nog nooit een wachtwoord hergebruikt bij mijn password manager, simpelweg omdat deze de wachtwoorden altijd netjes genereert voor mij.

Maar deze discussie heeft in essentie geen goed of fout antwoord, het draait volledig om het risico dat je wilt lopen. Ik gebruik 1Password en heb het white paper van hun security model doorgekeken. Op basis daarvan heb ik besloten dat ik het risico van een gehackte kluis zeer klein acht en daarom op hun service vertrouw. Het opschrijven in een boekje is misschien inderdaad wel nog veiliger dan dat.

Mij gaat het hier echt om het woord "veiliger". Het niveau van veiligheid en risico dat je neemt is iets dat iedereen zelf moet bepalen. Het belangrijkste wat ik mensen wil meegeven is dat zowel een boekje als kluis zeer veilig zijn en je het liefste één van die opties gebruikt.

[Reactie gewijzigd door n9iels op 26 juli 2024 14:16]

Stellig zijn dat een risico van een webservice beperkt is is niet hetelfde als het is veilig. Het hangt vervolgens ook nog van de implementaties af. Stel xkcd had de wachtwoorden beter gehashed en de crimineel had op de servers ingebroken om het ingecrypte verkeer af te luisteren dan hadden de gevoelige gegevens ook afgeluisterd kunnen worden. Had je niets aan het hashen gehad als het alleen gebruikt werd op de opslag en niet tijdens het transport. En zo dus ook met bankzaken of wachtwoordkluizen. Misschien vind je het risico niet ze zwaar, maar wat doe je als het wel mis gaat? Het is veilig [punt] is vaak geen goed uitgangspunt om je risico te beheersen.
Risicobeheersing is iets wat veel password managers bij design al doen. Vaak heb je niet enkel een hoofdwachtwoord maar ook een secret-key nodig om met een nieuw apparaat in te loggen. Deze worden beide tevens gebruik ter encryptie van je data. Daarnaast is verkeer altijd netjes over HTTPS, beveiligen ze vaak indien mogelijk het transport en bieden ze 2FA aan om je kluis te openen.

Het doemscenario is uiteraard een lek aan de kant van de password manager waardoor alles op straat komt te liggen. Maar dan kun je als eind-gebruiker ook risico beperking op doen door bijv. inloggegevens van je email niet op te slaan en 2FA (backup)codes ook appart te bewaren.
Maar hoe groot is de schade als nou net die ene manager gekraakt wordt? Dan is de schade niet te overzien, in tegenstelling tot wanneer je wachtwoord van 1 site uitlekt.
Jij snapt gewoon niet hoe dat soort passwords managers werken. Is ook echt ingewikkeld maar feit is dat het risico gewoon klein is. Veel minder groot dat jou lokale passwords gevonden worden.

Er zijn honderden links maar dit is er een die makkelijk te begrijpen is: https://www.techlicious.c...er-stored-passwords-safe/
Je kan ook de ultra-paranoïde modus gebruiken:
Een lokale password manager. bv Keepass(X) .
Dan moet je wel zeker weten dat jij beter bent in het beveiligen van je laptop dan LastPass en dergelijke bedrijven in het beveiligen van hun database. (Of zoals ik een hekel hebben aan alles waar 'cloud' in voorkomt en tegen misschien wel beter weten in alles lekker in eigen beheer willen houden).
Dat je ervoor betaalt maakt de dienst niet per-se veiliger.

Gratis en Open-Source oplossingen bieden deze functionaliteit ook.
Dan nog de vraag, welke?
Niet betaald, en in eigen beheer ... keeppass.
Gewoon je database opslaan waar je wilt, grote cloudboer of op je eigen NAS/Server
Dan heb jij wel erg veel vertrouwen in een externe partij. Als ik jou was dan zou ik ook de pincode van je bankpas erbij stoppen dan weet je zeker dat je de pineut bent als deze database wordt gekopieerd door een derde.
md5-hashed wachtwoorden? Wow. 2007 wil z'n security vulnerability terug.
Volgens mij is dit hoe standaard phpBB-forums aangeleverd worden nog steeds, tenzij je zelf gaat tweaken er aan (wat gewoon kan door relevante modules te downloaden en te installeren)... Helaas, zoals zelfs Wikipedia doorheeft, is MD5 nog te veel gebruikt ondanks dat experts het als cryptografisch compleet kapot/onbruikbaar zien.

EDIT: Nope, zoals @ACM aangeeft was MD5 juist uitgefaseerd. Waarom hebben ze in vredesnaam MD5 geinstalleerd als module?!

[Reactie gewijzigd door Verwijderd op 26 juli 2024 14:16]

ACM Software Architect @Verwijderd1 september 2019 14:31
Wellicht door een upgrade van phpbb2 naar 3? Maar dan nog zou je hopen dat die software dan automatisch wachtwoorden upgrade naar de nieuwe opslagformaten zodra een gebruiker inlogt. Daar heeft php zelfs netjes de password_needs_rehash-methode voor ontwikkeld.

En alle wachtwoorden die dan na een bepaalde tijd niet verandert zijn, moet je gewoon weggooien. Dan moet die enkele gebruiker die na zoveel tijd toch terugkomt maar een wachtwoord-reset aanvragen.

[Reactie gewijzigd door ACM op 26 juli 2024 14:16]

Hm, mogelijk. XKCD was als site actief in 2005, en dec 2007 werd phpBB 3.0 uitgebracht. Dan nog verwacht je echter dat in de tijd tussen toen en nu wel een keer de switch gemaakt zou zijn, aangezien er ook andere updates zijn uitgebracht in de tussentijd (al was het maar voor Apache en wat dan nog allemaal er mogelijk runt op de server).
ACM Software Architect @Verwijderd1 september 2019 14:48
Ik bedoelde dan ook dat ze met phpbb 2 begonnen en dat hebben geüpgraded naar 3. En daarvoor een compatibiliteits-modus voor die oude wachtwoorden gebruikten. Maar zelfs dan blijft het verwarrend en zou ik hopen dat het 'vanzelf' dan alsnog naar nieuwere formats zou zijn omgezet, sowieso voor alle nieuwere accounts.

[Reactie gewijzigd door ACM op 26 juli 2024 14:16]

Goede kans dat de MD5 tabel gewoon in de database is achtergebleven naast de nieuwe wachtwoordtabel. De wachtwoorden daarin zijn dan enorm oud en dat kan verklaren waarom een groot percentage al bekend was.
ACM Software Architect @synoniem1 september 2019 18:18
Dat de emailadressen al bekend waren zegt niet zoveel over of de wachtwoorden ook al bekend waren ;)
Ik ging er vanuit dat bedoeld werd dat 58% van de e-mailadressen met wachtwoord bekend was maar dat staat er niet inderdaad.
Ik snapte dat je bedoelde dat ze met 2 begonnen en de wachtwoorden in comp modus hadden gezet :) Daarom mijn nota re de switch.
In het bericht staat dat het grootste deel van de gebruikers al naar een andere database was gemigreerd. Ik verwacht dus dat ze die wachtwoorden wel aan het rehashen waren en dat hetgeen dat gelekt is nog niet opnieuw was ingelogd.
ACM Software Architect @jaxxil1 september 2019 14:22
Het is een hele verwarrende bewoording 'md5 phpbb3' format; ik heb geen ervaring met phpbb, maar voor zover ik kan vinden was md5 met versie 3 juist afgedaan. Met versie 2 was er nog wel een md5-versie van wachtwoordopslag. Overigens gebruikte die gelukkig wel salts, waarmee het ietsje minder erg is dat er md5 werd gebruikt.
Moest bij de titel al meteen denken aan de xkcd comic die ook in het artikel gepost is.
Rara hoe vaak dat wachtwoord of een variatie ervan in de gebruikers voorkomt…

Het verrassende vond ik dat 58% van de adressen al in de database voorkwam.
Door Rainbow tables is een kort wachtwoord sowieso uit den boze tegenwoordig.

De md5 breuk waar iedereen het over heeft is een clash in hashes die kunnen voorkomen uit verschillende ww die dezelfde hash opleveren. In praktisch gebruik zal dit niet een cryptografisch probleem opleveren. Wel betekent dit dat het tijd word om over te stappen op nieuwere hash functies waar dit soort kwetsbaarheden nog niet ontdekt zijn
ACM Software Architect @mikesmit1 september 2019 14:27
md5 is zo snel door te rekenen op gpu's dat je met brute force behoorlijk wat wachtwoorden kunt kraken binnen 'redelijke' tijd.

Uiteraard geldt hier nog wel bij dat heel lange/moeilijke wachtwoorden niet zomaar kan uitgeprobeerd zullen worden, want uiteindelijk is de 'entropy' dan natuurlijk alsnog zo hoog dat je alle mogelijke varianten proberen dan nog steeds flink wat tijd kost.
Het helpt een beetje dat phpbb zo te zien sowieso salts gebruikte bij md5, waardoor bulk-kraken geen schaalvoordelen geeft.

[Reactie gewijzigd door ACM op 26 juli 2024 14:16]

Herinner me nog dat Tweakers het gedaan heeft toen ze zelf hun methode hebben veranderd waarna iedereen met een wachtwoord dat op korte tijd (was het nu een half of een heel uur?) te kraken was een berichtje stuurde met een melding dat ze een onveilig wachtwoord hadden.

--edit--

En dan zie je 2 comments verder de link ernaartoe staan :+

[Reactie gewijzigd door Blokker_1999 op 26 juli 2024 14:16]

Ja, even kort door de bocht: MD5 is een zwak hashmiddel. Ik heb in 2011 daar mee zitten spelen en haalde met mijn destijds goedkope videokaart ongeveer 1 miljard wachtwoorden per seconde bruteforcen. Laat dat nu, net een high end videokaart ongeveer 10x meer zijn.

Als jij een lowercase wachtwoord hebt van 10 karakters is die dus in ongeveer 4 uur te kraken met normale hardware. Vuistregel is dat je je wachtwoord elk half jaar verandert én dat je een sterk wachtwoord hebt. Het idee is dat je dan nog tijd hebt dat wachtwoord te wijzigen voor degene die de database gehackt heeft jouw wachtwoord gekraakt heeft. en uiteraard moet je wachtwoorden nooit hergebruiken.
Op zich een goede regel, maar ik vindt elk half jaar passwords veranderen met de hoeveelheid accounts die ik inmiddels heb ombegonnen werk.

Ik genereer in mijn password manager passwords van 32 characters lang en laat die verder gewoon staan, dat moet maar goed genoeg zijn. (behalve voor bankzaken dan).

Valt dan trouwens nog tegen hoeveel sites passwords (al dan niet stilletjes) afkappen op bijvoorbeeld 16 characters.
Door Rainbow tables is een kort wachtwoord sowieso uit den boze tegenwoordig.
Korte wachtwoorden zijn uit den boze omwille van brute force attacks, rainbow tables werken alleen als dat (korte) wachtwoord zonder salt wordt gebruikt, waarvan ik hoop dat dat niet meer voorkomt tegenwoordig
ACM Software Architect @Verwijderd1 september 2019 14:46
Met md5, met of zonder salt, is het sowieso maar de vraag of het de moeite waard is om die rainbow tables te gebruiken... Je kan miljarden wachtwoorden (al dan niet uit een woordenlijst) uitproberen in een paar minuten tijd.

In 2011 konden we een half biljoen wachtwoorden in 16 minuten uitproberen, een RTX 2080ti is zo te zien - weliswaar met een andere hash - meer dan 10x sneller dan de toen gebruikte Radeon 6950... Overigens was die test van toen uiteraard niet 1:1 te vergelijken met deze situatie, door het gebruik van salts en een net andere manier van wachtwoord-opslag.
Daarom stoor ik me ook zo aan die XKCD tool. Als ik aan jou nu vraag om 4 willekeurige woorden vraag te noemen kan je er de donder op zeggen dat dit een van de 5000 meest gebruikte Nederlandse woorden zijn en zeer zeker wel een van de 10000 meest gebruikte woorden. Daar zijn gewoon datasets en zelfs formules voor. 10000^4 is een enorm getal maar als de aanvaller een beetje slim is en gelukt heeft zijn ook die wachtwoorden goed te kraken. Met een half biljoen(!) hashes per seconde heb je in een week tijd dan echt wel de bulk van de wachtwoorden te pakken. EN, net zoals met fietsen, is de kunst zorgen dat jouw wachtwoord sterker is dan die van alle anderen in de dataset. Onbreekbaar is geen slot maar als de dief al zijn energie zet op de fiets naast je dan wordt jouw fiets iig niet gejat.

[Reactie gewijzigd door Verwijderd op 26 juli 2024 14:16]

ACM Software Architect @Verwijderd1 september 2019 21:55
Ik denk dat de betreffende entropy nog wel iets groter is. Je moet o.a. rekening houden met wel/geen spaties/koppelteken en wel/geen (begin)hoofdletters. En een zin kan natuurlijk ook getallen bevatten, dus die moeten dan ook in je woordenlijst staan.
Maar inderdaad, als je 't slim insteekt begin je met de meest gebruikelijke combinaties. Er zijn wel diverse taalbibliotheken en -algortimen (denk aan autocomplete) die gebruikelijke combinaties van woorden bevatten.

Ik weet niet waar jij trouwens de half biljoen per seconde vandaan haalt? Onze test toen deed daar 16 minuten over. Met een RTX 2080ti en nieuwere versie van die software met wat optimalisaties kan je daar wellicht nu een halve minuut over doen en uiteraard meer als je meerdere kaarten inzet. Maar dat is met de meest eenvoudige manier van md5 inzetten.
Maar als je er inderdaad een half biljoen in een seconde kan doen, dan kan je die 10.000^4 combinaties in 20 seconde uitproberen. In een week tijd kan je dan 30.240 wachtwoorden testen.

Met modernere wachtwoordalgoritmes is het gelukkig een stuk beter gesteld. Bij fatsoenlijk gebruik ervan ben je al gauw 0.1 seconde aan het rekenen op een snelle cpu voor 1 wachtwoord. Laten we voor het gemak stellen dat het dan in 0.001 seconde kan op e.o.a. gespecialiseerd systeem (dus 1000/seconde); dan nog duurt diezelfde lijst dan ruim 300.000 jaar :)

Wat betreft jouw fietsanalogie; het is ook handig om gewoon voor iedere bestemming die je hebt een andere fiets te gebruiken. Als er dan eentje wordt gestolen, dan kan je nog veilig naar elke andere beveiliging en hoef je er maar een te vervangen (of te besluiten dat je dan niet meer naar die bestemming wilt) ;)
Maar die aanval zal dan alleen slagen wanneer de hacker weet dat de gebruiker die strategie heeft gebruikt. Het wachtwoord 1234 zal je op die manier niet weten te kraken.

Het punt is dat je bij een fiets in één oogopslag kunt zien wat een goed en wat een slecht slot is. Wanneer je een wachtwoord wilt kraken weet je niet hoe creatief de gebruiker is geweest. je kunt van meerdere gebruikers tegelijk met de simpelste vormen van de meestgebruikte strategieën beginnen, net zolang tot je ergens binnen komt.
Daarom stoor ik me ook zo aan die XKCD tool.
Ik neem aan dat je het over deze comic hebt?

Dan snap je de comic niet. Zoals velen blijkbaar.
Als ik aan jou nu vraag om 4 willekeurige woorden vraag te noemen kan je er de donder op zeggen ...
Om te beginnen dien je passphrases random te laten genereren door een computer. Mensen zijn enorm slecht in het verzinnen van willekeurige reeksen, of dat nou passwords of passphrases zijn.
... dat dit een van de 5000 meest gebruikte Nederlandse woorden zijn en zeer zeker wel een van de 10000 meest gebruikte woorden. Daar zijn gewoon datasets en zelfs formules voor.
Uiteraard gebruik je dan relatief veelgebruikte woorden! Anders krijg je woorden die ook weer lastig te onthouden zijn. En uiteraard zijn daar datasets voor!

De comic gaat zelfs uit van een woordenboek van 2048 woorden (11 bit per woord), nog kleiner dan jij noemt.

Het punt van die comic is niet dat passphrases onkraakbaar zijn; het punt van die comic is dat "correct horse battery staple" veiliger en makkelijker te onthouden is dan "Tr0ub4dor&3", en dat het dus waanzin is dat we gebruikers geleerd hebben dat tweede te doen. En daar heeft die comic 100% gelijk in.
Door Rainbow tables is een kort wachtwoord sowieso uit den boze tegenwoordig.
Bij mijn weten is een rainbow table tamelijk zinloos zodra er een salt gebruikt is.
Hash collisions zijn voor wachtwoorden niet zo'n groot probleem. Oplossing voor rainbow tables is het gebruik van salting
Naast dat hash collisions van verschillend belang zijn afhankelijk van het doeleind van het hashen, wil je ook voor het hashen van wachtwoorden vooral dat de hash min of meer alleen behoorlijk inefficiënt te berekenen is, terwijl men voor veel andere doeleinden van hashfuncties juist zo efficiënt mogelijke hashes zou willen. Dus wat aandacht bij het kiezen van een juiste hashfunctie kan niet kwaad.
Ik vind het vooral verassend dat het niet meer zijn. Met de grote hoeveelheden hacks die er geweest zijn over de jaren (waaronder LinkedIn, en recent Canva) maar ook de duizenden andere hacks moeten zo'n beetje de meeste e-mail adressen er wel eens in zitten. Maar goed, dat voegt weer ruim 200.000 nieuwe unieke emailadressen toe aan het lijstje.
Geen idee of ik een account had op XKCD, maar als dat zo was, was het een oudje met een vergelijkbaar password als andere die ook al gekraakt zijn, zoals Heroes of Newerth of Myspace.
Mijn passwords die ik dagelijks gebruik zijn compleet anders, maar die oude forum passwords waar ik nooit meer kom, die waren (en zijn) nog grotendeels allemaal gelijk. Vermoedelijke ben ik niet de enige...
99% van account hacks wordt vermeden door MFA, mss iets waar alle sites zich es mee moeten bezighouden die het zouden moeten doen.

[Reactie gewijzigd door Graviton12 op 26 juli 2024 14:16]

Erm, dat is deels appels en peren vergelijken.
Zodra een database naar buiten komt met alle gegevens (zoals in dit geval), is alsnog alle data bekend. MFA of niet.
Worst-case scenario: een hacker plaatst een forum bericht onder je naam.

Maar waar het natuurlijk om gaat is de data zelf, alle emailadressen en passwords (mits slecht gehashed).

MFA is interessant voor applicaties waarin je ook belangrijke acties kan uitvoeren: geld overmaken, zaken verwijderen (dus een admin van een forum ;) ), dingen aanschaffen, etc.

Ik ben best betrokken met security en 2FA voor een forum is voor mij echt niet benodigd. Uiteraard een groot voordeel als het wel beschikbaar is voor de gene die het wel willen.
Tijd voor een wereldwijde regelgeving dat geen inlog gebeuren in plaintext mag worden opgeslagen.
En dat het strafbaar moet worden bij wie het wel doet.

[Reactie gewijzigd door rejer op 26 juli 2024 14:16]

Hier was ook helemaal geen sprake van plain-text inloggegevens? Deze waren gewoon gehashed met md5, tegenwoordig al lang achterhaald maar het is beter dan niets.
Ik denk dat phpBB 3 gehaste md5 was, maar sinds 3.1 en boven zijn het andere algoritmes, met name sha* en bcrypt zijn in gebruik.
Voor bullshit sites altijd bullshit password en username + email. Voorkom je problems

Op dit item kan niet meer gereageerd worden.