Overheid geeft zwakke DigiD-wachtwoorden een reset

De overheid heeft alle zwakke wachtwoorden voor DigiD een reset gegeven waardoor gebruikers een nieuw sterker wachtwoord moeten opgeven. De wachtwoorden moeten naast een hoofdletter ook een cijfer en een leesteken bevatten.

De overheid laat gebruikers met een zwak wachtwoord verplicht een nieuw wachtwoord kiezen. "Enige tijd geleden zijn de wachtwoordeisen verscherpt", zo staat op de DigiD-site. De huidige eisen zijn er echter al weer een paar jaar: vereist is een wachtwoord van minimaal 8 en maximaal 32 tekens, die bestaat minimaal 1 kleine letter, minimaal 1 hoofdletter, minimaal 1 cijfer en minimaal 1 bijzonder leesteken.

Voor 2011 was het echter nog zo dat een wachtwoord alleen minimaal 1 cijfer bevatte. In 2010 gaf de staatssecretaris van Binnenlandse Zaken daarom al aan te onderzoeken of de minimumeisen aangescherpt moesten worden. De oude, zwakke wachtwoorden bleven echter gewoon werken, tot dinsdag.

Begin dit jaar kondigde minister Plasterk van Binnenlandse Zaken al maatregelen aan om fraude met DigiD te bemoeilijken. Onderdeel daarvan was het thuisbezorgen van DigiD-codes per koerier omdat de post onderschept kan worden. Ook werd overwogen om Nederlanders die een DigiD-account willen activeren, zich te laten identificeren aan de balie van de gemeente. Uiteindelijk wordt DigiD vervangen door eID, een systeem met smartcards.

Reacties (218)

[SinergyX]

Dus een 'nzdwacgzmbdn'* wachtwoord is niet veilig, maar een 'Wachtwoord1!' blijkbaar wel?

Hoe meer regels, hoe 'simpeler' men een wachtwoord kiest, dat ze kunnen herinneren of logisch is in te typen (zoals mijn voorbeeld).

Maarja, straks heb je pasje voor dit, E-reader voor dat, sim-ding voor zus, sms code voor dat, dan nog wat tokens en authenticators. Alleen omdat ze 'denken' dat zaken niet veilig zijn.

*nu zou dit wachtwoord al complex genoeg zijn, maar blijkbaar dus niet.

[aaiding]

Hoe kan men van bestaande wachtwoorden zien of deze aan de "zwakke criteria" voldoen? Deze zouden toch gehasht moeten zijn?

[David Mulder]

Moet je dit eens lezen: plan: Analyse: zwakke wachtwoorden op Tweakers.net

In totaal hebben we ruim 21 miljoen woorden uit diverse lijsten verzameld. De door ons gebruikte cracker had slechts veertien seconden (!) nodig om die lijst met ruim 330.000 wachtwoordhashes uit onze database te vergelijken. Daarna deden we nog een test met bijna een half biljoen variaties op die woordenlijsten. Hier waren nog eens zestien hele minuten voor nodig.

Uit deze test bleek dat een uitgebreide brute-forceaanval veel minder nut heeft. Het zou vele uren geduurd hebben om alle mogelijke wachtwoorden van maximaal acht tekens te berekenen - met de vrij verkrijgbare woordenlijsten hebben we in minder dan een half uur meer dan de helft van de wachtwoordhashes gekraakt.

Waar het op neer komt is dat je zelf een aanval op je eigen data kunt uitvoeren om zwakke wachtwoorden te herkennen. Of alternatief gewoon kijken op het moment dat je inlogd, wat een stuk makkelijker is natuurlijk, maar ook minder mooi

[Reactie gewijzigd door David Mulder op 22 juli 2024 22:17]

[Stry]

Inderdaad, als je beschikt over de hashes is het relatief eenvoudig om van woordenlijsten en hun variaties (papegaai4, pap3g441) ook hashes te maken en die te vergelijken met de hashes in je database.
Wat ik niet begrijp is waarom nog steeds vast gehouden wordt aan die "hoofdletter + leesteken" constructie voor paswoorden. Dat maakt het niet echt heel veel veiliger. Ik zou eerder een paswoord check uit laten voeren op een bestaande hashlijst. Een paswoord als "Vier blauwe aardappelen dansen" is moeilijker te breken en makkelijker te onthouden dan "Johnny4!".

Oblig:
http://xkcd.com/936/

[Stoney3K]

Inderdaad, als je beschikt over de hashes is het relatief eenvoudig om van woordenlijsten en hun variaties (papegaai4, pap3g441) ook hashes te maken en die te vergelijken met de hashes in je database.
Wat ik niet begrijp is waarom nog steeds vast gehouden wordt aan die "hoofdletter + leesteken" constructie voor paswoorden. Dat maakt het niet echt heel veel veiliger. Ik zou eerder een paswoord check uit laten voeren op een bestaande hashlijst. Een paswoord als "Vier blauwe aardappelen dansen" is moeilijker te breken en makkelijker te onthouden dan "Johnny4!".

Oblig:
http://xkcd.com/936/

Leg dat maar eens aan een overheid uit.

Vergeet even niet dat, wanneer je een password reset aanvraagt op je DigID, dat je dat nieuwe wachtwoord per brief toegestuurd krijgt.

Blijkbaar hebben de overheidscomputers 2 werkdagen nodig om een nieuw wachtwoord te verzinnen.

[page404]

Laat ook nou net zien dat je inmiddels kan kiezen om je wachtwoord per mail te resetten. Niks te vroeg

[macnerd]

Ik was even benieuwd en heb dus ingelogd. Moest meteen m'n wachtwoord wijzigen.

Overigens wel mooi gedaan: er wordt meteen aangegeven aan welke eisen voldaan moet worden, en zodra wordt voldaan aan een eis verandert deze van rood naar groen. Wel weer jammer is dat ze niet terug naar rood gaan als je het wachtwoord leegt maakt...

[Sando]

"vier blauwe aardappelen dansen" is in feite maar 4 tekens lang, als je een dictionary gebruikt.

[Stry]

Correct, maar op basis van de hash kan je niet weten of het 4 lange of 8 korte woorden zijn, of uberhaupt uit hoeveel karakters het wachtwoord bestaat. Verder zijn het 4 "tekens" uit (uitgaande van de Dikke van Dale) 240000, in plaats van 26, en dan is de vraag of "blauwe" en "aardappelen" daarin meegerekend worden of dat dit alleen de basisvormen "blauw" en "aardappel" zijn.
Aangezien Nederlands een vervoegende taal is (zal vast een juiste taalkundige terminologie voor zijn, maar dat weet ik niet) waarbij nieuwe woorden on the fly gegenereerd worden door bijv: aardappel + dans = aardappeldans, + sport = aardappeldanssport + wedstrijd = aardappeldanssportwedstrijd + jurist = aardappeldanssportwedstrijdjurist.
Op die manier zijn het aantal woorden in de Nederlandse taal nagenoeg ongelimiteerd.

Anyway, uitgaande van de 0.24M woorden in de vanDale heb je met 4 woorden 1 uit 3.3 x 10^21 mogelijkheden.
Met 12 willekeurige letters uit het crockford alfabet (32 bits) heb je een varieteit van 1 uit 1.15 x 10^18. Daar zit dus grofweg een factor 2000 verschil in.

[Sando]

Helder. Amen.

Maar met 200 sites die allemaal een uniek wachtwoord adviseren onthoud je dat waarschijnlijk niet en ontkom je haast niet meer aan een wachtwoordmanager oid en kunnen alle wachtwoorde net zo goed 32 tekens random zijn.

[m8ZBm1Si]

Het zal waarschijnlijk inderdaad gebeuren op het moment dat de gebruiker inlogt. Ik neem aan dat ze een sterk genoeg hash systeem gebruiken waardoor een aanval simuleren te moeilijk gaat worden.

[Zayl]

Het kan prima zijn dat ze al maanden aan het loggen zijn geweest of een wachtwoord zwak is of niet, voordat encryptie gebeurd natuurlijk.

[Grrrrrene]

Waarom zouden ze dat doen zonder meteen eisen aan het ww te stellen? Ik kan echt geen enkele reden bedenken.

Ik vind het wel goed. Sommige mensen moeten blijkbaar tegen zichzelf in bescherming genomen worden. Ik wil niet eens gokken hoeveel Nederlanders "geheim" of "wachtwoord" als wachtwoord hebben voor hun meest privacy gevoelige zaken als belastingaangifte, WW-uitkering, etc...

[Mentalist]

Waarom zouden ze dat doen zonder meteen eisen aan het ww te stellen? Ik kan echt geen enkele reden bedenken.

Wil je je belastingaangifte ondertekenen op 31 april. "Sorry, uw wachtwoord is te zwak! U krijgt binnen 5 dagen een code thuisgezonden om een nieuw wachtwoord in te stellen."

Ik vind het wel goed. Sommige mensen moeten blijkbaar tegen zichzelf in bescherming genomen worden. Ik wil niet eens gokken hoeveel Nederlanders "geheim" of "wachtwoord" als wachtwoord hebben voor hun meest privacy gevoelige zaken als belastingaangifte, WW-uitkering, etc...

Maar de eisen zijn niet goed. "Wachtw00rd!" voldoet namelijk perfect aan de eisen, terwijl "goedemorgen jongens dit is mijn digid wachtwoord" aan geen enkele eis voldoet. Geen hoofdletter, geen speciaal teken, geen cijfer en ook nog eens te lang. En toch is dat eerste wachtwoord zo gekraakt, en de tweede gaat ontzettend lang duren.

[SunnieNL]

Wachtwoorden die aan de eisen voldoen die nu gesteld worden zijn net zo gevaarlijk. Minimaal 8 tekens, minimaal 1 hoofdletter, 1 getal en 1 vreemd teken....
Dat zijn wachtwoorden die mensen snel vergeten en dus gaan opschrijven. Waarom niet minimaal 15 tekens met minimaal 1 hoofdletter. Veel praktischer, zeker als je mensen ook leert dat je hele zinnen kan gebruiken.

[Zayl]

Het kan ter observatie zijn om te analyseren hoe veel mensen een zwak wachtwoord hebben en wat de beste oplossing is

Op dit moment kan je namelijk "scannen" wat er in zit.

[m8ZBm1Si]

Dan zouden ze op moeten slaan wie er een zwak wachtwoord heeft en wie niet. Als de database lekt, is dit natuurlijk gigantisch gevaarlijk, en dit maakt brute-force aanvallen veel makkelijker.

Geen optie dus.

[Stefanic]

Klopt inderdaad, net getest en na inloggen krijg je een melding dat je je wachtwoord moet instellen omdat deze niet meer voldoet.
Staat wel een overslaan knop bij, heb hem alleen niet getest.

[CH4OS]

Staat wel een overslaan knop bij, heb hem alleen niet getest.

IMO valt daarmee de actie weer in het water. Aan de andere kant; dan kan DigiD zeggen dat het aan de gebruiker lag, niet aan hen, omdat zij wel de gebruiker adviseerden om een beter wachtwoord te kiezen.

[Jefrey Lijffijt]

Wat je ook nog zou kunnen doen is alle wachtwoorden die meerdere keren voorkomen als te simpel bestempelen, door gewoon de hashes met elkaar te vergelijken.

[Verwijderd]

Iedereen die zijn wachtwoord nog niet heeft aangepast nadat de datum dat de nieuwe wachtwoordregeling is geimlementeerd. Altans dat hoop ik

[ATS]

Waarom? Als een gebruiker al een zeer sterk wachtwoord had, waarom zou je hem dan verplichten het te veranderen?

Mijn bedrijf heeft zo'n policy waarbij je elke twee maanden je ww moet aanpassen. Bijzonder irritant. Het heeft er toe geleid dat ik van het gebruik van een zeer sterk ww ben overgestapt naar eenvoudig patroon wat ik kan onthouden maar wat wel aan de eisen voldoet (inderdaad: hoofdletters, cijfers, speciale tekens... ) . Helaas pindakaas.

[Reactie gewijzigd door ATS op 22 juli 2024 22:17]

[regmaster]

Juist, en dat is wat die suffe IT'ers maar niet willen snappen. Luisteren naar je gebruikers en niet domweg een regel invoeren omdat de IT vindt dat dat veilig is, het omgekeerde is juist waar. Sterke wachtwoorden, die ook nog regelmatig moeten worden gewijzigd, maken systemen juist onveiliger dan veilig omdat we nu eenmaal met mensen te maken hebben. Een gemakkelijk te onthouden wachtwoord i.c.m. met een token, of iets anders dat men heeft, is vele malen veiliger dan dat ene wachtwoord dat moeilijk te onthouden is en uiteraard opgeschreven en verloren zal worden. Buiten het feit nog dat wachtwoorden dan met een cijfer worden opgehoogd. Nu heeft de IT gestapo daar ook al iets voor bedacht en maken het daarmee de gebruiker nog moeilijker en dus de systemen onveiliger.
Wachtwoorden hebben voor een lange tijd hun nut bewezen maar nu wordt het toch echt tijd voor iets vernieuwends.

[Sp4c3r]

Ben ik het als IT nazi toch niet mee eens. Het feit dat het menselijk brein meer kan onthouden dan ons lief is, maar het onthouden van je eigen wachtwoord toch zo moeilijk maakt is het feit dat men hier niet het nut van wil begrijpen.
Hoe moeilijk is het om een moeilijk wachtwoord te creëren.
Letters vervangen door cijfers en leestekens en je wachtwoord is ineens 10x sterker.
De IT maakt het men niet moeilijker, het begrip dat er voor wordt gevraagd is alleen meer. Wellicht zou je eens je Wifi wachtwoord naar Welkom12345 moeten veranderen en kijken hoeveel mensen gratis van je netwerk genieten. Lekker makkelijk wachtwoord en dan de techniek de schuld geven. Kortzichtig en ondoordacht.

[Njipep]

Het punt is dat als de wachtwoorden te ingewikkeld worden geforceerd en dan vooral in combinatie met de eis om elke 2 maanden een nieuw wachtwoord te kiezen, de gebruiker er uiteindelijk klaar mee is

De IT afdeling kan dan natuurlijk regels verzinnen dat het veranderen van het wachtwoord Aardappel01 naar Aardappel02 niet mogelijk is, maar uiteindelijk eindigt dat wachtwoord dan op een Post-It die aan de monitor is geplakt

Het is belangrijk om de balans tussen gebruiksvriendelijkheid en veiligheid niet te ver doorslaat naar 1 van beide kanten.

[deadinspace]

Ben ik het als IT nazi toch niet mee eens. Het feit dat het menselijk brein meer kan onthouden dan ons lief is, maar het onthouden van je eigen wachtwoord toch zo moeilijk maakt is het feit dat men hier niet het nut van wil begrijpen.

Daar ben ik het echt niet mee eens. Ik ken veel verschillende wachtwoorden uit mijn hoofd, waaronder een stevige dosis random gegenereerde wachtwoorden (a la p56ps7j94d) en passphrases. Ik specialiseer me in information security; ik ben goed bekend met information theory, cryptografie, authenticatie.

Ik snap echt het nut van wachtwoorden wel. En weet je? Ik vind wachtwoorden nog steeds kut.

Tuurlijk, mensen kunnen wachtwoorden onthouden, maar het is niet makkelijk. En de wachtwoorden moeten sterk zijn, het zijn er veel, en als je ze dan ook nog eens vaak moet veranderen (wat echt een slechte regel is), dan gaat dat mis. Mensen willen daar geen significant deel van hun energie aan besteden, en terecht.

En het zou niet nodig moeten zijn. We hebben al tientallen jaren asymmetrische crypto waarmee het mogelijk is te bewijzen wie je bent zonder een wachtwoord te versturen. Dat kan prima gebruikt worden om met honderden systemen te authenticeren en toch maar één wachtwoord op je private key.

Hoe moeilijk is het om een moeilijk wachtwoord te creëren.
Letters vervangen door cijfers en leestekens en je wachtwoord is ineens 10x sterker.

Wat heb je aan 10x sterker? Als je wachtwoord "tweaker" is, en dat is met een dictionary attack te vinden in 0.001s, wat heb je er dan aan om daar 0.01s van te maken?

[drdelta]

Wat heb je aan 10x sterker? Als je wachtwoord "tweaker" is, en dat is met een dictionary attack te vinden in 0.001s, wat heb je er dan aan om daar 0.01s van te maken?

Niet zo veel, maar van 100 uur naar 1000 uur lijkt me een mooie stap.

[PdeBie]

Lees jij dan deze comic maar eens:
http://xkcd.com/936/

Een minder lang wachtwoord met vreemde tekens erin is minder veilig dan een langer wachtwoord zonder vreemde tekens. Die vreemde tekens en cijfers dragen dus helemaal niets bij aan het moeilijker te raden/kraken van een wachtwoord, alleen maar aan het onthouden ervan.

[jarrin]

Die XKCD strip klopt al lang niet meer helemaal. Ook vier random woorden zijn zo te raden met een dictionary attack.

Waar XKCD het over heeft is een brute force aanval. Ja dan klopt het inderdaad dat een langer wachtwoord langer duurt om te kraken. Echter zal er vaker dus een dictionary attack gebeuren.

Beste oplossing is vreemde tekens, letters, cijfers en hoofdletters door elkaar zonder enige logica; maar of dat dan zo makkelijk te onderhouden is...

[pe1dnn]

Die XKCD strip klopt al lang niet meer helemaal. Ook vier random woorden zijn zo te raden met een dictionary attack.

Hoe kom je daar nu bij? Heb je enig idee hoeveel woorden je moet testen?

Als je een kleine bibliotheek hebt met 10000 woorden zit je al op 10000 x 10000 x 10000 x 10000 = 10.000.000.000.000.000
combinaties. Met 8 random tekens zit je op 96^8 = 7,25x10^15; maar die 4 woorden zijn onvoorstelbaar veel gemakkelijker te onthouden.

10000 is het aantal woorden dat een gemiddelde Nederlander normaal gebruikt (volgens een reactie op goeievraag).

[deadinspace]

Die XKCD strip klopt al lang niet meer helemaal. Ook vier random woorden zijn zo te raden met een dictionary attack.

Waar XKCD het over heeft is een brute force aanval. Ja dan klopt het inderdaad dat een langer wachtwoord langer duurt om te kraken. Echter zal er vaker dus een dictionary attack gebeuren.

Dat klopt niet. Waar die xkcd het over heeft is juist een dictionary attack. Het hele punt van dat stripje is juist dat correct horse battery staple onder een dictionary attack significant sterker is dan Tr0ub4dor&3 onder een dictionary attack.

Zie ook mijn post hierboven over de wiskunde achter dergelijke wachtwoorden.

[outis]

Het punt dat XKCD maakt is dat het sterker is om een 4-letter woord te maken uit een alfabet met 32.000 karakters waarin geen correlatie te ontdekken is tussen de 4 letters, dan een 10-letter woord uit een alfabet van 50 karakters waar patronen in te ontdekken zijn.

Volgens mij houdt dat argument nog steeds stand: als je echt vier willekeurige woorden kiest, dan kun je daar geen dictionary attack op schrijven (dictionary gaat ervan uit dat sommige woordcombinaties / volgordes vaker voorkomen dan andere). Maar voor een mens is het wel redelijk makkelijk om voor zo'n woordcombinatie een ezelsbruggetje te bedenken.

[drdelta]

arstechnica.com - Anatomy of a hack: How crackers ransack passwords like “qeadzcwrsfxv1331”:

Early in the process, Steube couldn't help remarking when he noticed one of the plains he had recovered was "momof3g8kids."

"This was some logic that the user had," Steube observed. "But we didn't know about the logic. By doing hybrid attacks, I'm getting new ideas about how people build new [password] patterns. This is why I'm always watching outputs."

The specific type of hybrid attack that cracked that password is known as a combinator attack. It combines each word in a dictionary with every other word in the dictionary. Because these attacks are capable of generating a huge number of guesses—the square of the number of words in the dict—crackers often work with smaller word lists or simply terminate a run in progress once things start slowing down. Other times, they combine words from one big dictionary with words from a smaller one. Steube was able to crack "momof3g8kids" because he had "momof3g" in his 111 million dict and "8kids" in a smaller dict.

"The combinator attack got it! It's cool," he said. Then referring to the oft-cited xkcd comic, he added: "This is an answer to the batteryhorsestaple thing."

[Reactie gewijzigd door drdelta op 22 juli 2024 22:17]

[switchboy]

Als je @ random wel of geen spaties gebruikt wordt het al weer sterker

Wachtwo0rdsterk raam deur plantvensterb4nk woonhuysoud

Daarbij zullen al die dict woorden gecombineerd moeten worden het is niet alsof je bij iedere juist woord een teken krijgt. Een wachtwoord bestaande uit 8 willekeurige woorden is per definitie als sterker dan 8 willekeurige tekens. Gewoon omdat er veer meer mogelijkheiden per ding zijn. ~72 normale letters en tekens. 10000+ mogelijkheden per woord.

[Reactie gewijzigd door switchboy op 22 juli 2024 22:17]

[PdeBie]

Het is dan ook een comic van een aantal maand/jaar (?) oud

Maar Sp4c3r gaf aan dat door alleen het vervangen van letters door cijfers al je wachtwoord significant sterker maakt en dat is ook niet zo.

[robvanwijk]

Eén probleem:

De huidige eisen zijn er echter al weer een paar jaar: vereist is een wachtwoord van minimaal 8 en maximaal 32 tekens, die bestaat minimaal 1 kleine letter, minimaal 1 hoofdletter, minimaal 1 cijfer en minimaal 1 bijzonder leesteken.

Correct horse .. past daar nog net in (kort door de bocht: vier woorden van acht letters per stuk), maar als je net iets langere woorden gebruikt dan gaat het mis.

Kan iemand me trouwens uitleggen waar die eis vandaan komt? Zodra je het hasht (het eerste wat je doet zou ik hopen) komt er hoe dan ook waarde met een vaste lengte uit, dus waarom deze vreemde eis??

[PdeBie]

Dat is ook een debiele eis, die maximale lengte van 32. Dat er een maximum aan zit snap ik. Dat is om te voorkomen dat je het systeem plat trekt door heel vaak veel te lange wachtwoorden af te vuren op de site. Maar maak het dan 1024 ofzo in plaats van 32.

[Verwijderd]

Alsof die paar extra bytes een enorm verschil maken? Dit stamt volgens mij nog uit de tijd dat wachtwoorden als plaintext werden opgeslagen in een varchar(32).

[justincase]

Waarom ze hier voor een maximum van 32 characters kiezen durf ik niet te zeggen. bcrypt heeft echter wel een maximum password length.

[Verwijderd]

Letters vervangen door cijfers en leestekens en je wachtwoord is ineens 10x sterker.

Dat is dus één van de grootste fabels in de IT wat betreft wachtwoorden.
Alle dictionairy's die gebruikt worden houden allang rekening met het vervangen van letters door cijfers, en alsnog kraken ze je wachtwoord even snel.
https://xkcd.com/936/

[yeep]

Slecht voorbeeld met die XKCD comic. Dat soort wachtwoord (4 random woorden) zijn al lang niet meer veilig. Het enige wat nog veilig is, is een string van 20+ random karakters. Als er een logica in zit, is het te kraken. Lees op Ars Technica maar eens de artikelen over password kraken. Je wordt er bang van.

[deadinspace]

Slecht voorbeeld met die XKCD comic. Dat soort wachtwoord (4 random woorden) zijn al lang niet meer veilig.

Het punt van die comic is niet of een wachtwoord van 4 random woorden veilig is of niet, maar dat het veiliger EN eenvoudiger is dan het andere voorbeeld.

Of 4 random woorden veilig is hangt van het attack model af. Die xkcd geeft het attack model (online attack @ 1000guesses/sec) EN de worst-case brute force time. En gegeven het attack model is dat 4-woord password acceptabel voor veel doeleinden. En beter dan de meeste wachtwoorden.

Het enige wat nog veilig is, is een string van 20+ random karakters. Als er een logica in zit, is het te kraken. Lees op Ars Technica maar eens de artikelen over password kraken. Je wordt er bang van.

Dan mis je echt serieus het punt van die xkcd.

Random woorden zijn hetzelfde als random letters. Het alfabet is anders, en het aantal "tekens" dat je gebruikt is anders, maar voor de rest is het exact dezelfde aanpak. Beide geven exact Z^N mogelijkheden, waar Z de grootte van je alfabet is, en N het aantal tekens in je wachtwoord. Het punt van die xkcd is dat de random woorden relatief makkelijk zijn te onthouden.

Stel, je neemt hoofdletters, kleine letters, cijfers en alle leestekens van een standaard US qwerty toetsenbord als je alfabet. Z = 26 + 26 + 10 + 32 = 94. N = 20 zoals in jouw post. Dat geeft 94²⁰ ≈ 2,901 * 10³⁹ mogelijkheden, ongeveer 131 bits aan entropie.

Een diceware passphrase gebruikt woorden uit een woordenlijst van 6⁵ = 7776 woorden. Dus Z=7776. Met 10 woorden krijg je dan 7776¹⁰ ≈ 8,082 * 10³⁸ mogelijkheden, ongeveer 129 bits aan entropie. Bijna hetzelfde dus.

Een voorbeeld uit de eerste categorie is

~FWe5#y`%U@[1NUlXM~f

En een voorbeeld uit de tweede categorie is

plunk gouda fro filler doze dc attic furry karma quilt

En die twee wachtwoorden zijn dus ongeveer even sterk.

[Reactie gewijzigd door deadinspace op 22 juli 2024 22:17]

[Jefrey Lijffijt]

De ironie van deze actie is natuurlijk dat het de entropie juist een beetje lager maakt, net als iedere eis die je stelt aan de wachtwoorden.

[kwikstaart]

20+ random karakters (alles wat je op een normaal US Int toetsenbord ziet en geen vreemde chinese tekens neem ik aan), of 25 gewone lowercase a-z tekens is vrijwel identiek. Anders zet je er standaard $1 voor of A.9 achter - et voila!

[LessRam]

Ben ik het als IT nazi toch niet mee eens. Het feit dat het menselijk brein meer kan onthouden dan ons lief is, maar het onthouden van je eigen wachtwoord toch zo moeilijk maakt is het feit dat men hier niet het nut van wil begrijpen.
Hoe moeilijk is het om een moeilijk wachtwoord te creëren.

Dat is niet zo moeilijk. Maar als je elke 2 maand 8 wachtwoorden op je werk moet wijzigen, dan verdwijnt de motivatie als sneeuw onder de zon als je steeds zo'n moeilijk wachtwoord moet bedenken. Zeker als LastPass e.d. niet mogelijk zijn.
Gevolg... simpele wachtwoorden, opvolgbare nummers en opschrijven in agenda/smartphone.
Verstandig? Nee.
Praktisch? Ja

[Bas de Bakker]

"Je eigen wachtwoord"? Alsof het er eentje is. Ik heb zoveel belangrijke wachtwoorden: DigiD, email accounts, domain provider, bankrekeningen, credit cards, PayPal, Facebook, Amazon, etc. Sommige gebruik ik zelden. Uit veiligheid moeten ze allemaal verschillend zijn. Al die wachtwoorden onthouden kan vrijwel niemand.

[pe1dnn]

Ik ben benieuwd hoe lang het ECHT duurt als je wachtwoord Welkom12345 is. Heb je dat ooit getest?

Je moet het dan hebben van mensen die in de buurt van jouw WiFi zitten en de moeite kunnen en willen nemen om die uitgebreid te gaan kraken.

Zelf heb ik wel een m'n eigen WEP wachtwoord gekraakt wat als totaal niet veilig te boek staat. Maar zelfs dan moet je al een ISO ophalen en branden, een aantal commandline tooljes opstarten enz. Daarmee heb je al 90% van de Nederlandes uitgesloten, tenminste ik krijg het mijn familie niet uitgelegd.

Ik heb ook jaren lang WEP gebruikt (vanwege oude Agere WiFi kaarten) en echt helemaal nooit vreemd verkeer gezien (ja, wel in de gaten gehouden door bijvoorbeeld te kijken of er onbekende MAC adressen waren). Terwijl de kraakbaarheid erg laag is.

Maar zelfs als zouden ze het wel snappen, dan is de volgende stap met een laptop in de auto stappen en woonwijken door rijden, om vervolgens ergens geparkeerd lekker te gaan internetten. Sorry hoor, maar dat zie ik al helemaal niemand doen. Hooguit figuren die dingen willen die het daglicht niet kunnen verdragen, maar dan heb je het over nog meer mensen. En dit is WEP waarbij je er zo ongeveer om vraagt.

Als jij Welkom12345 gebruik met WPA2 dan moet je dus al iemand hebben die uitgebreid de tijd wil nemen om jouw WPA2 wachtwoord te kraken of te raden (hij/zij weet immers van te voren niet dat het een dergelijk wachtwoord is!).

Maar ik zou zeggen doe het voor de grap eens en wacht eens hoe lang het echt duurt voordat je ook maar 1 ander iemand op je netwerk ziet. Ik denk dat je heeeeeeel lang kan wachten tenzij er iemand is die echt heel erg graag precies jouw netwerk moet en zal willen kraken. Voor een doorsnee particulier lijkt me die kans ontzettend klein. Volgens mij kun je beter de WiFi van een Mac Donalds, benzine station of trein gebruiken als je even wat wil.

[SunnieNL]

Letters vervangen door cijfers/leestekens maakt het wachtwoord niet 10x sterker. Want wat gebruik je voor de a? het @. Wat gebruik je voor de E? de 3....
zie je waar ik op doel? Die zijn gewoon allemaal bekend en worden bij bruteforce automatisch gebruikt en maken het wachtwoord net zo zwak.

Wachtwoorden als @pe$t@@rt is zwakker dan DitIsEenGeheimWachtwoord.
Die laatste is echter weel 10x makkelijker te onthouden.

[Verwijderd]

Ben wel gecharmeerd van BitID:
https://github.com/bitid/bitid

Zowieso belachelijk om wachtwoorden ergens centraal op te slaan (terwijl het technisch niet hoeft)

[pjottum]

Helaas_Pindakaas01. neem ik dan aan?

[ongewoongewoon]

En na 2 maanden $pindakaas++;

[LessRam]

Ben je gek, veel te moeilijk. Op mijn werk wordt dat dan gewoon Helaas_Pindakaas02 en weer 2 maand later Helaas_Pindakaas03

[RGAT]

Dat is wat $pindakaas++; doet
Moet voor school blackboard, email en netwerkwachtwoorden elke drie maanden wijzigen, waardoor die nu dus ook een lachertje zijn wat betreft sterkte van het wachtwoord...

[Rob Krauts]

Dat was precies mijn eerste gedachte toen ik dit las.

Moet je dit eens lezen: plan: Analyse: zwakke wachtwoorden op Tweakers.net
...
Waar het op neer komt is dat je zelf een aanval op je eigen data kunt uitvoeren om zwakke wachtwoorden te herkennen.

Is dit niet een schending van privacy? Ook al is het hun database, er staan wel onze persoonlijke gegevens in.

[Bartske]

Als je het artikel gelezen had:

Nota bene: Dit onderzoek is uitsluitend door medewerkers van Tweakers.net verricht. De benodigde gegevens zijn vernietigd en niet aan derden ter beschikking gesteld. Alleen een niet tot wachtwoorden herleidbaar overzicht van gebruikersnummers is bewaard om gebruikers met een zwak wachtwoord te kunnen waarschuwen.

[Puc van S.]

Zolang je de aanval op een geanonimisseerde lijst van wachtwoorden uitvoert is er uberhaubt geen spraken van schending van privacy.

[M.l.]

De gegevens zijn door wat software gemaald met als uitkomst "gekraakt" of "niet gekraakt", Die gegevens zijn alleen gedeeld met de gebruikers zelf. Het is wel prive, maar het is niet gedeeld.

[M.l.]

Goede vraag, dacht ik ook gelijk aan. Ik denk dat ze bij het veranderen van het wachtwoord alleen kijken naar hoe sterk het wachtwoord is, en dat ze dat opslaan. In dat geval sla je dus wel infarmatie op over het wachtwoord wat het eigenlijk nog zwakker maakt.
Het zou ook kunnen dat ze bang zijn voor een hash-collision en daarom wachtwoorden in plaintext opslaan, ik hoop maar van niet.

[robvanwijk]

Het zou ook kunnen dat ze bang zijn voor een hash-collision en daarom wachtwoorden in plaintext opslaan, ik hoop maar van niet.

Als je bang bent voor hash collisions dan zijn er twee mogellijkheden:

• De hashes die je gebruikt zijn véél te kort
• Je hebt totaal geen besef van kansrekening

Willekeurig voorbeeld: SHA-1:

• Lengte: 120 bits
• Kans op collision: 1 / 2¹²⁰ per poging (stomme pech)
• Aantal pogingen om een collision te genereren (opzettelijk hacken): 2⁶¹ (bron; wordt door Wikipedia aangemerkt als beste aanval tot nog toe), maar dan moet je weten naar welke hash je zoekt... als je de gehashte passwords van DigiD kunt stelen, is het cracken van passwords dan nog wel nodig...?
• Als je je zorgen gaat maken over hash collisions, ga je dan ook zorgen maken dat iemand een typefout maakt in zowel zijn username, als in zijn password en dat zó doet dat ie als iemand anders inlogt... Ik heb het niet uitgerekend, maar het zou me niet verbazen als die kans groter is dan de kans op een hash collision.

[M.l.]

Ik weet ook niet of de overheid kans van 1 op 2^256 (sha256) nog te groot vind, ik niet in ieder geval, maar we zullen het waarschijnlijk nooit weten.

Als je bij de gehashte passwords kan is het misschien alsnog nodig om te brute-forcen. Misschien dat je alsnog normaal in moet kunnen loggen om iets te misbruiken, maar de hash aanpassen kan misschien ook nog.

[Armin]

Plus dat een collision nog geen echt problem is.

Betekent enkel dat er meer wachtwoorden zijn per gebruikersnaam.

En kansberekening leert dat dan naast jouw eigen wachtwoord123 er waarschijnlijk enkel nog iets is als kdj':dg37fks*#!ehasl873 is dat ook toegang geeft.

[Lord Ganesha]

Het wachtwoord wordt geevalueerd op het moment dat het gehashed wordt voor verificatie met de opgeslagen hash.
Als de verificatie succesvol is EN de input niet aan de eisen voldoet, wordt het account gemarkeerd als "zwak wachtwoord".

[mie9iel]

De huidige eisen zijn er echter al weer een paar jaar: vereist is een wachtwoord van minimaal 8 en maximaal 32 tekens,

Waarschijnlijk worden de wachtwoorden niet gehashed. Ik ben geen security expert, maar als je wachtwoord een maximum lengte heeft, dan is dat een teken dat er niet gehashed wordt of dat er iets anders fout wordt gedaan.

[Reactie gewijzigd door mie9iel op 22 juli 2024 22:17]

[CyBeRSPiN]

Geen limiet op de wachtwoordlengte zetten kan juist een 'security' risk zijn. De server wordt behoorlijk zwaar belast om een meervoudige hash van een wachtwoord van bijvoorbeeld 4000 tekens te berekenen. Dan heb je met een paar bots die een inlogform submitten met enorm lange passwords al voldoende om de server te laten roken..

[Rafe]

32 of 4000 tekens maakt niet zoveel uit, een megabyte (1048576 tekens) daarentegen wordt wel zwaar. Zie bijv deze security advisory voor Django: Issue: denial-of-service via large passwords.

[Reactie gewijzigd door Rafe op 22 juli 2024 22:17]

[Leroy]

Ik kan me voorstellen dat dit tijdens een drukke periode wel degelijk uitmaakt. Misschien in mindere mate voor het berekenen van de hash, maar die 4000 tekens zullen zeker 4K memory opsnoepen. Je loopt dan dus veel eerder tegen de de limitaties van je omgeving aan (in dit geval geheugenlimiet).

[FreezeXJ]

Dan nog zul je minimaal miljoenen wachtwoorden tegelijk moeten genereren, en zelfs dan... Als je een beetje socket opent voor je login ben je die 4k ook wel kwijt, het gaat eerder om hele megabytes aan wachtwoord tegelijk. De cap op 512 tekens zetten was inderdaad beter geweest, maar helaas.

[Armin]

Plus dat bij hash algorithms het nog wel meevalt, maar gebruik je iets als scrypt voor wachtwoorden 'hashen' (het is immers technisch geen hash) dat expliciet gemaakt is om groeiende geheugen gebruik te geven, ben je mooi de klos met een 1MB wachtwoord ...

[robvanwijk]

Da's een (D)DoS, géén security probleem! Bovendien, hoeveel bytes kost een inlogform submitten nou helemaal: lengte password + honderd tekens aan overhead (http request, username, misschien nog een nonce)? Als je die botjes tweehonderd keer zoveel requests laat doen met een wachtwoord van 4000 / 200 = 20 tekens, dan hebben ze nauwelijks extra bandbreedte nodig (wel meer TCP handshakes, maar goed, dat zorgt aan de kant van de server ook voor extra load, dus voor een DoS is dat juist prima) dan moet de hash functie 200 keer zo vaak initialiseren en (in totaal) uiteindelijk dezelfde hoeveelheid stappen verwerken.

Dat er uiteindelijk ergens een limiet moet liggen, okee, maar dan zou ik graag zien dat die hoog genoeg is om in elk geval het gebruik van passphrases mogelijk te maken; 32 tekens is gewoon te laag, daar gaan (enkele) legitieme gebruikers tegenaan lopen.

[CyBeRSPiN]

DDOS-risico wordt toch wel degelijk als een 'security risk' gezien, ook al krijg je er niet automatisch toegang tot het systeem mee.. verwarrend wel.

Het gaat dus niet om de de data.. die bytes boeien inderdaad niet, het gaat erom dat het heel veel meer rekenkracht kost van de server om een (heel) lang wachtwoord te controleren. Als je bij voorbaat hele lange wachtwoorden uitsluit, kun je deze meteen afkappen voordat je je server laat rekenen.
4000 tekens was een voorbeeld, het gaat inderdaad sneller mis als je meer dan 1.000.000 tekens zou toestaan bijvoorbeeld.

32 tekens vind ik overigens wel prima qua lengte. Een wachtwoord alleen is toch niet secure, je moet altijd nog iets anders erbij nemen (two-factor authentication). Hoe dat bij DigiD werkt is me trouwens een raadsel, want kan bij inloggen zelf kiezen om nog een SMS erbij te krijgen.. dat gaat een aanvaller natuurlijk niet doen..

[robvanwijk]

Dat selectie-vakje is inderdaad een tikkeltje krom. Het idee daarachter is dat de dienst waar je bij inlogt aan DigiD kan doorgeven dat het vakje "alleen wachtwoord" gedisabled moet worden (ik heb nooit geprobeerd wat er gebeurt als je het met debugger enabled en alsnog selecteert...), waardoor sms-verificatie voor die inlogpoging verplicht is.
In een andere reactie las ik dat je in je persoonlijke instellingen kunt opgeven dat jij altijd sms-verificatie wilt gebruiken (ook als de dienst waar je bij in wilt loggen dat niet verplicht), zonder dat andere gebruikers daar "last" van hebben.

[Reactie gewijzigd door robvanwijk op 22 juli 2024 22:17]

[Jasper Janssen]

Denial of service (al dan niet distributed) is een security probleem.

[Jaco69]

Bij een gehashed password wordt (werd?) vaak alleen een aantal tekens gebruikt.
Dat was altijd grappig als iemand zijn super lange paswoord had ingetikt dat je er nog even (&*^$&*^*^@(W^<enter> achter tikt en dat dan de verbaasde persoon ziet dat inloggen lukt.

[Rafe]

Ik kan me dit niet voorstellen, slechts een deel van de input hashen verslaat het idee van een hash maken, zoals je zelf al aangeeft. Waar baseer je deze aanname op?

[real-doc]

Klopt!

Dat is de goeie oude Unix crypt(3) functie. Die gebruikt alleen de eerste acht karakters van je wachtwoord:

"The user's password is truncated to eight characters, and those are coerced down to only 7-bits each; this forms the 56-bit DES key"

http://en.wikipedia.org/wiki/Crypt_%28C%29

[Fairy]

Ik heb zelf systemen gezien waarbij het niet eens uitmaakte wat je intikte, zolang de letters die in het wachtwoord zaten in ieder geval maar voorkwamen. Ja echt! En dat was een beveiligingssysteem voor electronische deuren (met van die magnetische tags).

[Metten]

Je kan je natuurlijk afvragen wat de motivatie is voor het instellen van een maximumlengte, maar het is technisch natuurlijk geen enkel probleem om een maximumlengte te controleren vóór het wachtwoord gehashed wordt, dergelijke controles geschieden nou eenmaal ook op de andere wachtwoordcriteria.

[mie9iel]

Controleren of een wachtwoord korter dan 33 tekens is technisch geen probleem. Dat het gedaan wordt terwijl het overbodig is is ernstiger. Als de controle gedaan wordt omdat een wachtwoord echt niet groter dan 32 tekens kan zijn, dan hint dat op een serieus probleem. Nogmaals, ik ben geen security expert, maar een hash van een wachtwoord wordt niet groter als het wachtwoord groter wordt ... toch? Waarom zou een hash van een 32 teken wachtwoord wel kunnen, maar een hash van een 33 teken wachtwoord niet?

[SWINX]

Dat is een klein beetje afhankelijk van de gebruikte hash functie dacht ik.
Bijvoorbeeld RC4 is veel korter als je ook een kort wachtwoord hebt, maar als je sha512 gebruikt dan krijg je gewoon altijd 128 tekens.

[dezejongeman]

de maximum lengte grens is denk ik voornamelijk gesteld ivm performance hoog te houden en de opslag te beperken. als iedere NL'er een digid heeft dan zijn dat 16 miljoen wachtwoorden x 32 tekens x het aantal bits van de achterliggende taal ascii, unicode....

[Frankster]

Dat maakt dan voor ASCII 16.000.000x32=512000000 bytes -> 488 megabyte. Lijkt me dat dit op de totale begroting van het DigiD project (zal toch enkele tientallen miljoenen zijn) niet echt significant voor de opslag

[dezejongeman]

dat is 1 veld voor iedere gebruiker. hier komen de gebruikersnamen nog bij en vermoedelijk nog het sofienr, telefoonnr en vast nog veel meer waar we geen weet van hebben als buitenstaander. maar je hebt gelijk dat ~500MB wel makkelijk te behappen is.

[Armin]

Plus natuurlijk dat grote wachtwoorden op een bepaald moment weinig meerwaarde meer hebben. Je moet altijd naar de zwakste schakel kijken.

Allereerst
- Een 16 karakter écht random wachtwoord is praktisch onkraakbaar wanneer goede meervoudige hash met unieke salt gebruikt wordt.
- Een 128 karakter wachtwoord met MD5 zonder salt is echter best te kraken.

Besef verder dat als de hash X bit is, meer input bits geen meerwaarde heeft. Neem SHA1 met 160 bits. Als dat de basis is voor je password algorithme dan wordt uiteindelijk elk wachtwoord gereduceert tot 160 bits. Dat is 20 tekens. Langer heeft dus geen nut.

Tenzij je uiteraard een niet-random wachtwoord gebruikt. In dat geval kun je beter daar aan werken ipv de lengte. Als het echt belangrijk is én zelfs uit het blote hoofd moet, gewoon even door bijten, en na enig eoefenen kun je zelfs een random 20 teken string onthouden.

[Joerdgs]

Neem aan dat ze pas checken bij de volgende keer dat je probeert in te loggen.

[S0epkip]

Dat zien ze alleen bij inloggen, zojuist geprobeerd en ik werd meteen gevraagd om mijn zwakke wachtwoord te updaten (geen leesteken). Overigens kon ik het veranderen van het wachtwoord gewoon overslaan. Dus je moet nog geen nieuw wachtwoord opgeven, maar het wordt wel gevraagd.

[Verwijderd]

Dan kunnen ze toch achterhalen wat het uiteindelijke wachtwoord is? Aangezien ze zelf de hashes genereren ( d.m.v. een rekensom ).

[Monochrome]

Verder *zijn* er organisaties die een wachtwoord versleutelen met asymmetrische encryptie en een public key. Een dergelijke implementatie gedraagt zich zonder de private key bij benadering als een cryptografische hashfunctie. Alleen is ergens nog een private key, in een kluis ofzo (dus offline, ergens waar hackers geen toegang toe kunnen krijgen), die gebruikt kan worden om de versleutelde wachtwoorden alsnog in te zien.

Ik zeg niet dat dit goed is.. ik zeg alleen dat ik weet dat het gebeurt. En ik hoop van harte dat onze overheid dit niet doet. Mijn geld zou ik zetten op het checken van het plaintext wachtwoord tijdens het inloggen, zowel technisch simpel als veilig namelijk.

[cdwave]

Ach, de leus is toch: "Overheid en IT, dat kun je niet maken."

Het zou me niet verbazen als digid een omkeerbare encryptie op de wachtwoorden gebruikt.

[Armin]

Ik neem aan dat ze een standaard bibliotheek als bcrypt (onomkeerbare encryptie) of PBKDF2 (meervoudige hash) gebruiken.

[Armin]

Hoe kan men van bestaande wachtwoorden zien of deze aan de "zwakke criteria" voldoen? Deze zouden toch gehasht moeten zijn?

De kop dekt dan ook niet de lading.

De wachtwoorden krijgen helemaal geen reset. Echter bij het inloggen wordt nu een aanvullende check gedaan of het wachtwoord veilig genoeg is. Zo niet, wordt dan een reset gedaan.

Tenminste, anders zou de DigiD database wel erg makkelijk terug te rekenen zijn. Ik neem aan dat deze immers gehasht is met een unieke salt en multiple rounds. In dat geval kan ook DigiD zelf niet - zonder heel erg groite moeite - zien dat een wachtwoord onveilig is.

[Sissors]

Wachtwoorden online bruteforcen/dictionary attacken is zo goed als onmogelijk. Zelfs als mijn wachtwoord "Dolfijn" is, hoeveel pogingen hebben ze moeten wagen om daarop te komen? Ik mag toch hopen dat na de eerste honderd inlogpogingen er minstens een time-out op de volgende poging gezet wordt?

Dus het is sowieso al enkel een probleem als ze hun database laten lekken. Maar zelfs dan nog. Ik heb nu een wachtwoord van ruim meer dan 12 tekens (jullie hoeven niet de exacte lengte te kennen ). Deze heeft geen hoofdletters en leestekens, wel cijfers en kleine letters, en de cijfers zijn geen standaard vervangingen (Oftewel niet d0lf1jn). Een dictionary attack gaat niks tegen het wachtwoord doen, en voor bruteforce is het ook veel te lang. En toch heb ik blijkbaar een onveilig wachtwoord. En als ik nu D0lf1jn! als wachtwoord heb is het heel veilig. Want gezien je bij een dictionary attack al weet wat de eisen zijn aan het wachtwoord kunnen ze hem uiteraard niet zo instellen om eerste letter een hoofdletter te maken, laatste een uitroepteken/vraagteken, en wat standaard letter-cijfer vervangingen te doen [/sarcasm]. En dat zal het nieuwe wachtwoord zijn voor het merendeel van de mensen die nu een daadwerkelijk zwak wachtwoord hebben.

En ik? Ik had een sterk, uniek wachtwoord dat ik wel kon onthouden. Nu moet ik een nieuwe bedenken. En waarschijnlijk het wachtwoord ergens opschrijven om hem te onthouden. Of toch bovenstaande doen. Wat de optie ook is, mijn veiligheid gaat erop achteruit vanwege volstrekt arbitraire en achterhaalde eisen die leuk klinken maar voornamelijk de gebruiker irriteren.

[alexnauta]

Mijn haren gaan toch recht overeind staan als ik dit zo lees? Dit betekend dus dat ze:
* Of de wachtwoorden niet encrypted of met een vaste encryptionkey opslaan
* Of de wachtwoorden gehashed zijn zonder salt, waardoor ze simpele wachtwoorden via een rainbow table terugzoeken
* Of de eigenschappen van het wachtwoord (lengte/aantal cijfers en letters) opslaan (wat het hackers ook makkelijker kan maken bij het unencrypten)

[renevanh]

Of (en dat zal het geval wel zijn) wordt het wachtwoord onversleuteld verzonden naar de server (over een https verbinding, maar dus wel als plaintext string) en daar gecontrolleerd/gehashed/encrypted/enz.

Jij typete je wachtwoord, de servers checken of jouw invoer voldoet aan de gesteld regels.
Voldoet jouw invoer niet maar is je login wel succesvol, dan krijg je 'wijzig uw wachtwoord' voor je neus.

[.oisyn]

wordt het wachtwoord onversleuteld verzonden naar de server (over een https verbinding, maar dus wel als plaintext string

Zelfs dat hoeft helemaal niet. Ze zouden ook clientside kunnen checken of je wachtwoord aan de nieuwe regels voldoet en dat mee kunnen sturen. Niet dat het veel nut heeft om het wachtwoord clientside te beveiligen - als iemand verkeer kan afluisteren kan hij het waarschijnlijk ook manipuleren, en dus ook clientside code injecteren om het door jou ingetypte wachtwoord door te sturen.

[Reactie gewijzigd door .oisyn op 22 juli 2024 22:17]

[efari]

Of, die controle wordt lokaal gedaan (mbv Javascript ofzo) en indien slecht wachtwoord wordt er een extra parameter doorgestuurd met de inlogrequest..

[WhatsappHack]

Inderdaad! Het eerste wat ik ook las, blij dat in de zee van "omg moet mn wachtwoord wijzigen" iemand dit nog opmerkt.

Het is echt een *zeer* kwalijke en extreem gevaarlijke zaak dat de roverheid blijkbaar de wachtwoorden niet encrypted opslaat. Dat is een IT faal van de grootste orde voor een systeem als DigID.
Nu zou ik nog liever mn wachtwoord wijzigen om te zorgen dat ik veiliger ben gezien de overheid totaal niet te vertrouwen is, en er ook een grote kans is dat ze je wachtwoord proberen te misbruiken (daarom: gebruik overal andere wachtwoorden!), maarja... Die gasten slaan ook je laatste 5 wachtwoorden op!

Lekker verhaal dit... Zo zie je maar dat je er nooit vanuit moet gaan dat de overheid iets goed doet met IT.

[Verwijderd]

Ik denk toch echt dat het antwoord heel simpel is. Het wachtwoord is bekend op het moment van inloggen omdat je het zelf hebt ingetypt. Na de hash/salt/quantumencrytiecontrole laten ze een simpele validatie controle op je ingevoerde stringetje los en klaar is klara.

De database weet je wachtwoord niet, dat weet alleen de webserver voor de duur van de veiligheidscontrole.

De eenvoudige antwoorden zijn best vaak waar denk ik.

[skiwi2]

Incorrect. Ze weten zelf alle salts die bij de wachtwoorden horen, aangezien die netjes bij de gebruikersnaam in de tabel staan.

Ik weet niet wat de eisen van de oude wachtwoorden precies waren, maar je kunt alle simpele wachtwoorden (a-z + 0-9) tot en met een lengte van 8 tekens zeker wel gaan bruteforcen.
Zeker als je de overheid bent, en anders kunnen ze vast nog wel van iemand eventjes wat rekencapaciteit lenen.

[DLGandalf]

Dat een salt bekend is maakt niet uit, het gaat erom dat dmv salts je een attacker de mogelijkheid ontneemt om rainbow tables te gebruiken. In dit geval is de attacker de bank zelf - het punt dat @alexnauta maakt is dus wel valide.

[Tweaker_19]

Waarom moet er een maximum lengte op het wachtwoord zitten? Als je het fatsoenlijk opslaat is dat toch helemaal niet nodig?

EN daarbij natuurlijk nog altijd leuk: http://xkcd.com/936/

[YopY]

Precies dit; door ipv een hoofdletter (oid) toe te voegen hadden ze beter de minimumlengte naar 10 of 12 kunnen ophogen.

Letters + cijfers maal 8 karakters = 36 ^ 8 = 2.821109907456 × 10^12
Met Hoofdletters + zooi, laten we zeggen 70 totale karakters = 70 ^ 8 = 5.764801 × 10^14
Letters + cijfers maal 12 karakters = 36 ^ 12 = 4.738381338321616896 × 10^18

tl;dr, meer karakters = moeilijker te bruteforcen.

[RadioKies]

Verbaas mij altijd nog dat deze xkcd toepasselijk is... moeilijkere wachtwoorden voor wie? Niet voor de pc, maar wel voor de gebruiker.
http://xkcd.com/936/

[jaapzb]

Ik wil gewoon een wachtwoord kunnen hebben zoals die in die XKCD, maar heel weinig websites geven die mogelijkheid omdat er een hoofdletter, een cijfer, een gangsign en het bloed van een maagd in moeten staan... Dat is inderdaad vast een stuk veiliger dan twee/drie random worden gescheiden met een spatie.

Nog leuker zijn die sites waar je wachtwoord een *maximale lengte* hebben. Dan weet je zeker dat je wachtwoord niet gehasht word...

[MadEgg]

Ik weet zeker dat ik veel meer fouten zou maken met een correct horse battery staple wachtwoord dan met mijn huidige wachtwoord wat uit willekeurige cijfers, letters en tekens bestaat.

Het klinkt in eerste instantie heel makkelijk maar doordat de woorden niet gerelateerd (zouden moeten) zijn, is het lastig om de volgorde te onthouden. Wat mij betreft net zo lastig zo niet lastiger dan de volgorde van random characters onthouden. Bovendien, die lange wachtwoorden intypen is ook strontirritant, liever gewoon een karakter of 10. Zeker op een mobiel apparaat.

De enige echte oplossing voor de wachtwoordproblematiek is één extreem lastig wachtwoord gebruiken om je password-kluis in KeePass of andere dergelijke software te versleutelen en vervolgens gewoon 24-karakter-random-garbage als wachtwoorden gebruiken voor alle overige sites die je dan simpel kunt copy-pasten of mbv een plugin automatisch invullen. En dan voor elke login een ander wachtwoord natuurlijk.

[X-Rey]

Net op een mobiel apparaat is een wachtwoord zoals XKCD voorstelt veel fijner. Probeer op een iPad of Android toetsenboard maar eens lekker cijfers in te typen, laat staan vreemde tekens zoals %,^ en # die achter 2 knoppen verborgen zijn.

[jaapzb]

Ik gebruik zelf zo'n soort wachtwoord in de praktijk op alle mogelijke plekken waar dat maar kan. En ik vind het een stuk makkelijker te typen + een stuk makkelijker te onthouden. Ik had eerst ook wachtwoorden die er z0 u1T Z4g3n en alhoewel dat op een bepaald moment ook wel gaat werken, was mijn muscle memory sneller geupdate toen ik zo'n XKCD wachtwoord nam dan toen ik een ander nummers-en-leestekens wachtwoord nam.

Heb je het wel eens geprobeerd? Bijvoorbeeld als wachtwoord op je eigen computer?

[MadEgg]

Jazeker heb ik het geprobeerd, en ik blijf steeds twijfelen welke volgorde ik nou had en of ik, naar het voorbeeld, nou trombone of troubador had gebruikt. Het effect is hetzelfde, maar de XKCD doet het rooskleuriger voor dan het is.

Een wachtwoord van 10 willekeurige hoofdletters, kleine letters en cijfers heb ik aanmerkelijk sneller onder de knie en heel wat sneller ingevoerd. Na een dag of 2 is het een soort automatisch motorprogramma geworden waar ik zelfs niet meer over na hoef te denken.

[.oisyn]

Nog leuker zijn die sites waar je wachtwoord een *maximale lengte* hebben. Dan weet je zeker dat je wachtwoord niet gehasht word...

Dat niet per se. Je wil eigenlijk altijd wel een maximum hebben om denial of service attacks tegen te gaan. En uiteraard bedoel ik dan niet 32 maar iets als 1024 ofzo.

[Maarten21]

Hoe kunnen ze erachter komen of een opgeslagen wachtwoord geen hoofdletters of leestekens bevat? Tenzij...

[mobstaa]

Aan de hand van de UserInput, als de gebruiker nu opnieuw wil inloggen, zou er op zoiets dergelijks gecontroleerd kunnen worden. Als het wachtwoord vervolgens gehashed wordt vergeleken met de hash in de database en er komt uit dat de hashes hetzelfde zijn, kan het systeem de melding geven dat het wachtwoord moet worden aangepast.

[Zapato]

Hoe wil je anders een wachtwoord ingeven?

[dcm360]

Hoe wil je dan een inlogsysteem zonder userinput maken als ik mag vragen? Mij lijkt dat nogal een uitdaging.

[Standeman]

" maximaal 32 tekens"

Dit snap ik nou nooit. Wat maakt het nou uit of je een string van 32 tekens hashed of, laten we zeggen 4096 tekens. Qua performance ga je echt het verschil niet merken.

[Verwijderd]

De vraag is of het zinvol is om een wachtwoord langer dan 32 tekens te gebruiken als hash bijvoorbeeld maar 32 tekens lang is? Let wel, dit is bedoelt als vraag, geen stelling? Ik kan me voorstellen dat de kans dat er dan een collision optreedt met een korter wachtwoord aanwezig is.

Zit je dagelijks trouw een string van 684 tekens in te tikken, blijkt het een collision te hebben met 'Geheim123'

Gezien de drukte op DigID soms, kan ik me ook voorstellen dat ze het om performance redenen beperkt is.

[Armin]

Ik kan me voorstellen dat de kans dat er dan een collision optreedt met een korter wachtwoord aanwezig is

Niet alleen aanwezig, maar zelfs gegarandeerd!

Vandaar ook dat meer dan hash_bits / 8 ook meestal niet relevant is. Bij SHA1 dus 20 tekens.

Performance maakt minder uit, want - mits goed geimplementeerd - worden er meerdere rounds gedaan. In de eerste round ben je dus alles groter dan in mijn voorbeeld 20 tekens kwijt. Daarna worden er bijvoorbeeld nog 999 hash-rounds gedaan met die 20 tekens igv een 1000-round algorithme. Je ziet dus dat die eerste hash op het totaal niet zo veel uitmaakt.

[Standeman]

Wachtwoorden intikken doe ik allang niet meer. Daarvoor heb ik met password database met generation tooltje voor

Maar als ik een makkelijk te onthouden wachtwoord nodig hebt, heb ik liever "De kerstman wast zijn onderbroek in de tobbe met zeep" dan "$jf9_4i9g43$" of "p4$$w0rd"

[Reactie gewijzigd door Standeman op 22 juli 2024 22:17]

[MadEgg]

Een upper limit is wel handig, maar die zou inderdaad net zo goed 4096 kunnen zijn. Zonder upper limit is het natuurlijk vragen om (D)DOS-aanvallen.

[Armin]

Dit snap ik nou nooit. Wat maakt het nou uit of je een string van 32 tekens hashed of, laten we zeggen 4096 tekens. Qua performance ga je echt het verschil niet merken.

Qua veiligheid ook niet

Immers met bijvoorbeeld een 160bits hash (20 tekens) is langer niet echt zinnig. Hoogstens geeft het wat extra entropie.

[mtak]

Uiteindelijk kost dit dus veel meer opslag dan wanneer er wordt afgedwongen niet meer dan 32 tekens te gebruiken.

Een hash van een wachtwoord van 4096 karakters is net zo lang als een hash van een wachtwoord van 8 karakters.

[Fab1Man]

Frappant. Ik heb nu juist een zwak wachtwoord omdat DigiD destijds sterke wachtwoorden (lees: leestekens) niet accepteerde, maar alleen hoofdletters, kleine letters en cijfers.

[ulTimaS]

^ Dit.
Dit vond ik toen zo raar, dat je voor zoiets belangrijks geen eens demogelijkheid kreeg om een veilig wachtwoord te creëren. Gelukkig zit er nog wel een SMS check bij.

[.oisyn]

Gelukkig zit er nog wel een SMS check bij.

Die niet verplicht is. Voor sommige dingen is 2FA wel vereist, maar voor de meeste onderdelen van de overheid waarvoor je in moet loggen met DigiD volsta je met alleen je wachtwoord.

[ulTimaS]

dat wist ik niet, dan is het helemaal slecht

[Tim_bots]

Inmiddels kun je de SMS check wel forceren. Hierdoor moet je altijd de SMS code overtypen als je wilt inloggen met DigiD.
Bij mij staat deze optie dus geforceerd aan. Mocht ik ooit een DigiD SMS krijgen terwijl ik niet aan het inloggen ben -> Account compromised. Al moet ik dan in mijn geval ook lastpass nakijken.

[djunicron]

Dit dus. Ik heb namelijk juist bij DigiD een wachtwoord dat breekt met mijn eigen interne wachtwoord regels, omdat punt 1 het wachtwoord te lang was (t.d.t. geloof ik max 12 tekens?) en omdat de leestekens er niet in mochten.

[incaz]

Ik vind het idd wel een beetje jammer dat er nu geimpliceerd wordt dat het 'die domme gebruikers' weer zijn - zonder ook maar iets te zeggen over de eigen steken die ze ook hebben laten vallen.

[ManiacsHouse]

Euhm... Pardon? En hoe weet den overheid dan dat iemand een zwak wachtwoord heeft? Blijkbaar zijn die wachtwoorden dus ergens leesbaar opgeslagen... Ook erg fijn dat ik dat nu lees op tweakers maar nergens anders. Niets op het Journaal of nu.nl
* ManiacsHouse gaat eens even inloggen op mijn.overheid.nl en zien wat er geroepen wordt.

En jawel ik heb een 'zwak' wachtwoord. Ooit gekozen omdat mijn 'sterkere' wachtwoord niet werd geaccepteerd.
Ook knap. Zelfs op mijn.overheid.nl staat géén melding dat de wachtwoorden gereset zijn en dat je een nieuwe moet kiezen. Heel knap in de tijd van fishing enzo. Wie zegt dat ik niet omgeleid word naar een andere site en men zo mijn digid weet te kraken?

Echt... Overheid en ICT...

[Reactie gewijzigd door ManiacsHouse op 22 juli 2024 22:17]

[.oisyn]

En hoe weet den overheid dan dat iemand een zwak wachtwoord heeft

Bij het inloggen natuurlijk, duh.
Echt... tweakers en <insert random onderwerp>...

[Reactie gewijzigd door .oisyn op 22 juli 2024 22:17]

[NRG-81]

Zo duh is dat niet. Er staat in de tekst toch duidelijk dat de zwakke wachtwoorden een reset hebben gekregen, niet dat er tijdens het inloggen gecontroleerd wordt of er aan de huidige eisen wordt voldaan.

[.oisyn]

Wat vooral "duh" is is dat je niet blind moet vertrouwen op de woordkeuze van de auteur van dit artikel. Ik lees verder nergens een officieel persbericht dat de wachtwoorden een "reset" hebben gekregen. En zelfs als dat wel zo is dan impliceert dat nog niet dat dat het geval is, want persberichten worden in de regel niet geschreven door technici.

Als ze de wachtwoorden daadwerkelijk hebben gereset dan had ik een email verwacht, en niet dat je het pas moet veranderen de volgende keer dat je inlogt. En dat heeft hoogstwaarschijnlijk een heel duidelijke reden: de wachtwoorden zijn niet in plain text opgeslagen dus ze kunnen niet weten wie er een zwak wachtwoord heeft (anders dan dat te gaan brute forcen zoals tweakers.net een keer met haar database heeft gedaan)

[Snowmiss]

Inderdaad, wilde vanmorgen iets doen op de site van de gemeente. Ingelogd met DigiD (heel oud (en zwak) wachtwoord) en die moest ik inderdaad vernieuwen, terwijl ik er drie weken terug nog mee ingelogd had, zonder vernieuwing

[tomcool]

Misschien alleen reageren als je ook echt dingen zeker weet. Het is toch heel simpel om te weten of je een zwak wachtwoord hebt. Er staat ook dat er gekeken word tijdens het opnieuw inloggen.
Dus je wachtwoorden staan echt wel gehashed opgeslagen. Maar bij je volgende inlog poging wordt gewoon snel gekeken naar de nieuwe eisen. (want ja client side is wel plain text) Voldoet je wachtwoord daar niet aan dan wordt je door gestuurd naar een pagina waar je een nieuw wachtwoord moet kiezen.

Dus er valt niks af te kraken aan deze oplossing

[WhatsappHack]

Ik heb tijdens het intikken van t wachtwoord nog tijdens het submitten kunnen opmerken dat de wachtwoord sterkte wordt bekeken.
imho is het niet toepassen van client-side pre-hashing een doodzonde, en als hun servers dan plain-text wachtwoorden analyseert is dat ook een probleem... Zo kun je er vanuit gaan dat je wachtwoord niet bijster veilig is bij DigID en de mogelijkheid dat het NIET hashed opgeslagen is staat nog altijd volledig open.

[brid]

Net even ingelogd op Digid.nl.
Daar staat netjes de melding dat deze maatregel van kracht is geworden en na het inloggen mocht ik gelijk me wachtwoord wijzigen

[ManiacsHouse]

Ja daar dus pas. Op moment dat je gaat inloggen. Verder nergens aankondiging. En phishing is eigenlijk altijd met inloggen.

[Saven]

Wat een onzin dat er ook per se een cijfer en leesteken inmoeten. Dat maakt het wachtwoord helemaal niet significant veiliger. Een langer wachtwoord, dat is wel veiliger

[MadEgg]

Op zijn minst hoofdletters en kleine letters vereisen is wel een must. De complexiteit van het wachtwoord vergroot je daar dramatisch mee. Cijfers en leestekens toevoegen helpt dan wat minder.

Echter, de kraakbaarheid van een wachtwoord hangt met name af van de samenstelling. Je kunt inderdaad beter 16 random letters (uppercase/lowercase) hebben dan 8 uppercase/lowercase/cijfers/leestekens. Echter, als je niet de eisen van cijfers / leestekens erbij maakt loop je een enorm risico dat mensen gewoon volzinnen gaan gebruiken en die zijn dan weer een stuk makkelijker te kraken omdat je dan niet aan het kraken bent op karakterniveau maar op woord-niveau waardoor je dus met +- 3 woorden bezig bent in plaats van 16 karakters. Maakt nogal een verschil voor de kraakbaarheid.

[Verwijderd]

"Op zijn minst hoofdletters en kleine letters vereisen is wel een must. De complexiteit van het wachtwoord vergroot je daar dramatisch mee."

Toch heeft marginale uitbreiding van de wachtwoordlengte meer effect dan het verdubbelen van de karakters (ie 26^2 >> 52^1)
Ergo, Saven is correct.

[MadEgg]

Err..

Stel, 8 tekens, 26 karakters: -> 208827064576 combinaties
8 tekens 52 karakters -> 53459728531456 combinaties = factor 256 groter

Of:
9 tekens, 26 karakters -> 5429503678976 = factor 26 groter

Dus hoofdletters en kleine letters vereisen vergroot de complexiteit een factor 10 meer dan het verlengen van de minimale lengte naar 9 karakters. Natuurlijk is een combinatie van beide altijd nog beter.

[Sissors]

Met hoofdletters en kleine letters verhoog je niet de complexiteit, simpelweg omdat iedereen die echt een zwakwachtwoord heeft nu of zijn wachtwoord ergens opschrijft, of van de eerste letter een hoofdletter maakt. Leestekens? Uitroepteken aan het einde. Cijfers? De i door een 1 vervangen.

[MadEgg]

Tja, en met verhogen van minimale lengte krijg je precies hetzelfde. In plaats van 1234 gebruiken ze dan wel gewoon 123456789012345678901234567890 of zo.

Het probleem zit niét in de eisen die je stelt aan het wachtwoord maar gewoon tussen de stoel en het toetsenbord. Mensen zijn te beroerd om energie te steken in beveiliging van hun gegevens, en daar verander je weinig aan ben ik bang.

[Tuckson809]

Natuurlijk maakt dat het wachtwoord wel veiliger. Het dwingt attackers de volledige codeset te gebruiken en niet de puur alfabetische subset. Het aantal mogelijke combinaties neemt enorm toe.

[Verwijderd]

Op zich heb je natuurlijk gelijk, maar dat is misschien wel uitgaande van de regels aan een wachtwoord.

Als de regels van de site zijn dat het geen cijfers mag bevatten, dan hoeft een hacker niet te zoeken naar cijfers.

Bij een site zonder die regel, waarbij een wachtwoord mag bestaan uit hoofd/kleine letters, cijfers en leestekens zal een hacker sowieso alles doorlopen.

In dat geval vraag ik me af of je kan stellen dat alleen kleine letters of hoofdletters zwakker is. Dat zal helemaal afhangen van de manier waarop het hacker-script is ingericht denk ik.

[laptopsheerlen]

Ik denk dat de gemiddelde internetter standaard een kort wachtwoord gebruikt. Laten we zeggen een wachtwoord van 8 tekens lang met alleen 'kleine' letters.
Dit wachtwoord heeft 26**8= 208827064576 mogelijkheden. Met een snelheid van 310,5 MH/s kun je dat in iets meer dan 11 minuten kraken bij een MD5 hash.

Als je dan verplicht dat het wachtwoord ook hoofdletters en speciale tekens moet bevatten vergroot dat het aantal mogelijkheden aanzienlijk op zo'n kort wachtwoord.
We krijgen dan op elke plaats van een karakter 84 mogelijkheden in plaats van 26.
Dit wachtwoord heeft dan 84**8= 2478758911082496 mogelijkheden. Met een zelfde snelheid van 310,5 MH/s duurt het nu al ruim 13 weken om het wachtwoord te kraken.

[RGAT]

Duurt het nu al maximaal 13 weken

Het kan ook 1 seconde zijn, aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa1 is geen sterk wachtwoord hoe lang het ook is
Je hoort vaak dat je een zinnetje moet doen, zoals:
'Ik heb een groene fiets' en dan elke eerste letter....
Zodat je wachtwoord 'Ihegf' is, wat erg sterk klinkt als je het als mens probeert te raden, want wie denkt daar nou aan, zeker omdat ik geen groene fiets heb, maar de pc denkt er anders over.

[laptopsheerlen]

Je hebt gelijk, het zou maximaal moeten zijn.