image

Juridische vraag: Handelen instanties die wachtwoorden van maximaal 12 karakters accepteren wel overeenkomstig de AVG?

woensdag 10 juli 2019, 10:01 door Arnoud Engelfriet, 37 reacties

Heb jij een interessante vraag op het snijvlak van privacy, cybersecurity en recht? Wil je weten wat onder de AVG nu wel en niet is toegestaan of zit je met andere gerelateerde dilemma's? Stuur je vraag naar juridischevraag@security.nl. Elke week geeft ict-jurist Arnoud Engelfriet in deze rubriek antwoord.

Vraag: Ik kom nog geregeld bedrijven en verenigingen tegen die wachtwoorden van maximaal 12 karakters accepteren. Als je ze hierop aanspreekt zeggen ze dat dit voldoende is of het later zal worden aangepast. Maar de AVG verplicht dat er "passende technische én organisatorische maatregelen" worden genomen om een adequaat beveiligingsniveau te waarborgen. Twaalf karakters is tegenwoordige echt niet meer adequaat. Handelen de instanties die wachtwoorden van maximaal 12 karakters accepteren in strijd met de AVG?

Antwoord: Daar lijkt het wel op. Een goed wachtwoord is een van de belangrijkste technische beveiligingsmaatregelen die je kunt nemen. In de praktijk wordt vaak binnengedrongen met een geraden wachtwoord, dus hoe sterker je dat wachtwoord tegen gokken kunt maken, hoe beter. De AVG zegt zelf niet precies aan welke eisen een wachtwoord moet voldoen, alleen dus dat de maatregelen die je neemt "passend" moeten zijn gezien de risico's, de stand der techniek en andere relevante factoren. Kort gezegd: je moet kunnen verantwoorden waarom je de keuzes maakte die je maakte, en waarom het niet sterker hoefde dan het was.

In mijn ervaring wordt zelden echt nagedacht over wachtwoordbeleid, met name als het gaat om de lengte van wachtwoorden. Er is het nodige onderzoek gedaan naar bijvoorbeeld hoe vaak een wachtwoord gewijzigd moet worden (nooit, als het maar sterk is, zie deze voorbeelden) of hoe sterk ze moeten zijn (12 karakters is wel het minimum inderdaad) maar je ziet dat niet snel terug in bestaande implementaties van password-based access control. En dat is jammer.

Ik zou dus zelf geneigd zijn om te zeggen, wie een maximale lengte op wachtwoorden afdwingt zit fout onder de AVG, tenzij hij een heel goed verhaal heeft waarom het nódig is dat het wachtwoord niet langer is. Ik kan me dat verhaal niet voorstellen, maar goed, ik probeer een open mind te houden hierbij. "Onze software werkt nu eenmaal zo" of "Wij zijn nog nooit gehackt" is natuurlijk géén goed verhaal.

Arnoud Engelfriet is Ict-jurist, gespecialiseerd in internetrecht waar hij zich al sinds 1993 mee bezighoudt. Hij werkt als partner bij juridisch adviesbureau ICTRecht. Zijn site Ius mentis is één van de meest uitgebreide sites van Nederland over internetrecht, techniek en intellectueel eigendom. Hij schreef twee boeken, De wet op internet en Security: Deskundig en praktisch juridisch advies.

Reacties (37)
10-07-2019, 10:17 door PietdeVries - Bijgewerkt: 10-07-2019, 10:17
Ik vraag me af of je gebruikers moet verplichten een wachtwoord van tenminste 12 karakters te gebruiken...

Grofweg zijn er twee manieren om een wachtwoord te misbruiken:

1. Je kijkt mee over de schouder van een gebruiker en leest het wachtwoord mee (of snift).
2. Je hackt jezelf een weg de server in, steelt daar de wachtwoord tabel en probeert de hashes te kraken.

Ad 1: een gebruiker zal nooit een willekeurige string van 12 karakters kunnen onthouden. Het zal een woord met wat variaties zijn. Kan me niet voorstellen dat het meelezen van een woord van 12 karakters lastiger is dan een woord van 8.

Ad 2: dit lijkt me duidelijk het probleem van de eigenaar/admin van de server. Waarom dan de oplossing ervan bij de gebruiker leggen?

Fratsen als herhaaldelijk proberen in te loggen met een wachtwoord laat ik maar even buiten beschouwing. Ook dat is een issue van de admin, en niet iets waar je de gebruiker mee moet lastig vallen.

Lange wachtwoorden lossen vermoedelijk minder op dan dat ze aan last bezorgen. Het gebruiken van verschillende wachtwoorden bij verschillende sites - dat helpt. En twee-factor of one-time wachtwoorden ook...
10-07-2019, 10:50 door [Account Verwijderd]
Door PietdeVries: Ad 1: een gebruiker zal nooit een willekeurige string van 12 karakters kunnen onthouden.

Jawel hoor... Mijn langste onthouden wachtwoord is 34 karakters en ik ken er meer uit het hoofd.
10-07-2019, 11:15 door hw28
Niet alleen vanwege de AVG, maar in het algeheel voor security is het niet zinvol om de lengte van een wachtwoord te beperken.

Want een wachtzin als Ikvindd3AVGmaaronzin! is niet zo moeilijk te onthouden, lastig te raden, en nagenoeg onmogelijk te kraken
10-07-2019, 12:22 door Anoniem
Door herbert28: Niet alleen vanwege de AVG, maar in het algeheel voor security is het niet zinvol om de lengte van een wachtwoord te beperken.

Want een wachtzin als Ikvindd3AVGmaaronzin! is niet zo moeilijk te onthouden, lastig te raden, en nagenoeg onmogelijk te kraken
Zelfs als leek begrijp ik nog dat je een hash van een wachtwoord moet opslaan en niet het wachtwoord zelf. Dus de programmeur kan de lengte in de database volledig zelf bepalen. Er is dus sowieso ook geen technische reden waarom er een 12 karakter limiet zou moeten zijn.

Behalve als de software uit vorig millenium komt en nooit geupdate is.
10-07-2019, 12:31 door Anoniem
Ad 1: een gebruiker zal nooit een willekeurige string van 12 karakters kunnen onthouden. Het zal een woord met wat variaties zijn. Kan me niet voorstellen dat het meelezen van een woord van 12 karakters lastiger is dan een woord van 8.

Daarom zou iedereen een password manager moeten gebruiken. Waarom wachtwoorden onthouden, als er programma's zijn die dat veel beter kunnen. Mijn wachtwoorden zijn altijd 18 random chars + cijfers. En ik weet er niet een uit het hoofd. Alleen mijn master wachtwoord.

TheYOSH
10-07-2019, 12:36 door bguijt
Als een wachtwoord in lengte wordt beperkt is de kans groot dat het in plaintext wordt opgeslagen in de database (waarvan het veld dezelfde lengte heeft). Dat alleen al is een rode vlag waard.

Ik zie ook geen enkele andere reden waarom je de lengte zou willen beperken.
10-07-2019, 13:12 door Anoniem
Door bguijt: Als een wachtwoord in lengte wordt beperkt is de kans groot dat het in plaintext wordt opgeslagen in de database (waarvan het veld dezelfde lengte heeft). Dat alleen al is een rode vlag waard.

Ik zie ook geen enkele andere reden waarom je de lengte zou willen beperken.
Hoeft niet, sommige systemen hebben van oudsher een beperking in de lengte van het wachtwoord. Wanneer rechtstreeks op een AS400 of een mainframe wordt geauthentiseerd, speelt dit bijvoorbeeld.
10-07-2019, 13:15 door Anoniem
Door PietdeVries: Ik vraag me af of je gebruikers moet verplichten een wachtwoord van tenminste 12 karakters te gebruiken...

Grofweg zijn er twee manieren om een wachtwoord te misbruiken:

1. Je kijkt mee over de schouder van een gebruiker en leest het wachtwoord mee (of snift).
2. Je hackt jezelf een weg de server in, steelt daar de wachtwoord tabel en probeert de hashes te kraken.

Ad 1: een gebruiker zal nooit een willekeurige string van 12 karakters kunnen onthouden. Het zal een woord met wat variaties zijn. Kan me niet voorstellen dat het meelezen van een woord van 12 karakters lastiger is dan een woord van 8.

Ad 2: dit lijkt me duidelijk het probleem van de eigenaar/admin van de server. Waarom dan de oplossing ervan bij de gebruiker leggen?

Fratsen als herhaaldelijk proberen in te loggen met een wachtwoord laat ik maar even buiten beschouwing. Ook dat is een issue van de admin, en niet iets waar je de gebruiker mee moet lastig vallen.

Lange wachtwoorden lossen vermoedelijk minder op dan dat ze aan last bezorgen. Het gebruiken van verschillende wachtwoorden bij verschillende sites - dat helpt. En twee-factor of one-time wachtwoorden ook...
Toch nog maar even jezelf blijven afvragen.
Mbt. 1) 12 is nog steeds kort, denk eerder aan 16. En als het schijnbaar willekeurige karakters zijn(dus niet een herkenbare zin) wordt het steeds moeilijker om die wachtwoorden mee te lezen
Mbt. 2) dat is een bijzondere benadering: we weten dat overal systemen gekraakt worden, zelfs bij hi-profile bedrijven, waar wachwoorden goed versleuteld (gehashed) opgeslagen ziijn. Als je dat weet ben je mijns inziens onverantwordt bezig als je een wachtwoord als "Welkom" gebruikt "want het is de verantwoordelijkheid van de eigenaar/admin". Volgens mij net zo iets als je auto niet op slot doen in een parkeergarage "wan t het is de verantwoordelijkheid van de eigenaar".

Let op: onbekende wachtwoorden van 8 karakters waar de hash van bekend is kunnen binnen minuten via brute force teruggebracht worden. En door gebruik van een woordenlijst kunnen via brute force ook "wachtzinnen" (een combinatie van woorden) al heel snel teruggehaald worden, ook al zijn die langer dan 12 karakters!
10-07-2019, 13:18 door Anoniem
Door bguijt: Als een wachtwoord in lengte wordt beperkt is de kans groot dat het in plaintext wordt opgeslagen in de database (waarvan het veld dezelfde lengte heeft). Dat alleen al is een rode vlag waard.
Bingo! De spijker op z'n kop.
Een Hash (opslaan zoals het hoort) heeft altijd dezelfde lengte, onafhankelijk van hoe lang het oorspronkelijke wachtwoord is, dus dan maakt de lengte van het wachtwoord niet uit.
Ik zie ook geen enkele andere reden waarom je de lengte zou willen beperken.
Tja, tot voor kort was 16 karakters wel de maximale lengte van Azure AD, ik weet ook niet waarom...
Maar gelukkig is dat nu aangepast
10-07-2019, 14:08 door Anoniem
Door PietdeVries:2. Je hackt jezelf een weg de server in, steelt daar de wachtwoord tabel en probeert de hashes te kraken.

Als je de link naar de 12 tekens had gevolgd, had je kunnen lezen dat de meeste aanvallen plaatsvinden middels wachtwoorden die bekend zijn geraakt door inbraken bij grote organisaties als LinkedIn.

Peter
10-07-2019, 16:53 door _R0N_
Een beperkte lengte van een wachtwoord duidt er op dat het wachtwoord niet gehashed wordt. Om ene hash te genereren maakt de lengte van het wachtwoord niet uit, al is het pagina vullend. Het limiet kan dus enkel in de grootte van het database veld zitten.

Een wachtwoord met een maximum aan karakters zal dus zelden voldoen aan de regels van de AVG/GDPR
10-07-2019, 17:32 door Anoniem
Door _R0N_: Een beperkte lengte van een wachtwoord duidt er op dat het wachtwoord niet gehashed wordt. Om ene hash te genereren maakt de lengte van het wachtwoord niet uit, al is het pagina vullend. Het limiet kan dus enkel in de grootte van het database veld zitten.
Dat is niet per se zo. Iemand noemde al authenticeren tegen een mainframe-backend, een platform waar ongeveer alles vaste lengtes heeft. Het is mogelijk dat de wachtwoorden daar op zich goed gehasht worden maar dat de interface ernaartoe maar een beperkt aantal tekens toestaat. Hoe knullig dat ook is, het kan. Ik heb dergelijke interfaces meegemaakt. Niet iets wat ik vandaag de dag nog acceptabel zou vinden, overigens.

De lengte van het wachtwoord is trouwens niet de enige factor. Denk maar aan pinpassen, vier cijfers slechts. Daar wordt de kans op succesvol kraken aanzienlijk gereduceerd door de pas na drie mislukte pogingen te blokkeren.
10-07-2019, 18:23 door Anoniem
Door _R0N_: Een beperkte lengte van een wachtwoord duidt er op dat het wachtwoord niet gehashed wordt. Om ene hash te genereren maakt de lengte van het wachtwoord niet uit, al is het pagina vullend. Het limiet kan dus enkel in de grootte van het database veld zitten.

Een wachtwoord met een maximum aan karakters zal dus zelden voldoen aan de regels van de AVG/GDPR

Wat een onzin, die conclusie is helemaal niet te trekken.
Het enige correcte is dat voor een hash functie de input lengte helemaal niet uitmaakt .

Maar als je ooit code - en met name aanbevelingen voor robuuste code - gezien hebt weet je dat op allerlei plekken buffers/api calls/library functies zitten met een vaste lengte . Dynamisch alloceren van geheugen introduceert een heel extra klasse van werk om dat goed te doen - en eventuele errors af te vangen.

Als je met vaste lengte buffers werkt - en die lengte controleert bij invoer - vermijd je een heel scala van problemen.
Natuurlijk - soms kan/moet/ iets werken voor parameters met willekeurige, of MAXINT lengte. Maar parameters met vaste en beperkte lengte maken code wel echt veel simpeler.

Hoe groot dan zo'n buffer moet zijn is de vraag, maar of de maximale lengte nou 12, 16, 32, 64, 255 is zegt niks of er aan het eind van de rit wel of geen hash functie zit.
Ook al kan die hash prima 2^32 bytes input aan.
10-07-2019, 18:45 door Anoniem
Door PietdeVries: Ik vraag me af of je gebruikers moet verplichten een wachtwoord van tenminste 12 karakters te gebruiken...

Grofweg zijn er twee manieren om een wachtwoord te misbruiken:

1. Je kijkt mee over de schouder van een gebruiker en leest het wachtwoord mee (of snift).
2. Je hackt jezelf een weg de server in, steelt daar de wachtwoord tabel en probeert de hashes te kraken.

Ad 1: een gebruiker zal nooit een willekeurige string van 12 karakters kunnen onthouden. Het zal een woord met wat variaties zijn. Kan me niet voorstellen dat het meelezen van een woord van 12 karakters lastiger is dan een woord van 8.

Ad 2: dit lijkt me duidelijk het probleem van de eigenaar/admin van de server. Waarom dan de oplossing ervan bij de gebruiker leggen?

Fratsen als herhaaldelijk proberen in te loggen met een wachtwoord laat ik maar even buiten beschouwing. Ook dat is een issue van de admin, en niet iets waar je de gebruiker mee moet lastig vallen.

Lange wachtwoorden lossen vermoedelijk minder op dan dat ze aan last bezorgen. Het gebruiken van verschillende wachtwoorden bij verschillende sites - dat helpt. En twee-factor of one-time wachtwoorden ook...

Dat zijn allemaal wel terechte punten, en passwords hebben op veel vlakken een beperking.

Ik wil wel opmerken dat 'gewoon raden' (Welkom, qwerty,123456) toch een risico is als er geen minimale eisen gesteld worden aan het wachtwoord - qua lengte en complexiteit.
Als de 'inlog-api' dan ook nog redelijk breed benaderbaar is zul je dat probleem toch moeten afvangen.

Ook al nemen mensen een schema , met enige minimale lengte wordt dan de zoekruimte te groot om 'snel' geluk te hebben. Als dan het maximale aantal pogingen voldoende beperkt kan worden op de server zijn ook die mensen nog redelijk beschermd.

Het klopt dat random wachtwoorden van voldoende lengte gewoon niet te onthouden zijn. Maar dat wil niet zeggen dat als kortere wachtwoorden mogelijk zijn die wel "goed" gekozen worden.

Voor je punt 2 - inderdaad. Maar mensen lijken aan te nemen dat bij een hack van de server waarbij de hashes gestolen blijken te zijn ook altijd _alleen maar de hashes gestolen zijn_ .
En dat je dan rustig achterover mag leunen als je een 128 puur willekeurige letters als password gekozen had.
Weinigen lijken zich af te vragen of de hacker die de hashes meenam niet ook een rootkit kan installeren die de _invoer_ van de hashes bekeek en doorstuurde.
Dus ja, liever wel dan geen hashes, en liever lange random passwords dan korte voorspelbare, maar desondanks moet je imo bij een server hack eigenlijk dat account/password als 'breached' beschouwen.
10-07-2019, 19:04 door Anoniem
Als je meer karakters kan invoeren wil dit niet perse beteken dat er ook meer characters worden opgeslagen. Sommige implementaties gebruiken alleen de eerste x characters en negeren de rest.
10-07-2019, 19:23 door Anoniem
Door _R0N_: Een beperkte lengte van een wachtwoord duidt er op dat het wachtwoord niet gehashed wordt. Om ene hash te genereren maakt de lengte van het wachtwoord niet uit, al is het pagina vullend. Het limiet kan dus enkel in de grootte van het database veld zitten.

Een wachtwoord met een maximum aan karakters zal dus zelden voldoen aan de regels van de AVG/GDPR

Idd. Dit is een goed stuk dat het in detail uitlegd.
https://nakedsecurity.sophos.com/2013/11/20/serious-security-how-to-store-your-users-passwords-safely/
10-07-2019, 21:40 door Anoniem
Door Anoniem: Als je met vaste lengte buffers werkt - en die lengte controleert bij invoer - vermijd je een heel scala van problemen. Maar parameters met vaste en beperkte lengte maken code wel echt veel simpeler.
Dat kan wel zijn, maar veiliger wordt het er ook niet op. Je zegt eigenljk dat de programmeur niet meer hoeft na te denken en dat is nadelig voor de veiligheid.
Hoe groot dan zo'n buffer moet zijn is de vraag, maar of de maximale lengte nou 12, 16, 32, 64, 255 is zegt niks of er aan het eind van de rit wel of geen hash functie zit.
Hoe korter de input, hoe sneller je met brute-forcen dat wachtwoord hebt en hoe kleiner de rainbowtable om selfs binnen een seconde van de hash het bijpassende wachtwoord te vinden.

Kortom als je website niet met lange wachtwoorden in het invoerveld overweg kan, hoort die niet aan internet gekoppeld te zijn. Dan is het of prutswerk of zwaar outdated spul (beide niet goed naar huidige maatstaven).
10-07-2019, 21:46 door Anoniem
Door Anoniem: Als je meer karakters kan invoeren wil dit niet perse beteken dat er ook meer characters worden opgeslagen. Sommige implementaties gebruiken alleen de eerste x characters en negeren de rest.
Dat zijn dan ondoordachte bagger implementaties, als je naar de veiligheid kijkt. Niet 'stand der techniek', als je uitgaat van de huidige inzichten. Misschien dat dit dertig jaar geleden nog kon, maar nu zeker niet meer.
10-07-2019, 22:27 door Anoniem
Even de advocaat spelen:

12 tekens is genoeg.
Mits:
- het ingevulde ww niet voorkomt in de lijsten van haveibeenpwnd (check bij elke inlog)
- je maar een paar pogingen hebt om het in te voeren. Daarna account vergrendeld. (Brute forcing dus onmogelijk)
- het mag bestaan uit alle leesbare ascii tekens (zo irritant als je niet je eigen ding kunt maken ervan)

15 tekens is beter, want hoger dan 14 tekens (2x7) van LanMan ;)
32 momenteel gewoon onkraakbaar
64 prima max., hashes zijn vaak toch niet langer.
3Mb aan data: pure onzin.
11-07-2019, 09:47 door Anoniem
Handelen de instanties die wachtwoorden van maximaal 12 karakters accepteren in strijd met de AVG?

Gaat het uiteindelijk niet om veel meer dan enkel de lengte van wachtwoorden. Zoals controls met betrekking tot account lockout, password complexity, en veel meer van dat soort zaken ? De combinatie van maatregelen zegt meer over de veiligheid, dan enkel bijvoorbeeld de lengte van het wachtwoord. Moet natuurlijk ook niet te kort zijn.
11-07-2019, 09:50 door Anoniem
Instanties die hun verantwoordelijkheid nemen zorgen dat je naast je wachtwoord ook een one-time-token moet gebruiken. Zodat gelekte credentials veel moeilijker te misbruiken zijn, naast genoemde password controls. Met multi factor authenticatie zijn een hoop problemen te voorkomen. Dit kan met hard- of softtoken; softtokens zijn relatief goedkoop te implementeren (app op je telefoon, die je one-time-password genereert).

Instanties die single factor authenticatie gebruiken, zouden zich anno 2019 moeten schamen. Ongeacht de vraag of het wel/niet mag van de AVG.
11-07-2019, 10:30 door Anoniem
De meeste aanvallen op passwords vinden plaats via password stealers, phishing en dergelijke. En in veel mindere mate door het kraken van passwords. In die gevallen maakt je password length, en password complexity weinig meer uit.
11-07-2019, 10:50 door Anoniem
Door Anoniem:
Door _R0N_: Een beperkte lengte van een wachtwoord duidt er op dat het wachtwoord niet gehashed wordt. Om ene hash te genereren maakt de lengte van het wachtwoord niet uit, al is het pagina vullend. Het limiet kan dus enkel in de grootte van het database veld zitten.

Een wachtwoord met een maximum aan karakters zal dus zelden voldoen aan de regels van de AVG/GDPR

Wat een onzin, die conclusie is helemaal niet te trekken.
Het enige correcte is dat voor een hash functie de input lengte helemaal niet uitmaakt .

Dus een wachtwoord van 1 teken is ook goed?
Want de hash maakt er toch een vaste lengte van?

Peter
11-07-2019, 11:46 door Anoniem
Een lang wachtwoord betekent dat mensen eerder een typefout maken en vervolgens de helpdesk gaan bellen. Zo'n helpdesk kost geld. Daarom willlen bedrijven de complexteit van wachtwoorden enigszins beteugelen. En dat is ook de reden waarom Microsoft bezig is om wachtwoorden uit te bannen zolang de oplossing maar even veilig of zelfs beter is.
11-07-2019, 13:10 door Anoniem
Gek genoeg lees ik geen enkele reactie met betrekking tot de Baseline Informatiebeveiliging Overheid (BIO), die er volgend jaar aankomt.

Deze zegt het volgende over passwordbeleid:
- minimaal 8 posities en complex van samenstelling
- Vanaf een wachtwoordlengte van 20 vervalt de complexiteitseis

En het wordt nog gekker:
- Als er geen MFA mogelijk is, is een wachtwoordreset eens per 6 maanden benodigd.

Let wel: de BIO is een baseline, ik zou zelf nooit deze keuze maken.

Maximaal 12 karakters kan misschien wel tegen de AVG zijn, maar ik lees bijvoorbeeld niet dat er ook MFA afgedwongen wordt. Als dat het geval is, vind ik 12 niet direct een probleem. Dit soort dingen zijn altijd contextgevoelig.

Verder ben ik het wel eens met Arnoud dat een beleid van maximaal 12 erg beperkt is, maar ik kom in de praktijk ook bedrijven tegen die een maximale (!) lengte van 8 karakters hebben (aangevuld met MFA).
11-07-2019, 13:23 door Anoniem
Om op de oorspronkelijke vraag te antwoorden :

Nee, paswoorden van 12, 10 of zelfs 8 karakters zijn in NIET in noodzakelijk strijd met de AVG.

Er zijn 3 elementen die in rekening gebracht moeten worden om te evalueren of het adequaat (= risk based) is:

* Welk type van gegevens worden er beveiligd en wat is de impact als ze gestolen worden?
- Enkel je email adres en enkele comments op een website, of eerder zeer persoonlijke medische gegevens?
* Is het paswoord de enige "factor" of heb je ook nog een PIN, Kaart of GSM die een extra garantie geven ?
* Op welke (technische) manier wordt er met het passwoord omgegaan? (meestal onzichtbaar voor eindgebruikers)
- Wordt het paswoord in leesbare tekst doorgestuurd en opgeslagen (zeer onveilig) of stuur je een "hash" op die opgeslagen wordt en later als referentie gebruikt wordt. Door de hash zal de website of toepassing je paswoord (van andere) niet onmiddellijk kennen en kunnen misbruiken maar wel het resultaat kunnen vergelijken.
11-07-2019, 13:35 door Anoniem
Soms worden niet alle tekens geaccepteerd en dat is stuitend. Een goede validatie van een wachtwoord of -zin mag bij aanmaak of authenticatie geen onnodige beperkingen in die zin opleggen. Waarom: omdat er geen geldige reden voor is en bij gebreke daarvan is dat dus ongerechtvaardigd, zo niet onrechtmatig.
.
11-07-2019, 14:35 door Anoniem
Door Anoniem:
Door Anoniem:
Door _R0N_: Een beperkte lengte van een wachtwoord duidt er op dat het wachtwoord niet gehashed wordt. Om ene hash te genereren maakt de lengte van het wachtwoord niet uit, al is het pagina vullend. Het limiet kan dus enkel in de grootte van het database veld zitten.

Een wachtwoord met een maximum aan karakters zal dus zelden voldoen aan de regels van de AVG/GDPR

Wat een onzin, die conclusie is helemaal niet te trekken.
Het enige correcte is dat voor een hash functie de input lengte helemaal niet uitmaakt .

Dus een wachtwoord van 1 teken is ook goed?
Want de hash maakt er toch een vaste lengte van?

Peter

Is dat nu een reactie op _RON_ met mij erbij gequote, of een reactie op mij - met alle nadere duiding weggeknipt ?
(Ik denk dat jij iemand bent voor wie onderstaande bekend is, maar toch ...)

Inderdaad zal een hash ook een input van lengte 1 accepteren en een vaste lengte output geven.
(aimgh is bv de SHA-familie zelfs gedefinieerd op input lengtes in _bits_, en doet padding tot een geheel aantal blokken)

Gewoon - uit wat de password-invoer-API aan lengte beperking (of karakterset-beperking) oplegt kun je geen conclusie trekken of aan het eind van de invoer-tot-opslag keten wel of geen hash functie gebruikt wordt.

Je kunt er iets over afleiden welke maximale password veiligheid gehaald kan worden, en of het maximale 'redement' van een eventuele hash gehaald kan worden.
Maar de conclusie 'invoer max 12 DUS wordt plaintext opgeslagen' die enkele posters maakten kun je niet trekken.
Invoer max 1 (of bv Max 4 digits) naar de conclusie "zeer zwakke bestendigheid tegen brute-force" kun je wel trekken.
Als je een threat-model hebt waarin brute-force geen rol speelt (bankpas-pincode) is dat een bruikbare keuze.

Als je wel rekening moet houden met een hack waarbij opgeslagen hashes lekken is een max 12 lengte invoer nogal krap.
11-07-2019, 15:01 door Anoniem
12 tekens is genoeg.
Mits:
- het ingevulde ww niet voorkomt in de lijsten van haveibeenpwnd (check bij elke inlog)
- je maar een paar pogingen hebt om het in te voeren. Daarna account vergrendeld. (Brute forcing dus onmogelijk)
- het mag bestaan uit alle leesbare ascii tekens (zo irritant als je niet je eigen ding kunt maken ervan)

En wat nou indien je password wordt gestolen middels phishing, key logger, credential stealer ? Dan maakt geen van bovenstaande zaken ook maar iets uit. Staar je niet blind op password cracking, en denk ook aan andere scenario's.

Waarom: omdat er geen geldige reden voor is en bij gebreke daarvan is dat dus ongerechtvaardigd, zo niet onrechtmatig.

Heeft niets te maken met onrechtmatig. Tenzij je aan kunt tonen dat er sprake is van het overtreden van wettelijke regels.
11-07-2019, 15:03 door Anoniem
Een lang wachtwoord betekent dat mensen eerder een typefout maken en vervolgens de helpdesk gaan bellen. Zo'n helpdesk kost geld. Daarom willlen bedrijven de complexteit van wachtwoorden enigszins beteugelen. En dat is ook de reden waarom Microsoft bezig is om wachtwoorden uit te bannen zolang de oplossing maar even veilig of zelfs beter is.

1) Een helpdesk behoort je password niet te kunnen zien
2) Anno 2019 moet je zonder helpdesk je password ook kunnen resetten

Gewoon beetje nadenken bij de architectuur, om dergelijke belletjes tot een minimum te beperken.
11-07-2019, 15:50 door Anoniem
Door Anoniem:
Door Anoniem:
Door _R0N_: Een beperkte lengte van een wachtwoord duidt er op dat het wachtwoord niet gehashed wordt. Om ene hash te genereren maakt de lengte van het wachtwoord niet uit, al is het pagina vullend. Het limiet kan dus enkel in de grootte van het database veld zitten.

Een wachtwoord met een maximum aan karakters zal dus zelden voldoen aan de regels van de AVG/GDPR

Wat een onzin, die conclusie is helemaal niet te trekken.
Het enige correcte is dat voor een hash functie de input lengte helemaal niet uitmaakt .

Dus een wachtwoord van 1 teken is ook goed?
Want de hash maakt er toch een vaste lengte van?

Peter
Zucht... Je begrijpt het probleem niet. Voor een hash functie maakt de lengte van het bericht niet uit: er komt altijd een hash van een bepaalde lengte uit (bv. 128 bit). Die hash berekening is niet omkeerbaar, dus aan de hash kan je niet zien of het origineel 1 of 1 miljoen karakters was.
Echter, heb je eenmaal de hash dan kan je "brute forcen", ofwel alle mogelijke waarden aan de functie geven en kijken of het resultaat hetzelfde is. En met een wachtwoord van 1 karakter ben je er dan wel erg snel.
Hou even in gedachten dat een beetje Brute force systeem 50 miljoen pogingen per seconde kan doen...
11-07-2019, 16:12 door Anoniem
Door Anoniem: Even de advocaat spelen:

12 tekens is genoeg.
Mits:
- het ingevulde ww niet voorkomt in de lijsten van haveibeenpwnd (check bij elke inlog)
- je maar een paar pogingen hebt om het in te voeren. Daarna account vergrendeld. (Brute forcing dus onmogelijk)
- het mag bestaan uit alle leesbare ascii tekens (zo irritant als je niet je eigen ding kunt maken ervan)

15 tekens is beter, want hoger dan 14 tekens (2x7) van LanMan ;)
32 momenteel gewoon onkraakbaar
64 prima max., hashes zijn vaak toch niet langer.
3Mb aan data: pure onzin.
"12 tekens is genoeg mits..." Dat hangt van de context af: gaat het om het bestellen van nieuwe vuilniszakken, of om medische geheimen?

"32 momenteel gfewoon onkraakbaar" Weer afhankelijk: als je een wachtzin maakt met gewone nederlandse woorden, dan is 35 karakters prima kraakbaar. Als het random karakters zijn wordt het erg moeilijk

"64 prima max., hashes zijn vaak toch niet langer. " Kijk maar eens op https://en.wikipedia.org/wiki/List_of_hash_functions bij "Unkeyed cryptographic hash functions", dan zie je dat hash functies gemiddeld 128 of 256 bit zijn. Bij een entropie van 6,5 bits per karakter en 128 bit zouden zo'n 20 karakters al voldoende zijn om alle hash waarden op te leveren, bij een hash resultaat van 256 zijn plm. 40 karakters nodig. Een random gegenereerd wachtwoord van 20 of 40 karakters is dan al genoeg.
Echter.... het gaat om mensen die iets moeten kunnen onthouden, dus geen random serie karakters, maar iets waar een mens betekenis aan kan koppelen zodat hij dat kan onthouden. Dan zijn langere dan 40 best handig: een lange logische wachtzin is beter te onthouden dan een random serie karakters.
waarden
12-07-2019, 09:52 door Anoniem
Voor wat betreft de complexiteit van wachtwoorden en hoe dit te benaderen vanuit een gebruiksvriendelijk perspectief heeft Dan Kaminsky hier op een van zijn defcon talks een aantal slides gewijdt (storybits heet het geloof ik).
Willekeurige woorden door de gebruiker te kiezen, maar met intelligente herkenning. Voorbeeld van de passphrase:
Ik moet de hond uitlaten om 11 uur
intelligente passphrase herkenning, dit wordt ook goedgekeurd:
wij moeten de hond uitlaten om 11 uur
ik ga de hond uitlaten om 11 uur
ik moet de hond utilaten om 1 uur

Zo maak je wachtwoorden gebruiksvriendelijk. de hash hiervan (met een goede salting en entropy) kan client of server side vergroot of verkleind worden maar voor de gebruiker is het voldoende om een passphrase te onthouden waarin het systeem coulant omgaat met kleine wijzigingen (wat was het wachtwoord ook alweer... iets met de hond uitlaten) en typfouten mits het valt binnen de parameters van de standaarddeviatie.
12-07-2019, 10:27 door Anoniem
Handelen instanties die wachtwoorden van maximaal 12 karakters accepteren wel overeenkomstig de AVG?

Handelen instanties die wachtwoorden van 1200 karakters accepteren, die geen maximum login attempts ingesteld hebben, geen regels voor password complexity toepassen, en geen multi factor authenticatie gebruiken wel overeenkomstig de AVG ?

Bieden ze meer veiligheid dan instanties die 12 karakters accepteren, en aanvullende maatregelen nemen ?
12-07-2019, 10:28 door Anoniem
- het ingevulde ww niet voorkomt in de lijsten van haveibeenpwnd (check bij elke inlog)
- je maar een paar pogingen hebt om het in te voeren. Daarna account vergrendeld. (Brute forcing dus onmogelijk)
- het mag bestaan uit alle leesbare ascii tekens (zo irritant als je niet je eigen ding kunt maken ervan)

Nutteloos indien het password wordt gestolen middels phishing, middels credential stealers, of middels keyloggers. Om maar wat te noemen.
12-07-2019, 11:03 door karma4
Ik eis een wachtwoord dat een lengte van 5.000.000 tekens toestaat. Dat zal niet te hacken zijn :<))))
Een wachtwoord is zo uit de jaren 60 omdat men toen niets beters kon.
12-07-2019, 11:35 door Anoniem
Ik eis een wachtwoord dat een lengte van 5.000.000 tekens toestaat. Dat zal niet te hacken zijn :<))))

Onderschep ik je wachtwoord wel met een keylogger ofzo.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.