Consumentenbond: sommige websites zijn vatbaar voor bruteforce-aanval wachtwoord

Sommige bekende Nederlandse websites waar gebruikers kunnen inloggen met een account, zijn vatbaar voor aanvallen via brute force. Die sites staan een onbeperkt aantal pogingen toe om in te loggen. De Consumentenbond noemt de naam van slechts een van die sites: die van de bond zelf.

De Consumentenbond voerde de test met de software om wachtwoorden te achterhalen met een bruteforce-aanval op 37 Nederlandse websites. Daarvan bleken er negen vatbaar voor de aanval, meldt de bond. De Consumentenbond zegt maatregelen te hebben genomen tegen deze aanvalsmogelijkheid toen bleek dat de site kwetsbaar was.

Daarnaast scoorde de bond op de eigen test van wachtwoorden 'matig', omdat hij te korte en veelgebruikte wachtwoorden toestaat. Onder meer Spotify en Netflix staan korte wachtwoorden ook toe, claimt de Consumentenbond. Cameranu spande de kroon, omdat die site wachtwoorden bestaande uit één teken toestond. Dat heeft de site inmiddels aangepast. Ook Fonq heeft verbetering aangebracht, omdat op die site een wachtwoord met vier tekens voldoende bleek.

Behalve het toestaan van te korte wachtwoorden zijn er ook sites die lange wachtwoorden juist verbieden. Onder meer bij webwinkels van Otto en MediaMarkt is dat het geval. Daarnaast stellen veel sites specifieke eisen zoals een hoofdletter, cijfer of speciaal teken, waardoor de sites wachtwoorden weigeren die in principe wel in orde zouden zijn.

Reacties (194)

[TimvH]

Het grootste probleem aan die maximumlengte's is nog wel dat de site de hacker zo als het ware instructies geeft binnen welk bereik hij moet bruteforcen om het wachtwoord te kunnen kraken. Hoe meer eisen er worden gesteld, hoe meer de hacker ook over kan slaan tijdens het kraken om zo sneller resultaat te boeken.

Daarbij iedere keer die adviezen over hoe je het best een wachtwoord kan verzinnen, het heeft maar voor een bepaalde tijd zijn ervan uitgaande dat de tips nog niet bekend zijn (en dus ook niet bij de mogelijke hackers).

Ook zijn er nog genoeg websites niet of zwak beveiligd en worden wachtwoorden nog steeds vaak enkel gehasht of met zeer verouderde encryptie opgeslagen. Beveiliging is iets waar je continu of in ieder geval met enige regelmaat naar moet kijken. Er is geen enkele beveiliging die echt volledig toekomstbestendig is.

[Reactie gewijzigd door TimvH op 22 juli 2024 16:28]

[Blokker_1999]

Wilde me overlaatst registreren bij Jottacloud. Genereer een wachtwoord van 100 karakters. Wordt niet aanvaard wegens "te kort". Stuur mailtje naar support: gelieve te proberen met minder dan 63 karakters. Heb maar verder gekeken.

Maximumlengte is inderdaad de grootste bs die er bestaat. Het zorgt niet voor moor veiligheid maar komt meestal doordat iemand lui is geweest bij het programmeren van de backend.

[gorgi_19]

Integendeel, een maximumlengte heeft wel degelijk zin.
Het controleren / hashen van wachtwoorden is een proces dat juist traag moet zijn. MD5 is om die reden een probleem; het is veel te snel. bcrypt is veel trager en er kunnen dus veel minder pogingen gedaan worden (wat het bruteforcen van wachtwoorden een stuk lastiger maakt)

Omdat een bewerking duur is, wil je dus niet te lange wachtwoorden hebben. Je kan daarmee anders een DOS-attack creeeren. Oftewel: te lange wachtwoorden vormen een risico, evenals te korte wachtwoorden.
Een lengte van 63 karakters is ook niet zwak te noemen. Probeer maar eens om de entropy te bepalen van een wachtwoord op bijvoorbeeld http://rumkin.com/tools/password/passchk.php; al vrij snel kom je bij hele hoge waarden uit.

Zie bijvoorbeeld ook https://arstechnica.com/i...-can-be-bad-for-security/

[LankHoar]

Dan wel weer vreemd dat die rumkin website gewoon je wachtwoorden laat intypen over een onversleutelde HTTP verbinding.. Ook jammer dat ik dat pas zag nadat ik mijn wachtwoorden al getest had

[gorgi_19]

Je kan ook de versie gebruiken die beschreven is door een medewerker van dropbox: zxcvbn
Zie hiervoor https://lowe.github.io/tryzxcvbn/

Het mooie is dat deze versie ook rekening houdt met een dictionary (weliswaar engels); eigen namen, herhaling van tekenreeksen en vervangen van karakters (zoals de e door een 3)

[Reactie gewijzigd door gorgi_19 op 22 juli 2024 16:28]

[SunnieNL]

LiesjeLeerdeLotjeLopenLangsDeLangeLindelaan

Vreemde manier waarop ze daar achter komen in die demo. Hij breekt het op in stukken terwijl er geen logica achter die stukken zit.

Ja er zit open in, maar hoe weet een programma op welke plek?

[Yaminike]

Ik heb voor de grap de code van dit project een keer geport naar een andere taal, dus ik weet hoe het ongeveer werkt.
In dit geval zit het woord "open" in één van de "dictionaries" die het algoritme gebruikt, dit is gewoon een lijst van de meest gebruikte Engelse woorden.
Hetzelfde geld voor "Lang" welk hij in de lijst van achternamen voorkomt. (Deze lijst is ook VS specifiek)

[SunnieNL]

ja, maar gaat erom dat hij al die losse stukken nog wel moet weten waar ze staan in het wachtwoord.

[Yaminike]

De code gaat dus ook uit van de best-case scenario (of worst-case, afhankelijk van hoe je het bekijkt).
"open" komt in een dictionary voor, en dus kan dat woord theoretisch eerder gevonden worden.
bruteforce wordt pas gebruikt als er geen andere patterns gevonden kunnen worden. (aangezien bruteforce het traagst is)
Andere patterns naast dictionaries zijn;

• date
• regex
• repeat
• sequence
• spatial

[Jerie]

Hoe weet jij mijn root wachtwoord??????

[mcDavid]

Dat maakt op zich weinig uit toch? Je gaat sowieso niet je échte wachtwoorden bij een 3e partij invoeren, ongeacht hoe die verstuurd worden. Als je dat wel gedaan hebt zou ik je ten zeerste adviseren om ze nu allemaal te wijzigen, want ze staan bijna gegarandeerd in een dictionary nu.

[Jerie]

De code draait lokaal in je web browser (JavaScript) dus wat dat betreft is er niets aan het handje.

De code is wel te MITMen want hij wordt geserveerd over HTTP. Dus wat dat betreft is het wel gevaarlijk. Als je op een hostile netwerk zit (of je bent bang voor de politie) dan wil je dit niet draaien

Maar het is minder erg dan dat je password plaintext over HTTP wordt opgestuurd om even te checken of je wachtwoord veilig is. Dat is wat je impliceerde, en dat is niet waar.

[hackerhater]

True, maar dan een realistische maximunlengte van 512 tekens of zo.

[Stoelpoot]

Dan nog vind ik 63 tekens een redelijk arbitrair aantal. Als je er van uit gaat dat de mensen met dergelijk lange wachtwoorden een generator gebruiken, moet je bepalen hoe groot de generators de wachtwoorden maximaal maken (bij standaardinstellingen). Je zal vaak boven de 63 tekens uitkomen. Ik zou zelf voor 255 tekens kiezen. Dat is voldoende om overkill wachtwoorden aan te maken, maar zal nog steeds voldoende DOS bescherming bieden als je dat combineert met 'echte' DOS bescherming.

[Clemens123]

63 karakters is ruim voldoende, bij Paypal moet je het met 20 tekens doen, wat in mijn ogen ook al voldoende is als je voldoende variaties in de tekens gebruikt kom je op wachtwoorden uit van om en bij de 128 bits (dus 2^128 moeglijkheden er vanuitgaande dat je weet welke tekens gebruikt zijn, wat je als aanvaller niet weet), dat is al heel lastig te bruteforcen...en als de hash juist gekozen is door de site is bruteforcen de enige mogelijkheid...

Waar ik wel gek van wordt zijn website die niet omkunnen met bepaalde tekens en oftwel het wachtwoord wijgeren oftwel doet het wachtwoord het niet omdat de site het niet kan hashen of de hash niet consistent ist en enige mogelijkheid is wachtwoord reset met een wachtwoord zonder bepaalde tekens

[Stoelpoot]

Limieten van 20 tekens laat ik links liggen en ik zoek naar een volgende dienst. Dat is niet meer van deze tijd. Tegenwoordig gebruik ik een password manager, dus elk wachtwoord dat ik zelf nog bedenkt is erg belangrijk en krijgt dus standaard al meer dan 20 tekens.

Verder gebruik ik geen variatie in mijn tekens. Dat doet de password manager wel voor me.

Daarnaast gaat jou berekening van bruteforcen er van uit dat elke site een goed hashing algoritme gebruikt. Daar ga ik juist niet van uit.

Ik voorzie eerlijk gezegd na de bitcoin-miner virussen ook nog wel password-hashing virussen te voorschijn komen. Stel je bijvoorbeeld voor dat de bitcoin miner uit uTorrent destijds vervangen was door een password miner. Dat zal best hard gaan.

[Clemens123]

Met variatie van tekens bedoel ik bv. of je letters met accenten gebruikt, spaties, andere speciale tekens, haakjes, accolades, etc. een brute force hacker weet niet waaruit jij allemaal gekozen hebt (https://puu.sh/yU04C/8e869fafa8.png). Heb al problemen gehad bij websites die bepaalde tekens niet accepteerden...uiteraard kies ook ik mijn tekens niet zelf. (zelf gebruik ik denk ik standaard 64 tekens met alles aangeduid behalve high ANSI characters) en erger ik mij als 64 te veel is of bepaalde tekens voor problemen zorgen.

Wat betreft het hashen ben ik wat te idealistisch waarschijnlijk, een slechte hash met een lastig en lang passwoord is inderdaad moelijker omkeerbaar dan een kort wachtwoord...
En vind Paypal ook wel belachelijk met hun 20 tekens...ook om dat 20 zo een random getal is.
Maar uiteindelijk weet je toch meestal niet hoe wachtwoorden opgeslaan worden door een dienst en kan je er enkel op vertrouwen dat de sites geen prutsers zijn, zeker als het om geldzaken gaat.

En die passwoord hasing virussen das inderdaad iets wat zorgwekkend zou kunnen zijn...

[Stoelpoot]

En die passwoord hasing virussen das inderdaad iets wat zorgwekkend zou kunnen zijn...

Ik hoop dat ik niet de enige ben die hieraan heeft gedacht. Dan zou ik namelijk een gevaar op het internet hebben gemaakt met de reactie

[mbb]

Al eens een site tegengekomen die de copy-past van een lang wachtwoord wel accepteert bij het aanmaken van de registratie, maar niet bij het inloggen?
Moest ik steeds wat tekens af halen, en dan opnieuw proberen.

[Clemens123]

oh ja die is ook frustrerend...
Of bij het registreren de bevestiging die geen paste toelaat.

[dennisvalk]

Zie bijvoorbeeld ook https://arstechnica.com/i...-can-be-bad-for-security/

Hoe relevant is een artikel uit 2013 mbt security?

Wachtwoordeisen veranderen om de haverklap (zie bijvoorbeeld https://auth0.com/blog/do...nist-password-guidelines/)

[gorgi_19]

Als het toen al een probleem was, zal het nu nog steeds een probleem zijn. In die zin dus zeker relevant; opmerkingen en constateringen die destijds zijn, wordt enkele jaren later nog steeds niets of onvoldoende mee gedaan.

Dat laat onverlet dat er steeds meer nieuwe inzichten komen, eens. Dus naast de eerdere constateringen en best practices, worden er nieuwe toegevoegd.

Zo zal binnenkort wel meer beschreven gaan worden dat een versleuteling van bcrypt (of Argon2, of welke dan ook) alleen niet voldoende meer zal zijn. Naar hashing zullen de wachtwoorden encrypt moeten worden opgeslagen in de database. Zo voorkom je dat bij toegang tot bijvoorbeeld een backup van de database, de wachtwoorden nog veilig zijn.

Deze is nog vrij weinig omschreven, maar zal ook een kwestie van tijd zijn.

[ezakimak]

Wat een onzin. Het hashen van wachtwoorden hoeft helemaal niet traag te zijn om het aantal pogingen in de tijd te beperken, dat kun je prima op andere manieren regelen.
MD5 is een probleem omdat het gewoon een zwak algoritme is waar in relatief weinig tijd collisions op te generen zijn. Heeft /niets/ met de performance te maken.

Verder spreek je jezelf tegen: als dat hashen van wachtwoorden zo traag mogelijk zou moeten zijn, dan is een langer wachtwoord juist een voordeel. Maar binnen redelijke grenzen zal de lengte van het wachtwoord echt verwaarloosbaar impact hebben op de performance. Er is dus geen enkele zinnige technische reden om dit te beperken tot lengtes onder de 100 karakters. Ergens moet je natuurlijk wel een bovengrens kiezen, want het moet ergens in een buffer passen die moet worden gealloceerd en ja als je megabytes gaat hashen dan kost dat uiteindelijk wel performance, maar dan heb je het over lengtes die zowieso niet meer praktisch bruikbaar zijn voor normale mensen.

De huidige state-of-the-art zegt dat je het beste een pasword kunt baseren op een aantal willekeurige, normale woorden (zodat het voor een mens te onthouden is), die je aan elkaar plakt. Een /lang/ wachtwoord dus (hoe langer hoe meer entropie, dus beter), zonder hoofdletters en rare special characters (want die voegen in de praktijk helemaal geen entropie toe, zeker niet als het geenforced wordt waardoor de search space van de attacker wordt verkleind).

[gorgi_19]

Je bent redelijk selectief nu aan het lezen.

Als ik een miljard hashes kan proberen, kan ik eindeloze combinaties uitproberen. Niet alleen collisons. Als een verificatie 1 miliseconde duurt, in, plaats van 100.000 verificaties per miliseconde, dan maakt snelheid wel degelijk uit. Brute force attacks zijn dan een stuk realistischer en sneller uit te voeren.

Verder over de maximale lengte: een tot voor kort (en nog steeds) veel gebruikte implementatie is bcrypt. Deze heeft een maximale lengte. zie https://www.mscharhag.com...t-maximum-password-length En ja, deze lengte is 72 karakters, dus ruim onder de 100 karakters waarvan je beweert dat er geen technische reden is.

Dat er tegenwoordig nieuwere implementaties zijn als Argon2, wil niet zeggen dat bcrypt ineens outdated is. Het zal wellicht op den duur uitgefaseerd worden, maar er is geen directe noodzaak om het direct te doen.

Daarnaast verwijs ik verderop in de post nog naar entropie.

Eveneens moet je de originele post waar ik op reageer in ogenschouw nemen. Hij nam eens site die een maximumwachtwoordlengte van minder dan 100 karakter niet serieus. Ik beweer dat 63 karakters prima voldoende veiligheid biedt.

[mrdemc]

Een maximum lengte op een wachtwoord geeft mij ook altijd direct het idee dat een wachtwoord plaintext wordt opgeslagen. Dat is namelijk de enige reden die ik kan bedenken om een maximum in te stellen. Een maximum veldlengte in de db. Bij hashing maakt de lengte namelijk helemaal niets uit. Behalve dat je daarmee ook een hoop mensen irriteert

[Aaargh!]

Bij hashing maakt de lengte namelijk helemaal niets uit.

Als je wachtwoorden veilig wilt opslaan gebruik je beter geen hashing algoritme. Hashing algoritmes zijn namelijk ontworpen om snel te zijn, je wilt voor wachtwoorden juist iets dat langzaam is en nog beter is als de snelheid instelbaar is zodat je ‘m trager kan maken wanneer computers sneller worden.

Een veelgebruikt alternatief is bcrypt en die heeft een maximum key lengte van 72 bytes, alhoewel het vaak beperkt wordt tot 56 vanwege redenen.

[TimVdE]

De eerste zes woorden van Wikipedia:

bcrypt is a password hashing function

Hashing is een algemene techniek, die simpel gezegd neerkomt op "onomkeerbare encryptie", dus je kunt er het origineel niet meer uithalen. Je hebt gelijk dat je geen snelle hash wil, en dat bcrypt een goede keuze is, maar een trage hash is nog steeds een hash

Edit: verwoording lichtjes aangepast

[Reactie gewijzigd door TimVdE op 22 juli 2024 16:28]

[OddesE]

Yup. Wat hij eigenlijk zegt is dus: pas op want niet elk hashing algoritme is ook secure voor encryptie.

Overigens maakt het natuurlijk wel uit hoe lang het password is voor hoe lang het hashen duurt, want het algoritme werkt gewoon blocksgewijs door de input bytes heen dus hoe meer input bytes, hoe langer het duurt voordat ze allemaal verwerkt zijn. Maar eerlijk gezegd... een DOS aanval doordat zoveel users tegelijk met te lange wachtwoorden proberen te registreren lijkt me toch niet een veelvoorkomend probleem eerlijk gezegd.

Ik zou eerder denken dat zulke lange wachtwoorden gewoon de user interface op de proef stellen en dat ze daarom een maximum kiezen. Want kun jij de weg nog volgen in een rij van tientallen sterretjes die horizontaal gescrolled in het wachtwoord venster staan? Ik snap dat je copy paste gebruikte, maar wachtwoorden zijn wel bedoeld om ingetyped te kunnen worden. 64 tekens vind ik geen vreemde limiet. Ik heb wel eens sites meegemaakt met 16 tekens als limiet. Kijk dat sucked dan weer wel wat mij betreft.

[TimVdE]

Zo'n DoS-aanval zal zeker niet per ongeluk gebeuren, maar het heet een DoS-aanval voor een reden

Uit dit artikel:

A password one megabyte in size, for example, will require roughly one minute of computation to check when using the PBKDF2 hasher.

Dit wil zeggen dat je met een dozijn requests met een payload van een paar MB al een hele server plat kunt leggen. Als verantwoordelijke sysadmin probeer je dat te vermijden.

Ik snap dat je copy paste gebruikte, maar wachtwoorden zijn wel bedoeld om ingetyped te kunnen worden.

Ik gebruik ook geen copy-paste, ik gebruik een password manager pass om precies te zijn. De meeste van mijn wachtwoorden heb ik zelfs nog nooit gezien, laat staan dat ik ze ken.

[OddesE]

64 vs 100 tekens vs een paar megabyte is wel een andere discussie natuurlijk he.

Maar hoe dan ook heb je gelijk natuurlijk.Alle input moet ergens beperkt worden. Anders wordt het vanzelf een attack vector. Geldt voor password velden en voor alle andere velden ook. Maar ik kan me wel voorstellen dat password velden, omdat ze gehashed worden, extra kritiek zijn. Maar van passwords van 64, of 100 of zelfs 256 tekens gaat een server niet veel merken hoor. Alleen het is geen menselijk password meer dan zal ik maar zeggen.

[TimVdE]

Helemaal mee eens hoor. Ergens anders heb ik gezegd dat ik zelf 256 characters aanhoud als maximumlengte voor password fields. Django doet blijkbaar 4k. Ik ben zeker niet aan het zeggen dat een maximumlengte van 16 tekens voor wachtwoorden een goed idee is

[Stoelpoot]

Kan je dan niet betere gewoon een request size limit op 1KB zetten oid voor non-file uploads?

[hackerhater]

Ik laat mijn code alles boven de 512 tekens transparant negeren om een dos-aanval via de login te voorkomen. Bcrypt is nogal traag en resource heavy.
Maar goed als je wachtwoord meer dan 512 tekens is spoor je niet

[Stoelpoot]

Transparant negeren? Hoe werkt dat dan?

[hackerhater]

Simpel, hij accepteerd het lange wachtwoord wel, maar kapt serverside gewoon alles na 512 tekens eraf.

[Stoelpoot]

Oke, en hoe is dat transparant? Dan blijft de gebruiker juist in de waan dat hij een lang wachtwoord heeft, maar je hebt het stiekem ingekort. Dan zie ik liever een foutmelding met uitleg van reden (omdat mensen met >512 wachtwoorden technische termen best begrijpen).

[hackerhater]

Je hebt lange wachtwoorden en enorm lange wachtwoorden.
Zelfs password managers gaan maar tot 100 a 150 tekens.
512 tekens wijst op een aanval.

[Jack Flushell]

100 tekens.
Je kan ook overdrijven. Tjongejonge.

[Reactie gewijzigd door Jack Flushell op 22 juli 2024 16:28]

[YopY]

Het zorgt niet voor moor veiligheid maar komt meestal doordat iemand lui is geweest bij het programmeren van de backend.

Juist niet; het toevoegen van een maximumlengte kost juist extra werk. Extra check, extra foutmelding (soms), etc, ipv geen check.

[watista]

" Daarnaast stellen veel sites specifieke eisen zoals een hoofdletter, cijfer of speciaal teken, waardoor de site wachtwoorden weigert die in principe wel in orde zouden zijn."

Ik dacht dit juist was zodat mensen 'sterke' wachtwoorden aanmaken, omdat wachtwoorden met alleen letters en dus geen speciale tekens niet sterk genoeg zijn, en dus sneller vatbaar zijn voor bruteforce-aanvallen.

[Keiichi]

Een extra (hoofd)letter/cijfer vergroot het aantal mogelijk te proberen combinaties met een factor 62. Het per se vereisen van een speciaal karater verhoogt het belanden van een wachtwoord op een post-it ook aanzienlijk ;-)

[Ramon]

Als de eisen zijn, 6 letters, 2 cijfers en een speciaal teken; raad eens wat de hacker als eerste gaat proberen? Alle wachtwoorden in zijn db met 6 letters; 2 cijfers en een speciaal teken.

Het maakt het dus niet per se moeilijker om te hacken.

[OddesE]

+3! Weten dat alle wachtwoorden tenminste een letter, een cijfer en een leesteken bevatten maakt het juist makkelijker! Dat is de paradox.

Hoe meer constraints je neerlegt bij het maken van het wachtwoord, hoe meer mogelijkheden je uitsluit die dus overgeslagen kunnen worden bij het brute forcen.

Als je wil dat bezoekers een sterk wachtwoord nemen, dan controleer je de sterkte van hun wachtwoord en meld je het als die te laag is. Dat is een goede UI. Wat je niet doet is een rij bullshit constraints verzinnen die makkelijk te implementeren zijn maar het de gebruiker onnodig moeilijk maken terwijl ze feitelijk niet helpen maar de boel juist makkelijker te brute forcen maken.

Hoe controleer je de sterkte van een wachtwoord? Simpel: Je kijkt naar de lengte. Dat is verreweg dé bepalende factor namelijk. Stel gewoon een minimum lengte in en toon een mooi balkje met rood, oranje, geel, groen dat laat zien hoeveel sterker het wachtwoord wordt naarmate gebruikers typen. Is ook gelijk een prettige aanmoediging voor de gebruiker. Bijvoorbeeld minimaal 5 tekens.Of 7. Of 10. Afhankelijk van hoe kritiek de gegevens zijn waar het om gaat.

Dan vervolgens zorg je ervoor dat na elke mislukte inlog poging het account een seconde gelocked wordt. Dan kan alleen het lekken van de password file nog echt problemen geven. Passwords netjes salten en ook dat probleem is grotendeels opgelost.

[Cerberus_tm]

Ik denk dat het iets ingewikkelder ligt: als mensen zonder eisen altijd alleen kleine letters gebruiken, dan zouden die eisen de totale 'ruimte van complexiteit' wel degelijk kunnen vergroten, althans in theorie. Een complicerende factor is dan weer dat mensen geneigd zijn die cijfers en speciale karakters aan het einde van hun wachtwoord te zetten, omdat ze dat zo gewend zijn; dan heb je een bekend patroon, en dragen de eisen juist weer weinig bij aan de complexiteit. Alles hangt er dus van af hoe mensen de eisen in de praktijk toepassen. En je zou wel eens gelijk kunnen hebben dat mensen die op een 'slechte' manier toepassen.

Wat mij betreft gaat het om complexiteit versus ongemak: als een bepaalde eis zorgt voor 100% extra complexiteit, maar 200% extra ongemak (moeilijker te onthouden), dan is dat meestal geen goed idee. Het hangt er ook van af waar je het mee vergelijkt: vergeleken met een zin van woorden denk ik dat die rare tekens geen goed idee zijn, omdat woorden zo veel makkelijker te onthouden zijn. Je kunt desnoods een database van bekende zinnen gebruiken om te makkelijke zinnen uit te sluiten.

[Reactie gewijzigd door Cerberus_tm op 22 juli 2024 16:28]

[PizzaMan79]

Allemaal veel te theoretisch. Een lang wachtwoord met alleen maar letters is goed te onthouden en zeer lastig te kraken.

Een korter wachtwoord met leestekens, hoofdletters en cijfers is moeilijker te onthouden en introduceert alleen al daardoor extra risico's. Het wordt ergens opgeschreven, vaker verkeerd getypt, etc.

Het is simpele wiskunde: een wachtwoord van 15 letters kent 26^15 combinaties. Dat is bijvoorbeeld meer dan 100^10. En dan ga ik nog uit van heel veel verschillende leestekens, want met alleen hoofdletters plus kleine letters plus cijfers is het 62^10.

Ook is bvb 7 leestekens/ letters/ cijfers/ hoofdletters (uitgaande van honderd mogelijkheden) iets minder veilig dan 10 letters.

En dan heb ik nog niet verrekend dat er minder mogelijkheden zijn als je verplicht een hoofdletter, cijfer of leesteken moet gebruiken. En dat het checken tegen wachtwoord lijsten dan ook makkelijker kan zijn.

[Reactie gewijzigd door PizzaMan79 op 22 juli 2024 16:28]

[Cerberus_tm]

Te theoretisch? Ik wilde juist de theorie een beetje uitdiepen.

Uit mijn theorie blijkt juist dat leestekens en cijfers geen goed idee zijn.

M.i. is een zin van woorden het beste, op basis van mijn theorette (dus niet willekeurige letters).

[3raser]

Een zin van woorden is dan weer erg vatbaar voor dictionary attacks. Oftewel, een aanval die zich richt op wachtwoorden die zijn samengesteld door woorden. Het aantal combinaties wordt daarmee namelijk best wel beperkt ten opzichte van een wachtwoord met dezelfde lengte die uit willekeurige letters bestaat.

Onderaan de streep is de vraag ook een beetje wat je probeert te beveiligen. Als de aanval zich richt op 1 gebruiker waarvan de wachtwoord-hash bekend is dan is dit bijna niet te beveiligen. Met voldoende tijd en resources komt men het wachtwoord te weten. Beveilig je een website welke wordt aangevallen dan kun je na iedere foute poging de timeout verlengen. Zeer effectief en de aanval is dan gedoemd te mislukken. Ongeacht de wachtwoord sterkte.

[Reactie gewijzigd door 3raser op 22 juli 2024 16:28]

[Cerberus_tm]

Dat is helemaal waar, en daarom moet je dan een langer wachtwoord gebruiken dan bij willekeurige letters. Daar is het nadeel. Daar staat tegenover dat een woord extreem veel makkelijker te onthouden is dan een aantal willekeurige letters. Daarom ben ik van mening dat het voordeel ruimschoots opweegt tegen het nadeel; een willekeurige letter is voor mij bijna even moeilijk/makkelijk te onthouden als een woord.

[3raser]

Je moet simpelweg een wachtwoord manager gebruiken. Dan heb je geen last van trucjes met woorden om je wachtwoord te kunnen onthouden. Ook als de betreffende website "rare" eisen stelt is het geen probleem. Het enige probleem is dat sommige website een maximale lengte hanteren die te laag is. Bijvoorbeeld maximaal 12 of 20 tekens. Dat is pas onveilig! Laat gebruikers minimaal 64 karakters gebruiken. Dat komt de veiligheid alleen maar ten goede. Zeker nu er steeds meer wachtwoord managers worden gebruikt.

[Cerberus_tm]

Een wachtwoordmanager is zeker goed, maar willekeurige tekens is toch wel erg onhandig als je even iets op een andere computer wilt doen. Of op je mobiel: met sommige managers kun je wel synchroniseren, maar het werkt niet altijd even goed, en niet in alle apps. Het is toch wel fijn om het ook zelf in te kunnen tikken. En misschien wil je je drie allerbelangrijkste wachtwoorden niet aan de manager toevertrouwen, mocht die gehakt worden.

[jsnl]

Heb wel vaker gelezen dat een wachtwoord bestaande uit losse woorden al goed is, nog beter om woorden uit meerdere talen te kiezen, waarbij het summum is om hier ook nog een dialect bij te gebruiken.
Je leest er van alles over, vaak tegenstrijdig, dat je op een gegeven moment door de bomen het bos niet meer ziet...

Aanvulling: b.v. gebruik van Limburgs in een wachtwoord, is ook nog per streek verschillende schrijfwijze van woorden, die zelfs niet op elkaar lijken!
Voorbeeld: emmer in NL is in Limburgs: ummer / eimer etc.

[Reactie gewijzigd door jsnl op 22 juli 2024 16:28]

[Cerberus_tm]

Dat is inderdaad heel goed. Gebruik zelf ook wel minder bekende talen.

[PizzaMan79]

Dus eigenlijk ben je het eens met OdessE? Dat bleek niet uit je aanhef.

[Cerberus_tm]

Ik ben het eens met belangrijke bezwaren die hij noemt, en wilde die op een bepaald punt nog iets beter onderbouwen dan hij deed.

Aan zijn oplossing voor de website-kant wilde ik een oplossing voor de gebruiker-kant toevoegen.

Met jouw bezwaren ben ik het ook wel eens, maar met je oplossing niet echt. Je bespreekt niet de voor- en nadelen van meerdere woorden i.p.v. willekeurige letters.

[Reactie gewijzigd door Cerberus_tm op 22 juli 2024 16:28]

[PizzaMan79]

Klopt, maar dat nadeel van bekende woorden heb je bij verplichte leestekens ook, omdat het wachtwoord heel vaak op een voorspelbare manier voorzien wordt van hoofdletters (eerste letter), cijfers en leestekens. Er zit natuurlijk enige variatie in, maar ik vind dit geen wezenlijk verschil qua veiligheid tussen langere wachtwoorden of wachtwoorden met meer soorten tekens.

[Cerberus_tm]

Ik gebruik zelf ook vaak en zin van woorden, ben er erg voor.

[Sleurhutje]

Een wachtwoord dat bestaat uit alleen letters maakt de kans aanzienlijk groter dat het woorden betreft. In dat geval is een dictionary attack vele malen makkelijker en sneller dan brute force. Dus dat maakt een lang wachtwoord met alleen letters weer kwetsbaarder.

Het is niet zo lastig om gebruikers uit te leggen dat ze een wachtwoord moeten bedenken met een groente of fruit, een kleur en iets dat op hun bureau staat, elk woord eindigen met een hoofdletter en na elke eerste letter een leesteken. Je krijgt dan iets van b#anaaNo#ranjEm#onitoR. Daar helpt geen dictionary tegen en brute force zal veel tijd in beslag nemen.

[Fidler]

Behalve dan dat je op deze manier binnen je bedrijf erg makkelijk het wachtwoord van een collega kan raden..... Zoals eerder gezegd, als je de mogelijkheden/opbouw van een wachtwoord beperkt of dicteert word het raden ervan alleen maar makkelijker.

[Sleurhutje]

Niet zo strikt, dit is als voorbeeld. Een gebruiker kan dan zelf kiezen welk karakter als hoofdletter en waar het leesteken te plaatsen (anders dan resp. eerste letter en leesteken tussen de woorden).

[foaly]

probleem is dat als de aanvaller dat weet, hij die regel in zijn dictionary attack toevoegt en dan ben je terug bij af.

[PizzaMan79]

Zie mijn reactie hierboven.

[TimvH]

Als ze het al helemaal goed willen doen maken ze een lokale kopie van de haveibeenpowned lijst van hashes van uitgelekte wachtwoorden.
Dan kunnen ze de hash van het ingevoerde password met de lijst vergelijken, staat hij erop dan kan er aanbevolen/verplicht worden om een ander te nemen.
Dit zou voor diensten als social media, internetbankieren, DigiD etc. een zeer goede toevoeging zijn aangezien veel mensen toch geneigd zijn om steeds maar hetzelfde oude wachtwoord te hergebruiken.

[L0we]

Waarom maakt dat het niet moeilijker?

6 letters, 6 keer 52 mogelijkheden als je alleen hoofd-en kleine letters hebt. Op het moment dat je daar nog cijfers en speciale tekens aan toevoegt, vergroot je alleen maar het aantal mogelijkheden en daarmee ook de moeilijkheid om het te kraken.

[Sissors]

Jij gaat uit van dat elk teken willekeurig is. De simpelere password strength checkers doen dat ook, maar realistisch is anders. Hackers zijn geen idioten, mensen zijn wel lui. Bijvoorbeeld gebruikmakend van: https://lowe.github.io/tryzxcvbn/ (ik had altijd een andere, maar deze lijkt ook prima). Ik ga even uit van Engels gezien die geen Nederlandse woorden in de dictionary heeft.

Mijn belabberde wachtwoord is: "cookiejar". Log10 guesses is 5.3. Nu ga ik alle geweldige veiligheidsadviezen die we kennen meenemen, en wordt het: "C00kiejar!", Log10 guesses is nu 6.9. Ja dat is logarithmisch, dus kost en hoop tijd, maar nou niet geweldig is het geworden. En dat is ervan uitgaande dat een hacker niet de eisen van hoofdletter en speciale tekens al meeneemt, waar ik wel durf te stellen dat het merendeel eerste letter hoofdletter heeft en een uitroepteken of vraagteken aan het einde (of s -> $). Eige onbekende is dan nog welke letters ik precies vervangen heb door cijfers.

Nu als alternatief vervang ik één letter door een andere lowercase letter: "colkiejar", en nu is de log10 guesses 9 geworden. Dus heel veel beter, ook al voldoe ik aan geen enkele wachtwoord eis, simpelweg omdat dictionary attacks nu niet meer erop werken.

Maar zolang het lekker makkelijk is om vinkjes aan te zetten bij software om zulke stomme eisen aan wachtwoorden te stellen zullen die wel blijven. Terwijl wat logisch is, is wat redelijke eisen aan lengte stellen (dus niet 20 characters minimaal), en wachtwoord checken tegen database veelvoorkomende wachtwoorden.

[lordfragger]

Omdat gebruikers nog altijd mensen zijn, en dus lui.

Je kan er zeker van zijn dat een overgroot deel van die wachtwoorden gaat eindigen met de cijfers en, als het verplicht is, begint met een hoofdletter.

Zo is een maatregel om sterkere paswoorden af te dwingen plots een patroon geworden waarmee het aantal mogelijkheden die een aanvaller moet proberen beperkt. Dat gaat zeker niet voor alle wachtwoorden op, maar helaas wel voor een groot aantal.

Een paswoord met 16+ lowercase letters gaat ook niet snel gebruteforced worden, dat gebeurt vanaf een 8-tal karakters alleen nog via dictionary attacks (en afgeleiden).

[PizzaMan79]

Het hangt er wel een beetje van af hoe wachtwoorden opgeslagen worden. Ik heb bijvoorbeeld in het tijdperk dat veel bedrijven maar op Windows Xp bleven hangen, veel lol gehad met lanman wachtwoorden. Ook die met veel leestekens.

[bilgy_no1]

Alle permutaties die buiten de regels vallen kun je weglaten.

Dus als de regel is minimaal 6, maximaal 10 tekens, minimaal 1 hoofdletter, 1 cijfer en 1 leesteken (uit een beperkte set wat je soms tegenkomt), dan sluit je behoorlijk wat uit.

Maar goed, volgens mij is het risico van brute Force makkelijk te verkleinen tot nihile proporties door een maximaal aantal pogingen in te stellen.

[Reactie gewijzigd door bilgy_no1 op 22 juli 2024 16:28]

[SunnieNL]

Een maximum van 6 letters vereisen is stupid.
Waarom mag ik niet een wachtwoord van 15-20 alpha tekens met hoofd/kleine letters? Die is veiliger dan een leesteken.
Ik denk dat LiesjeLeerdeLotjeLopenLangsDeLangeLindelaan een stuk lastiger te kraken is dan W3lk0m# terwijl die ook nog makkelijker te onthouden is.

[Mathi159]

Simpelweg slechts de eerste letter een hoofdletter maken vang je vrij veel van deze "sterkere" wachtwoorden op. Zwakste schakel zit voor het scherm.

[Joris]

Een wachtwoord op een post-it is niet eens een heel gek idee. Het is in ieder geval in veel opzichten beter dan een slecht wachtwoord. Een online aanvaller kan immers vaak niet zien wat er op het beeldscherm zit geplakt. En laat dat nou net een bijzonder groot deel van de aanvallers zijn.

[Keuvie]

https://www.tomsguide.com...ice-wrong,news-25617.html

Diegene die hiervoor het advies heeft gegeven heeft er ook spijt van.

Edit: Omdat nog niemand hem heeft geplaatst de comic van XKCD:
https://xkcd.com/936/

[Reactie gewijzigd door Keuvie op 22 juli 2024 16:28]

[kr4t0s]

Nadeel van het bekende stripje: wachtwoord is te lang en geen cijfers of vreemde tekens. Wat op veel plekken een requirement weer is

[batjes]

Die websites met zulke requirements mogen ook wel een stootje van de consumentenbond krijgen.

Ik neem de veiligheid van zulke websites gewoon niet serieus, want de bende is blijkbaar opgezet door iemand zonder kennis van security.

[Stoelpoot]

Ja, dat is het hele punt van het stripje: De bewering dat een vreemde-tekens wachtwoord beter is dan een lang, simpel wachtwoord ontkrachten.

[Bor]

Ook die XKCD cartoon ligt onder vuur:

password-security-why-the-horse-battery-staple-is-not-correct

[Reactie gewijzigd door Bor op 22 juli 2024 16:28]

[Mickey77]

Is de schrijver toevallig een bedenker/developer van een password manager?

Ik heb geen lekker gevoel bij het gebruik van password managers. Als je daar een probleem mee hebt, of het kwijtraakt, is de schade heel erg groot. Om maar te zwijgen over wat er gebeurt als een van de bekende password managers corrupt blijkt te zijn.

Ik denk dat het beste advies voor mensen is om voor de echte belangrijke zaken heel goede passwords te gebruiken en voor de minder belangrijke dingen vooral ANDERE passwords, die je heel erg makkelijk kunt houden. Zo kun je focussen op het onthouden van alleen die echt belangrijke wachtwoorden ipv heel erg veel. Maarja, iedereen zijn ding.

[Anoniem: 1017507]

Wilde ik NET zeggen.

[JAVE]

Een wachtwoord van 10 karakters dat voor mensen moeilijk te onthouden is, is voor een computer net zo makkelijk te kraken als een wachtwoord van 10 karakters dat wel makkelijk te onthouden is.

Het gaat namelijk om de lengte. 1 letter (dus zonder cijfgers en leestekens voor het gemak) heeft 52 mogelijkheden, 2 letters zijn 52 * 52, 3 letters zijn 52 * 52 * 52, enzovoorts

[JoooostB]

Niet helemaal waar als ze gebruik maken van dictionairy attacks, toch?

[Caelestis]

Veel mensen overschatten dictionary attacks. Er hoeft letterlijk maar 1 char anders te zijn dan de vergelijkingsmateriaal in het "dictionary" en je zal het nooit vinden.
Over het algemeen als je een paswoord gebruikt wat bestaat uit 1 woord dan heeft het nut maar zodra je meerdere woorden gebruikt welke makkelijk te onthouden zijn in een andere volgorde als gebruikelijk in je taal dan zit je goed.
Goedenmorgen = zwak
Morgengoed = sterk
Nou gaat dit natuurlijk over dictionary attacks en niet zozeer algemene sterkte want feit blijft hoe langer hoe beter.

[Reactie gewijzigd door Caelestis op 22 juli 2024 16:28]

[Bor]

Veel mensen overschatten dictionary attacks. Er hoeft letterlijk maar 1 char anders te zijn dan de vergelijkingsmateriaal in het "dictionary" en je zal het nooit vinden.

Vroeger klopte dat inderdaad. Tegenwoordig is de tooling en techniek veel slimmer en houdt deze rekening met variaties en veel gebruikte substituties. Een pure dictionary attack zie je dan ook minder en minder. Het is veel meer een hybride vorm of men gebruikt rainbow tables wanneer bijvoorbeeld hashes eenmaal verkregen zijn.

[kr4t0s]

Die dictionaries kun je zo downloaden en zijn gigantisch groot en compleet 20gb+ puur tekst. Nederlands woordenboek is slechts 250kb ofzo. Kun je nagaat hoe groot die dictionaries zijn.

[TimVdE]

Dat is ook niet helemaal waar. Krakers proberen eerst common passwords en (varianten op) bestaande woorden. "aaaaaaaaaa" is duidelijk minder veilig dan "tcX3NjCPyK"

[Caelestis]

yup "aaaaaaaaaa" is minder veilig dan "tcX3NjCPyK" echter is dat dan weer minder veilig dan "aaaaa1aaaaa"

[TimVdE]

Daar ben ik het absoluut niet mee eens. Lengte is niet het enige dat telt. Het gaat om entropie, en lengte is een grote, maar niet de enige factor die daarin meespeelt.

[Caelestis]

Tuurlijk is lengte niet het enige wat mee telt maar in een wereld van 1 en 0 is entropie minder van belang dan je denkt.
Entropie speelt alleen een rol met menselijk gemaakte voorspellingen om het kraken te versnellen (dictonary attacks) maar zodra het complexiteit voorbij gaat aan wat de mens als voorspelling kan programmeren wordt je volledig afhankelijk van bruteforce en dan is het aantal combinatie mogelijkheden alles.
Eigenlijk zijn verplichte eisen zoals "minimaal een hoofdletter" of "maximaal 12 tekens" veel erger omdat het mogelijke opties wegneemt wat een bruteforce hoeft uit te voeren.
Als alles erin kan zitten heb je meer mogelijkheden en wordt het algemeen gebruik complexer. Dat wil niet zeggen complexer voor de mens om te onthouden maar complexer voor de computer om te kraken.
Al die regeltjes van "je moet dit" en "je moet dat" zijn achterlijk het moet zijn
Je mag
-256 tekens
-Hoofdletters
-nummers
-speciale tekens
gebruiken
een paswoord als "mijnkatheeftgeenzinin3paswoorden" Is zo makkelijk om te onthouden maar geen enkel computer op aarde buiten een quantum computer zal dit ooit raden zolang jij leeft.
Geen hoofdletter of speciale tekens en raar gedoe wat moeilijk te onthouden is.
Dit zal in een wereld van "je moet" nooit als veilig paswoord geaccepteerd worden.

[TimVdE]

Ik ben het eens met zowat alles wat je hier zegt, maar een wachtwoord als "aaaaa1aaaaa" haalt de entropie zo hard naar beneden, dat het echt geen sterk wachtwoord is. Bruteforcers zijn gemaakt om dingen eerst te proberen die mensen geneigd zijn om te nemen, zoals woorden, jaartallen en reeksen. Een wachtwoord dat voor 10/11 tekens uit enkel a's bestaat, heeft niet genoeg variatie. Deze blogpost van Dropbox is een goede bron, en herhaalt heel wat van de dingen die jij zegt, maar duidt ook op het belang van voorspelbaarheid vermijden.

[Caelestis]

Ik zeg ook niet dat "aaaaa1aaaaa" een goed paswoord is maar feitelijk is en blijft het een sterker paswoord als "tcX3NjCPyK".
Het gaat erom of je beseft wat jij als mens als complex ervaart en wat voor een computer complex is twee heel verschillende dingen zijn.

"tcX3NjCPyK" lijk heel ingewikkeld voor ons maar voor een computer kan er net zo goed "bcafdegjhi" staan terwijl er geen enkel hoofdletter nummer of speciale teken in zit maar wel bestaat uit de eerste 10 letters van ons alphabet. (en geen dictionary attack die het vindt)
Zolang de mogelijkheid bestaat dat er een nummer in zit zal de computer alle nummers mee nemen in zijn rotatie van gekozen chars. Of er een nummer in zit of niet weet het computer pas als het paswoord is geraden dus of jij er een in doet maakt geen moer uit zolang de mogelijkheid maar aanwezig is.
Elke teken minder wat jij kiest zorgt ervoor dat het computer met een factor ~62 keer eerder klaar is.

[TimVdE]

Het gaat erom of je beseft wat jij als mens als complex ervaart en wat voor een computer complex is twee heel verschillende dingen zijn.

Dat klopt. Maar een computerprogramma dat geschreven is om wachtwoorden die verzonnen zijn door mensen te kraken, zal misbruik maken van patronen die wij er als mens in steken. Geen enkele tool zal in praktijk de hele oplossingsruimte bit per bit af gaan.

[Caelestis]

Ja en dan gaan we als "beveiligingsexperts" die patronen of zo ingewikkeld maken dat de mensen het zelf niet kunnen onthouden en de pet ernaar gooien of zo achterlijk instellen dat de helft van het dictionary bestaat uit
-alle paswoorden zonder hoofdletters, nummers en speciale tekens vallen automatisch af en is niet korter/langer dan 8-12 tekens.... Hoezo niet makkelijk om te hacken voor een computer?

Ik heb werkelijk waar nog nooit een reden kunnen bedenken waarom het lengte van een paswoord beperkt moest worden. (niet dat het overal gebeurt maar is nog altijd een uitzondering ipv de regel)

[TimVdE]

Waar heb ik dan gezegd dat je de lengte van wachtwoorden moet beperken (behalve dan op een belachelijke lengte om DoS-aanvallen tegen te gaan)? Natuurlijk zijn langere wachtwoorden beter, maar niet onvoorwaardelijk. Een wachtwoord van één teken langer met veel minder entropie is niet beter dan een willekeurig wachtwoord. Dat is het enige waar ik met je over discussieerde. Ik zei zelfs letterlijk dat ik het eens was met veel van wat je zei. Maar je conclusie dat lengte het enige is wat telt, volg ik niet.

Natuurlijk, als je het hebt over wachtwoorden die mensen kunnen onthouden, dan is een willekeurige string van tekens niet zo handig. Maar daarvoor zijn er password managers uitgevonden natuurlijk

[Caelestis]

Dat van lengte beperking was meer gericht op algemene regels mbt instellen van paswoorden en niet zozeer op jou persoonlijk gericht in dit argument.
Echter dat entropie waar jij op doelt ziet een computer niet. Alleen de mens ziet dat en het gaat er om dat je dus buiten schot blijft van die "patronen" en gelukkig is er geen sprake van "bijna geraden" het is 1 of 0 dus als je ook maar 1 char afwijkt van elke patroon gebakken in het dictionary dan is die volkomen nutteloos geworden.
Zodra dat niet meer van toepassing is blijft alleen brute force over en dan blijft alleen het complexiteit van combinatie mogelijkheden over en is lengte dus key.
Je denkt wel dat aaaaa1aaaaa zo'n slechte "entropie" heeft maar vertel onder welke patroon zou het vallen ? En is dat hetzelfde als ik aaaaa~aaaaa of aaa@aazzzzz zou doen? Over welke patroon hebben we het nu dat een dictionary attack dit zou kunnen voorspellen?
Ik zeg dat het juist sterker is omdat het juist geen onderdeel uitmaakt van een standaard patroon en dan 1 teken langer dus een factor 62* moeilijker is voor een computer om te hacken dan jou voorbeeld.

[TimVdE]

Het valt onder "repetition". Of je het nu in letters of binair ziet, aaaaa of 0110000101100001011000010110000101100001, er zit een duidelijk patroon in. Lees even de blogpost van Dropbox die ik gepost had, die legt het duidelijk uit.

people of course choose patterns — dictionary words, spatial patterns like qwerty, asdf or zxcvbn, repeats like aaaaaaa, sequences like abcdef or 654321, or some combination of the above. (...)

Dit kan door tools makkelijk misbruikt worden om paswoorden te kraken.

[Caelestis]

Nogmaals een computer ziet geen patronen alleen de mens ziet dat en kan dat in programmeren. Ja iets als asdf , 654321 of aaaaaaa is een patroon maar als een patroon gebroken wordt met iets helemaal willekeurig zoals dus aaaaa1aaaaa wordt het dan alsnog herkend als een patroon?
Je bakt in je tool dat als iemand alleen maar aaaaaaaa in tikt je iets vindt maar ga je dan ook nog
aaaa_aaaa_aaaa
aaa_aa_aaa_aa
aa_aa_aa
a_aaa_aa_aaa_a
enz... er allemaal inbakken? Wanneer kom je op het punt dat je patronen net zo ingewikkeld worden als een brute force attack zelf en dus niks opleveren?

[TimVdE]

Ja, dat wordt alsnog herkend als een patroon, zeker als er maar één teken anders is. Hier is de originele demo van Dropbox (de link in de blogpost werkt niet meer). Speel er maar wat mee rond.

[JAVE]

Nee, brute forcing betekent beginnen met 'a' en eindigen met 'zzzzzzzzzz' (bij wijze van spreken).
Zodra je met aannames (mate van waarschijnlijkheid, dictionaries) begint is het meer dan brute forcing.

Eigenlijk is 'aaaaaaaaa' behoorlijk veilig als er mensen zitten te hacken, omdat die uitgaan van 'Niemand is zo achterlijk om dat als wachtwoord te gebruiken'

[TimVdE]

Dat noem ik eerder een gevalletje tomato-tomato. Een computerprogramma dat zonder enige kennis alle mogelijkheden af gaat, noem ik een bruteforcer. Dat verandert voor mij niet als dat programma heuristieken toepast om te beslissen welke wachtwoorden meer waarschijnlijk zijn, zoals een dictionary of andere patronen. Maar als jij dat anders ziet, kan ik dat in principe niet tegenspreken. Punt blijft dat in praktijk zulke heuristieken worden toegepast, met als gevolg dat "aaaaa1aaaaa" een vrij slecht wachtwoord is, maar "tcX3NjCPyK" best wel degelijk, ondanks dat het een teken korter is.

[xAn52]

Hij is 1 karakter langer. Dus veiliger. Stellen dat 1 karakter een hoofdletter MOET zijn beperkt de keuze voor 1 karakter tot 26 en bij een cijfer tot 10. Als het MAG is, kunnen alle karakters 80+ (geen idee hoeveel) waarden hebben. ben je iets langer bezig omdat je dan alles langs moet.

[TimVdE]

Dat is enkel het geval bij een domme bruteforcer. Mensen zijn echter geneigd om bestaande woorden of patronen te gebruiken, omdat dit makkelijker te onthouden is. Slimmere bruteforcers buiten dit dan ook uit, en proberen dit soort wachtwoorden eerst. Door een volledig willekeurig wachtwoord te gebruiken, dwing je ook de slimme bruteforcers terug te vallen op het één voor één itereren over alle mogelijkheden.

Edit: zoals ik ook in mijn andere reactie hebt gezegd, lees zeker even deze blogpost van Dropbox.

[Reactie gewijzigd door TimVdE op 22 juli 2024 16:28]

[Anoniem: 420148]

Wachtwoorden met die aan deze eisen voldoen zijn niet specifiek sterk. P4ssw0rd! voldoet aan de eisen, maar dit is dus alles behalve veilig. "Rode Bloemen Zijn Mooi" is vele malen sterker, maar voldoet niet aan de eisen van de meeste sites. De spaties mogen soms niet eens.

[celshof]

Yep, P4ssw0rd is inderdaad een bekende: https://haveibeenpwned.com/Passwords.

[kr4t0s]

Rode Bloemen Zijn Mooi is een correct Nederlandse zin wat het zwakker maakt. Iets als Kersen_Mijnoma_Viool_Kloothommels is veiliger

[celshof]

Het probleem is, dat een brute-force aanval meestal niet met random karakters uitgevoerd worden, maar met lijsten. En op die lijsten worden de standaardzaken als een 3 voor een E of eindigend op een ! ook meegenomen. Zo zal Qwerty123! vast bij de meeste sites geaccepteerd worden, maar is veel onveiliger dan bijv watista_heeft_een_wachtwoord_met_8_letters

[Blokker_1999]

10 jaar terug zou ik je nog gelijk gegeven hebben. Vandaag is het belangrijker dat je hen de mogelijkheid bied maar niet verplicht en enkel verwacht dat het wachtwoord lang genoeg is.

[klonic]

als je alleen letters gebruikt zijn de mogelijke combinaties 26^aantal tekens
hoofdlettergevoelig: (26*2)^aantal tekens
met cijfers: (26*2+10)^aantal tekens
Mijn mactoetsenbord heeft 35 verschillende leestekens, voeg je die erbij, dan wordt het:
leestekens: (26*2+10+35)^aantal tekens

6 willekeurige tekens geeft dus een slechter wachtwoord als 10 willekeurige hoofdletterongevoelige letters. Dit is een van de 'issues' met hoe men met wachtwoorden omgaat. Websites eisen compleet belachelijke wachtwoorden die niet te onthouden zijn. Iets als "ik haat gloeilampen en het bos" staat ook leestekens toe. Als dit brute force gekraakt moet worden, moet een computer alsnog alle leestekens afgaan en waarschijnlijk ook cijfers en hoofdletters, maar zelfs al zou dit een lange zin zijn (zonder de spaties) dan nog zijn dit 25 tekens (26^25=2*10³⁵). Met brute force ben je dan al wel even bezig. Gaat een computer zinnen proberen, dan is dit nog steeds een crime om te kraken (oh ja, een website moet na de duizendste foute poging het account natuurlijk blokkeren of een pauze inlassen).

De strekking van mijn betoog, wachtwoorden kunnen een stuk efficiënter zonder in te boeten op veiligheid.

[erwinwernars]

Ja dat is al een achterhaalde techniek, momenteel is het beste wachtwoord een passphrase makkelijk te onthouden maar nog moeilijker te ontcijferen.

Ik irriteer me er juist aan dat er dan weer een hoofdletter en een cijfer of speciaalteken perse inmoet (of soms wel allebei) zoals bij DigiD.

voor dat soort wachtwoorden gebruik ik dan dus ook een password manager, maarja als dat dus niet meer verplicht is, is het allemaal uit het kopje

[Flozem]

Vergeet niet dat niet alleen lengte van belang is. Frequent wijzigen van je wachtwoord(zin) en je wachtwoord voor elke site uniek houden is minstens zo belangrijk.

Websites die nog te brute-forcen zijn, zijn per definitie niet veilig. Ook niet met lange wachtwoorden.

[Olaf van der Spek]

Waarom is frequent wijzigen belangrijk?

Websites die nog te brute-forcen zijn, zijn per definitie niet veilig. Ook niet met lange wachtwoorden.

Want? Een echt random wachtwoord met lengte 64 ga je echt niet brute-forcen..

[Reactie gewijzigd door Olaf van der Spek op 22 juli 2024 16:28]

[Flozem]

Jawel... Het duurt alleen langer. Maar wanneer een website na drie keer proberen blokkeert, is geen enkel zinnig wachtwoord te brute-forcen.

Frequent wijzigen, zorgt ervoor dat je accounts in geval van een onbemerkte hack en het wél gebruiken van één wachtwoord toch nog beschermd blijven.

[Reactie gewijzigd door Flozem op 22 juli 2024 16:28]

[mrdemc]

Als de hack onbemerkt is heb je natuurlijk ook een kans dat de hacker nog steeds meekijkt. In dat geval zou het nieuwe wachtwoord ook worden onderschept.

[.oisyn]

Frequent wijzigen zorgt ervoor dat mensen wachtwoorden op post-its opschrijven of gewoon standaard patronen gebruiken. NIST raadt tegenwoordig niet voor niets af om wachtwoorden regelmatig te laten expiren.

[Stoelpoot]

In principe geld dit alleen voor wachtwoorden die mensen zelf onthouden. Een goede wachtwoordmanager helpt hiermee

[Olaf van der Spek]

Jawel... Het duurt alleen langer.

Als het een miljoen miljard jaar duurt kan ik het geen kraken meer noemen..

en het wél gebruiken van één wachtwoord toch nog beschermd blijven.

Wachtwoorden niet hergebruiken is dus DE oplossing, niet het frequent wijzigen.

[OddesE]

Het is nog veel simpeler. Er zijn eigenlijk maar 2 scnario's:

1. Wachtwoord genereren en laten checken door het systeem (inlog poging)
2. Wachtwoord genereren en zelf checken (je hebt de password file bemachtigd)

In het eerste geval heb je medewerking van het systeem nodig. Aantal inlog pogingen rate limiten is hier een hele effectieve maatregel waar gewone gebruikers niks van merken terwijl brute forcen er vrijwel onmogelijk mee wordt gemaakt. Je kunt als extra security na een x aantal mislukte pogingen nog een captcha laten zien.

In het tweede geval heeft de aanvaller de password file buitgemaakt en kan hij zijn pogingen zelf verifieren. Hier kun je dus niet rate limiten en kan hij op volle snelheid wachtwoorden testen.

MAAR:

Als je je passwords netjes gehashed hebt met salt en pepper, dan is de input van de gebruiker vrijwel irrelevant geworden. Die maakt voor het brute forcen dan niks uit. Want men heeft dan aan de input van de gebruiker twee extra waarden toegevoegd: de salt (staat ook los in de password file) en de pepper (staat ergens anders op de server van de dienst, maar is dus als het goed is niet in handen van de aanvaller gekomen).

Opvallend in beide scenario's is dat gebruikers met relatief zwakke wachtwoorden weinig gevaar lopen.

[NullCrayfish]

Ha grappig!
Ik kwam eens op het idee om met 2 salts te werken, één in de database en één in een bestand weggeschreven. Voor de grap noemde ik de 2e pepper, mijzelf onbewust zijnde dat dat dus daadwerkelijk een ding is.

[vanaalten]

Lijkt mij alleen nuttig als je op meerdere sites hetzelfde wachtwoord gebruikt. Als dan 1 site lek is, dan zal - na een wijziging op de andere sites - je accounts op die andere sites weer veilig zijn.

Maar ik zie eerlijk gezegd het nut van frequent wijzigen ook niet, als je al een uniek wachtwoord per site hebt.

[Bor]

Want? Een echt random wachtwoord met lengte 64 ga je echt niet brute-forcen..

Dat hangt natuurlijk ook totaal van de gehanteerde character set af. Wanneer die lengte 64 alleen (expres gecharcheerd) alleen 1 en 0 toestaat is een bruteforce relatief vrij snel. Houdt er ook rekening mee dat mensen vaak dezelfde trucs uithalen om aan de meestal verplichte speciale karakters te komen (bv toevoegen van 01).

[Flozem]

Dit dus...

Hoeveel sites kennen we die meer dan 10 volledig willekeurige karakters toe staan? In de praktijk wordt het aantal mogelijkheden al door de sites zelf gelimiteerd. Juist de sites die brute forcing impliciet toestaan zijn dezelfde met veel te beperkte wachtwoord opties.

Daarnaast staat de techniek niet stil. Wat nu enkele eeuwen kost om te kraken, zal over enige tijd binnen dagen gekraakt zijn. Quantum computers, anyone?

Wachtwoorden frequent wijzigen is daarmee imho nog geen overbodige luxe.

[Reactie gewijzigd door Flozem op 22 juli 2024 16:28]

[Olaf van der Spek]

Hoeveel sites kennen we die meer dan 10 volledig willekeurige karakters toe staan?

Bijzondere tekens zijn niet nodig, een langer wachtwoord volstaat.

Quantum computers, anyone?

Voor zover ik weet niet van toepassing op password hashing..

[Olaf van der Spek]

Dat hangt natuurlijk ook totaal van de gehanteerde character set af.

Uiteraard

Wanneer die lengte 64 alleen (expres gecharcheerd) alleen 1 en 0 toestaat is een bruteforce relatief vrij snel.

Is dat zo?
64 bits is ongeveer equivalent met een normaal wachtwoord met lengte 10.
Het ging over een online attack (hash onbekend), maar zelfs met een offline attack is dat geen eitje. Met een goede hash functie is het niet te doen.
2 ^ 64 = 18446744073709551616

[Reactie gewijzigd door Olaf van der Spek op 22 juli 2024 16:28]

[Luno]

Wijzigen is zinloos als alleen jij en de site het wachtwoord kennen. Dit moeten wijzigen is een achterhaald idee.
Aangenomen dat jij het wachtwoord niet deelt, en de andere kant het ook veilig heeft opgeslagen is wijzigingen onzin. Heeft de ander knat het niet veilig opgeslagen dat is elke periode na 1 cpu cycle te laat. 3 maanden is dat niet veiliger dan 1 week, of 1 dag, of 1 seconde.
Dit fabeltje gaat al veel te lang rond.
Ik schat dat VISA ook enigszins heeft nagedacht over dit aspect (als wereldwijde financiële, niet zo kleine, organisatie), en m'n wachtwoord daar heb ik nog nooit hoeven veranderen. Zij hebben het begrepen.

Mijn schatting is dat door de eis van wijzigen er meer wachtwoorden middels geeltjes openbaar geworden zijn dan door welke maatregel ook.

Afgelopen jaar heeft de NIST (The National Institute of Standards and Technology) de regels voor goed password gebruik aangepast. Zie bv.

https://www.itispivotal.c...p-obsolete-password-rules
O.a. stellen ze dat de oorspronkelijk reden voor wijzigen nergens op sloeg en die is dus nu ook verdwenen

[RobbieB]

Eens, mensen vergeten vaak dat regelmatig wijzigen voor veel mensen alleen maar voor problemen zorgt. Ze vergeten hun wachtwoord, moeten weer resetten en kiezen vervolgens hetzelfde wachtwoord + 1...
Welkom01
Welkom02
Welkom03

Etc. In de praktijk al vaak genoeg gezien. Ik ben groot voorstander vh afdwingen van wachtwoorden van +25 tekens. Mensen gaan dan daadwerkelijk nadenken over wat ze hier makkelijk kunnen onthouden met als gevolg dat iedereen er op vooruit gaat... maar ja, kom daar maar eens mee aan bij je marketing/design afdeling... gelukkig gaan we nu van 8 naar 10... kleine stapjes

[OddesE]

Tja ik weet niet hoor. Lengte is de belangrijkste factor. Zeker. Maar elk nieuw karakter voegt een factor.. wat? 40? aan complexiteit toe... dus een wachtwoord van 10 tekens heeft dan grofweg 40 tot de macht 10 aan complexiteit. Voeg hier een teken aan toe en het gaat weer keer 40. En weer en weer bij meer tekens. 25 tekens lijkt me regelrechte overkill eerlijk gezegd. Het is niet lineair he. Het is een logaritmische schaal zeg maar. Dus een wachtwoord van 20 tekens is niet 2 keer zo sterk als een van 10 tekens maar 40^10 keer zo sterk.

[Bor]

In jouw link komt helemaal niet naar voren dat het wijzigen van een achtwoord een achterhaald idee is. Het gaat over passphrases ipv passwords maar gaat daar verder technisch gezien vrijwel niet op in. Gezien het gros van de websites en systemen geen passphrases ondersteunen heeft het frequent wijzigen absoluut zin.

Aangenomen dat jij het wachtwoord niet deelt, en de andere kant het ook veilig heeft opgeslagen is wijzigingen onzin.

Wanneer je als site de mogelijkheid open laat voor de brute force en matige wachtwoorden gaat jouw stelling niet op. Ook als jij het wachtwoord niet deelt en de site het veilig heeft opgeslagen (gehashed en gesalt etc) ben je alsnog het haasje wanneer je de andere randvoorwaarden niet goed hebt geregeld zoals zo vaak te zien is in de media.

[Reactie gewijzigd door Bor op 22 juli 2024 16:28]

[bytemaster460]

In principe heb je gelijk, maar bij die policy om het wachtwoord te wijzigen gaat men ervan uit dat je nooit kunt weten of iemand je wachtwoord heeft. Misbruik van een wachtwoord hoeft geen directe gevolgen te hebben. Het kan jarenlang op stille wijze misbruikt worden, bijv. stelen het van bedrijfsgeheimen. Daarom houden veel bedrijven eraan vast om wachtwoorden te wijzigen.

[TimVdE]

Je wachtwoord frequent wijzigen, is helemaal niet nodig. Zolang het niet compromised is, ben je veilig. Als het compromised is, is het toch te laat. Je wachtwoord frequent wijzigen (als je geen password manager gebruikt) speelt over het algemeen minder sterke wachtwoorden in de hand, omdat je om de zoveel tijd een nieuw wachtwoord moet onthouden.

[Sfynx]

Bovendien zou ik een dagtaak eraan hebben gezien de hoeveelheid wachtwoorden die ik heb, ik heb wel wat beters te doen Ze verlaten mijn password manager toch nooit behalve voor het automatisch invullen op de website in kwestie.
Ik verander een wachtwoord alleen als deze compromised is, of als ik daar ook maar het kleinste vermoeden toe heb, en dat gebeurt eigenlijk alleen als een site die ik gebruik in het nieuws komt vanwege een hack. Dan is het gewoon voorzorg en ook zo gepiept.

[Reactie gewijzigd door Sfynx op 22 juli 2024 16:28]

[Douweegbertje]

Ik zie veel reacties die gaan over het wachtwoord gebruik en de sterkte hiervan. Los daarvan is het ook gewoon niet 'ok' als je 10k requests mag afvuren zonder dat dit gevolgen heeft. Hier zit dus verder iets fout; signalering en monitoring.
Dat hoeft niet altijd op applicatieniveau te gebeuren.

Mijn ervaring is:

- Heb je een Nederlandse website met een Nederlandse doelgroep: blokkeer alle exotische landen by default. Het is gewoon bad behaviour 100%. Even een screenshot van een cluster: https://monosnap.com/file/cadXyoGgCmO3TvFJXpI6rqH47yS2a6.png
- Ratelimit (fail2ban / mod_evasive) ; te veel requests = temp ban. Gaat dat door -> perm ban

Goed, uiteraard heb je dan nog proxies maar dan gaat het vaak om een vrij specifieke attack als iemand zoveel moeite erin wilt stoppen. Dan is het gewoon zaak om het aan de 'applicatie' kant op te vangen;

- 2 factor..
- ratelimit op het account zelf (dit is echter heel vervelend voor de legitieme gebruiker!, iemand kan dus geblokkeerd worden door een derde)
- Geef geen informatie weg over username/email: "fout wachtwoord voor dit e-mail adres" of "dit e-mail adres bestaat niet"

Het zit hem dus in: server + applicatie + user. Als je niet -alles- aanpakt blijf je een weaklink behouden.

[Blaise]

Heb je een Nederlandse website met een Nederlandse doelgroep: blokkeer alle exotische landen by default. Het is gewoon bad behaviour 100%.

Je hebt vast gelijk dat het meeste exotische verkeer niet legitiem is, maar om dan gelijk alles te blokkeren gaat wel erg ver. Dan blokkeer je ook Nederlandse expats, vakantiegangers en mensen op zakenreis.

Bovendien verandert dit niks aan de veiligheid van de website, enkel de bereikbaarheid. Ik denk dat je beter je beveiliging op orde kan hebben en geautomatiseerd buitenlandse IPs kan blokkeren die verdacht of spammerig gedrag vertonen.

[Douweegbertje]

Ja, je zal dus inderdaad 0.001% legitiem tegenhouden. Dat is prima te onderbouwen als je hierdoor 20-30% 'hack' verkeer kan tegenhouden. Het doet niets af tegen de veiligheid 'direct' maar wel indirect. Hierdoor heb je domweg een stabielere website die veel minder wordt aangevallen. Ik gaf ook niet voor niets aan dat je meerdere zaken moest doen (server + applicatie + user).

Over het algemeen blokkeer ik bepaalde subnets uit Rusland, Oekraïne, Korea, Japan, China. Dat is keer op keer non-legitiem verkeer, botnets en ga zo maar door. Noem dit maar pro-actief. Daarnaast monitor ik gewoon nog op het rest verkeer en die worden per IP gebanned en gedeelt over de rest van de cluster.

Mijn ervaring is dat 40% van het verkeer niet legitiem is (ook non http/s meegenomen). Ik vind het derhalve ook verstandig om hier pro-actief al op te reageren.

[NullCrayfish]

Ik ben al een tijdje op weg om voornamelijk via twitter mijn beklag te doen bij bedrijven over slechte password policies. Het grootste bezwaar, welke ik beangstigend vaak tegenkom, is de maximumlengte.
Zo heeft de makro maximaal 30 karakters, de ING maximaal 32 karakters, Kiwi electronics maximaal 20! karakters, bol.com maximaal 32 karakters.
Sommigen kwalijker dan andere natuurlijk, maar het is me werkelijk een raadsel waarom je uberhaubt een maximum zou stellen.
En dan heb je ook nog de talloze gevallen waarbij er een beperking op de te gebruiken karakters gelegd word zoals geen speciale tekens behalve ! @ # $ en %...

Ik word er droevig van.

[TimVdE]

Je wil waarschijnlijk wel *een* maximum, omdat password hashes redelijk traag zijn, en je wil niet dat iemand megabytes aan data instuurt als wachtwoord. Mijn norm is een maximumlengte van 256 tekens. Ik moet nog de eerste persoon tegenkomen die daar een probleem mee heeft

[Blokker_1999]

256 is dan ook vrij ruim. Maar wanneer populaire wachtwoordmanagers al snel tot 100 karakters gaan dan moet je dat imho ook ondersteunen. En als iemand graag 512 karakters gebruikt, waarom niet? Het is niet alsof je zo veel gebruikers gaat hebben? Een arbitraire limiet heeft ook niet veel zin.

[TimVdE]

Elke limiet kun je arbitrair noemen, maar je moet er wel één hebben, of je bent mogelijk kwetsbaar voor een DoS-aanval. Dit is het eerste artikel dat ik vind op DDG, en ik zie dat Django 4k gebruikt als limiet. Ik zal het onthouden voor in de toekomst, maar zoals ik zei, ik heb nog nooit iemand over 256b horen klagen

[.oisyn]

Het gaat er niet om dat men het in de praktijk gebruikt, het gaat erom dat geen maximum stellen voor een DoS attack vector zorgt.

[NullCrayfish]

Tja, dan heb je nog eens een leuke toepassing voor een mooie preloader
Ik hanteer meestal een maximum in de vorm van de maximum post size of de maximum execution time.

[Stoelpoot]

Je maximum kan je op een request zetten. Blokkeer requests boven 1KB, behalve naar file-upload URL's.

[celshof]

Sommigen kwalijker dan andere natuurlijk, maar het is me werkelijk een raadsel waarom je uberhaubt een maximum zou stellen.

Wellicht niemand die weet hoe ze de database fatsoenlijk kunnen aanpassen om de velden groter te maken? En dat zonder dat de oude informatie verloren gaat.

Of, ze hebben de mensen wel, maar bij elke sprint belandt het wachtwoord veldje ergens onderaan omdat andere zaken hogere prioriteit hebben.

[TimVdE]

Ehm, je wachtwoord zou gehasht moeten zijn tot een vaste lengte (bv. bcrypt is 184 bit). Een langer wachtwoord betekent niet dat de hash langer is, en je zou dus geen langer wachtwoordveld moeten hebben.

[Jay-v]

Sommige bedrijven slaan je wachtwoord nog steeds in plaintext op en versturen deze prima per email zodra je je wachtwoord vergeten bent....

Edit: devs doen onterecht aannames. Bijvoorbeeld dat meer dan 20 karakters bij MD5 geen zin hebben vanwege mogelijke collisions

[Reactie gewijzigd door Jay-v op 22 juli 2024 16:28]

[.oisyn]

20 karakters kan er op wijzen dat men MD5 gebruikt, langere wachtwoorden hebben dan geen zin vanwege hash collisions.

Dit slaat nergens op . Wat maken hash collisions nou uit bij wachtwoorden? Who cares dat er ook een 18-teken reeks bestaat voor jouw 32-teken wachtwoord met dezelfde hash? Geen zin om de limiet dan ook maar op 20 te zetten.

[Jay-v]

[...]

Dit slaat nergens op . Wat maken hash collisions nou uit bij wachtwoorden? Who cares dat er ook een 18-teken reeks bestaat voor jouw 32-teken wachtwoord met dezelfde hash? Geen zin om de limiet dan ook maar op 20 te zetten.

Natuurlijk slaat een dergelijke implementatie nergens op, maar ze bestaan wel en dat is juist mijn punt. Er is ook geen argument om de limiet op 8 of op 30 te zetten wanner je de wachtwoorden gewoon netjes hashed (met salt!), maar het gebeurt dus wel.

[.oisyn]

Heb je bewijs dat er een limiet is omdat meer dan 20 tekens nutteloos zou zijn?

[Jay-v]

Nee, dat is er niet. Wat ik bedoel is dat devs onterecht de aanname doen.

Omdat:
De character opties (azAZ09+specials) (94 opties) ^ length (20) > 2^128 (MD5 = 16 bytes / 128bit)

Omdat x > y gaat men ervan uit dat alle mogelijke hashes al gebruikt zijn, dat hoeft echter niet perse zo te zijn (collisions zouden al eerder kunnen ontstaan).

En zelfs al zou dat zo zijn heb je enorm veel opslag nodig om alle mogelijkheden op te slaan in een (rainbow) tabel.

Veel ontwikkelaars (en beheerders) hebben geen kaas gegeten van deze materie. Indien een bedrijf niet over deze capaciteit beschikt zou beter zijn om een externe partij dit te laten doen.

[Reactie gewijzigd door Jay-v op 22 juli 2024 16:28]

[.oisyn]

Ik snap de theorie erachter heel goed. Mijn punt is meer dat ik het idee heb dat jij hier een aanname maakt dat devs die keuze maken om de door jou gesuggereerde reden (meer heeft geen nut bij een hash van 128 bits), terwijl in de praktijk het maximum helemaal niet om die reden op 20 wordt gezet, maar gewoon omdat dat wel genoeg zou zijn. Ik denk zelfs dat veel devs helemaal niet in staat zijn zelf die berekening te doen.

Dat een maximum van 20 erop kan wijzen dat er MD5 wordt gebruikt vind ik daarom nogal een boude stelling, vandaar dat ik vroeg of je daar bewijs of bronnen voor had.

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

[mocean]

Ik snap het probleem van de lengte ook niet. Ik mag toch hopen dat ze een hash opslaan en die verander niet qua lengte gewoonlijk, bij een langer password.

[JAVE]

Die 20! van Kiwi is best veel (1*2*3*4*5...)

[90710]

Ook Tweakers is er gevoelig voor heb ik al ontdekt.

[koku]

Waar dan precies? Als het goed is krijg je een Captcha te zien na een X aantal foute pogingen...

[90710]

Ah ik had net 3x getest, de Recaptcha komt na 5x Al is het niet perse een waterdichte oplossing

[cedal]

Wat fijn dat een partij als de Consumentenbond er even een punt van maakt. Het is namelijk een grote ergernis van iedereen zonder passwordmanager.

De meesten van ons weten allang dat lengte belangrijker is dan complexiteit, en ik erger me persoonlijk regelmatig aan gekke eisen. Aan de andere kant, verschillende eisen forceert verschillende wachtwoorden bij websites, maar daar hebben verstandige mensen een wachtwoordmanager voor.

[Kiswum]

Het is goed dat de Consumentbond dit heeft getest en zichzelf ook benoemd als een site met een beperkt wachtwoordbeleid. Nog beter is dat ze het hebben verbeterd. Dit soort testen mogen wel vaker worden uitgevoerd.

[WittiW]

Als je met brute force toegang wil, weet je niet of gebruikers alleen letters gebruiken of meer. Daar maakt het dus niet voor uit.

De lengte bepaald meer het aantal mogelijkheden. Dus doe een lang wachtwoord wat je kan onthouden.

In algemene zin maakt het mij weinig uit als ik en nauwelijks persoonlijke gegevens heb en zeker geen betalingsgegevens. Een site als tweakers? Succes met mijn account als je die weet te hacken

[mduijm]

En thuisbezorgd.nl stuurt nog steeds de wachtwoorden in een mailtje naar je toe

Security en websites is nog steeds een drama.