De zwakte van wachtwoorden

Wat uitgelekte naaktfoto's ons leren

Inleiding

Zo gek waren ze helemaal niet, die Romeinen. Elke dag bij zonsopgang koos een divisie van hun majestueuze leger een nieuw wachtwoord, dat per kleitablet werd verspreid en dat soldaten moesten gebruiken om zich te identificeren bij het tegenkomen van de wacht - vandaar de term 'wachtwoord'. Erg hightech was het niet, maar tweeduizend jaar later hebben we het slechter voor elkaar: wie verandert er immers elke dag zijn wachtwoord?

Het besef dat wachtwoorden de achilleshiel van onze privacy zijn, is afgelopen week hard aangekomen bij de beroemdheden die naaktfoto's van zichzelf zagen opduiken op internet. Anders dan sommige media aanvankelijk suggereerden, waren die niet bij een hack buitgemaakt, maar door het ontfutselen van gebruikersnamen, wachtwoorden en de antwoorden op beveiligingsvragen.

Wachtwoorden worden sinds de opkomst van de eerste gedeelde computersystemen in de jaren zestig gebruikt om ervoor te zorgen dat iemands bestanden niet zomaar toegankelijk waren. In die tijd werden computers echter vooral gebruikt voor onderzoek, en niet voor het hosten van naaktfoto's en andere gevoelige persoonlijke informatie. Die praktijk is echter door de tijd ingehaald; niet alleen zijn er nu computers waarop wordt gewerkt en geconsumeerd, ook zijn er vandaag de dag smartphones en tablets die soms nagenoeg elke minuut van iemands leven meemaken.

Informatie op pc's, laptops, smartphones en tablets wordt veelal alleen afgeschermd van de buitenwereld met een wachtwoord. Toegegeven, het achterhalen van wachtwoorden biedt de vijand niet langer de kans om ons van binnenuit aan te vallen, maar wachtwoorden zijn voor veel mensen het enige dat privébestanden scheidt van de rest van de wereld.

Het probleem is dat je van mensen niet kunt verwachten dat ze voor elke website een uniek wachtwoord verzinnen dat ook nog eens aan alle beveiligingseisen voldoet - al zou dat dus eigenlijk wel moeten vandaag de dag. Tweakers kijkt waarom dat noodzakelijk is en hoe realistisch het is.

Onveilige wachtwoorden

Veel mensen gebruiken in de praktijk een beperkt aantal makkelijke wachtwoorden, die ze bovendien nooit wijzigen. Vorig jaar werd een database van softwaremaker Adobe gestolen, met daarin de privégegevens van 150 miljoen gebruikers en ongehashte wachtwoorden. Beveiligingsonderzoekers konden uit de database afleiden dat het wachtwoord '123456' onder Adobe-gebruikers het populairst was: dat wachtwoord werd maar liefst 1,9 miljoen keer gebruikt. Ook '123456789', 'password' en 'adobe123' werden honderdduizenden keren gebruikt.

Onderzoek uit 2012 wijst uit dat een op de drie Nederlanders zijn wachtwoord nooit wijzigt. Een wachtwoord hoeft dan maar één keer uit te lekken om iemands volledige privéleven op straat te doen belanden. Ook websites en diensten moeten dus de nodige moeite doen om goed met wachtwoorden om te gaan. Veel websites halen een wachtwoord dan ook door een hash-algoritme. Uit de hash is het originele wachtwoord niet te destilleren. Als alleen de hash wordt opgeslagen en niet het originele wachtwoord, is het originele wachtwoord daar niet uit af te leiden, zo is de gedachte, maar daarvoor moet hashing wel correct worden geïmplementeerd, iets wat nog steeds niet altijd goed gaat.

Als een site bijvoorbeeld geen salt gebruikt bij het opslaan van wachtwoorden, kunnen wachtwoorden in veel gevallen toch worden achterhaald. Een salt is een voor dat wachtwoord unieke waarde die wordt toegevoegd aan een wachtwoord voordat het wordt gehasht. Gebeurt dat niet, dan heeft een wachtwoord na het versleutelen altijd dezelfde hash. Een aanvaller zou dan een rainbow table kunnen aanleggen: een tabel waarin wachtwoorden worden gekoppeld aan de bijbehorende hashes. Het invoeren van een gehasht wachtwoord is dan voldoende om de plaintext-versie te krijgen.

Dat is geen theorie: Tweakers wist in 2011 bij een test op zijn eigen gebruikersbestand in een halfuur 48,9 procent van de wachtwoordhashes te kraken. Tijdens de test lukte het om 55.000 wachtwoorden in 14 seconden te kraken. Dat kwam doordat Tweakers tot dan toe nog een zwak hashing-algoritme gebruikte en geen salt toevoegde aan het wachtwoord; sinds 2011 gebeurt dat wel en wordt een veiliger algoritme gebruikt. Overigens zou het kraken van de wachtwoorden op hardware uit 2014 nog minder tijd kosten.

Een brute force-aanval op wachtwoorden is vooral een probleem bij kortere wachtwoorden. Daarbij worden alle mogelijke wachtwoorden geprobeerd, net zo lang tot het juiste is gevonden. Wie een wachtwoord van meer dan acht tekens heeft, hoeft zich daar vrijwel geen zorgen om te maken, ook omdat veel webdiensten rate limiting toepassen: na een aantal mislukte loginpogingen wordt een aanvaller dan geblokkeerd. Overigens bleek maandag dat rate limiting op de Find My iPhone-dienst van Apple niet was ingeschakeld.

Een ander gevaar is phishing: een legitiem ogend mailtje verleidt een gebruiker ertoe om zijn gebruikersnaam en wachtwoord in te vullen op een nepsite - waarna de maker van die site uiteraard de ingevulde logingegevens in handen krijgt.

Beveiligingsvragen

Beveiligingsvragen zijn zelfs nog kwetsbaarder. In het Facebook-tijdperk zijn antwoorden op vragen als 'Wat is de meisjesnaam van je moeder?' iets te makkelijk te vinden. Apple is op dit moment het enige grote bedrijf dat nog beveiligingsvragen gebruikt voor het resetten van wachtwoorden; bij andere aanbieders van clouddiensten wordt een back-upcode naar een tweede e-mailadres of een telefoonnummer gestuurd. Dat kan overigens ook bij Apple, maar gebruikers moeten bij het registreren wel antwoord geven op de beveiligingsvragen.

"Als je een beetje een bekend persoon bent, is dit soort informatie vaak te vinden", zegt beveiligingsonderzoeker Yonathan Klijnsma van Fox-IT. "Vroeger werkte dit misschien, maar nu is dit soort informatie te makkelijk te vinden. Het zal niet de eerste keer zijn dat iemand hiermee gepakt is." Klijnsma raadt gebruikers aan om bij sites die nog steeds beveiligingsvragen gebruiken niet daadwerkelijk het antwoord op de vraag in te vullen, maar het antwoord als een soort tweede wachtwoord te gebruiken.

Two factor authentication

Ondanks alle gebreken draait de meeste identificatie nog steeds om een wachtwoord. Zelfs bij de vingerafdruklezer op de iPhone 5s en Galaxy S5 moet de gebruiker als back-up een pincode invoeren, voor het geval dat de vingerafdruk niet kan worden uitgelezen. Sowieso is biometrische identificatie geen oplossing volgens Harri Kiljander, director of personal identity protection bij beveiligingsbedrijf F-Secure. "Als je vingerafdruk wordt gestolen, kun je die niet meer wijzigen", zegt Kiljander.

"Er zijn veel problemen met het gebruik van wachtwoorden als authenticatie. We leunen nog steeds op hetzelfde mechanisme als in de jaren zestig. Maar de branche is tot nu toe nog niet in staat geweest om met een beter alternatief te komen", aldus Kiljander. Op de langere termijn zal er wel een technologie komen die het wachtwoord vervangt, denkt Kiljander. Ook Fox-IT denkt dat dat nog wel even kan duren voordat het wachtwoord is verdwenen.

Toch een oplossing

Voorlopig zitten we dus nog vast aan het duizenden jaren oude wachtwoord. Wat niet wil zeggen dat internetgebruikers zich erbij neer moeten leggen dat hun privégegevens slechts zijn beschermd door een reeks van hooguit twintig of dertig tekens. De meeste websites hebben inmiddels namelijk ondersteuning voor two factor authentication.

Bij two factor authentication moet een gebruiker bij het inloggen niet alleen een wachtwoord invoeren, maar zich ook nog op een tweede manier identificeren. Vaak is dat middels een code die moet worden ingevoerd, of een hokje dat moet worden aangevinkt in een mobiele app, zoals bij Twitter het geval is. Zelfs als je wachtwoord uitlekt, heeft een aanvaller dan dus nog geen toegang tot je account.

Banken waren de eerste die op grote schaal tweetrapsauthenticatie aanboden aan consumenten: voor het doen van betalingen moeten gebruikers al sinds jaar en dag een code invoeren die bijvoorbeeld per sms wordt verzonden of door een apparaatje wordt gegenereerd. Battle.net biedt al jaren ondersteuning voor de techniek. Google begon als eerste aanbieder van clouddiensten met het aanbieden van de techniek; inmiddels zijn onder meer Twitter, Facebook, Apple, Dropbox, Microsoft en Steam het bedrijf gevolgd.

Overigens heeft Apple two-factor-authenticatie niet op al zijn servers ingeschakeld. Het is mogelijk om back-ups van iCloud te downloaden met enkel de gebruikersnaam en het wachtwoord, ontdekte een beveiligingsonderzoeker vorig jaar.

Ingewikkelde wachtwoorden

Voor websites die geen two factor authentication aanbieden, of voor wie extra voorzichtig wil zijn, is het uiteraard nog steeds nodig om een sterk wachtwoord te verzinnen. Zelfs ezelsbruggetjes helpen niet meer als je voor tientallen diensten een uniek wachtwoord wil verzinnen. Gelukkig zijn er wachtwoordmanagers, die ervoor zorgen dat je nog maar één wachtwoord hoeft te onthouden: dat om toegang tot de wachtwoorden te krijgen.

Er zijn zowel betaalde als gratis passwordmanagers op de markt, die in functionaliteit niet veel verschillen. Sommige wachtwoordmanagers bieden bijvoorbeeld synchronisatie aan, waarbij de wachtwoorden op servers van de manager worden opgeslagen. Ook het aanbod aan extensies en bookmarklets voor browsers, om op sites te kunnen inloggen zonder handmatig een wachtwoord in te hoeven voeren, verschilt.

De meeste wachtwoordmanagers hebben bovendien een functie aan boord om wachtwoorden te genereren - je hoeft ze immers niet meer te onthouden, dus een wachtwoord als 'bQ!4}/sag8^py65Uv/O' is dan geen probleem. Al moeten websites daar wel aan meewerken: niet alle sites accepteren speciale tekens en ook de lengte is soms een probleem. Zo mag een ING-klant geen wachtwoord van meer dan 20 tekens hebben; bij webhoster Strato is dat zelfs maximaal acht tekens.

Overigens zijn wachtwoordmanagers ook niet gegarandeerd veilig: als de server van een wachtwoordmanager met synchronisatie wordt gehackt, kunnen wachtwoorden alsnog op straat komen te liggen. Dat is geen theoretisch probleem: in juli bleek dat Amerikaanse onderzoekers kwetsbaarheden in meerdere wachtwoordmanagers wisten te vinden, waardoor in het geval van LastPass een website de wachtwoorden van gebruikers kon uitlezen.

Maar een wachtwoordmanager die net als alle software kwetsbaarheden kan bevatten, blijft veiliger dan het recyclen van wachtwoorden. Samen met het gebruik van two-factor-authenticatie zou dat je voorlopig veilig moeten houden - totdat het wachtwoord helemaal verdwijnt, natuurlijk. Hoe dat er gaat uitzien - in de vorm van biometrische identificatie, bijvoorbeeld - is nog een kwestie van gissen.

Reacties (376)

[WhatsappHack]

Ja dat met die romeinen laat wel meteen het probleem zien dat veel mensen doen: sterke, of vaak wijzigende wachtwoorden, schrijven ze op. En dan niet in een secure container, maar op een kladblokje of in hun email...

... Dat maakt t alles behalve veilig. Die kleiblokken werden ook nog wel eens gejat.
Beter een zeer sterk wachtwoord uit je hoofd leren en een jaartje gebruiken, dan steeds wijzigen en t moeten opschrijven.

[FreezeXJ]

Dan mag jij bepaalde programmas eens vertellen dat ze me niet elke maand moeten dwingen een nieuw wachtwoord te kiezen. Da's namelijk gruwelijk irritant. Nou zul je misschien 3-4x iets interessants verzinnen, en dat niet opschrijven, maar na een half jaar ben je de tel kwijt, en schrijf je de hele bende op een post-it, en hang je em aan je monitor. Einde security, juist omdat ze dachten de veiligheid te verbeteren. Wat mij betreft moet je wachtwoorden gewoon vervangen door een token, een USB-stick dus. Ideaal, kan veel electronica in, 2-way authentication (da's geen 2-factor, let op!), en mensen raken hun huissleutel ook niet 3x per week kwijt. Ja, sommigen wel, maar daar is geen helpen aan.

[mOTiVe]

Zonder de context erbij te noteren kun je een wachtwoord prima ergens opschrijven. Als voorbeeld kun je bijvoorbeeld een fake contact in je telefoon opnemen en daar al je pincodes in kwijt. Geen hacker die weet welk contact het is behalve jij (zolang je de persoon niet Password Harry noemt).

[Dreamvoid]

Ander voordeel is dat zelfs als een hacker weet dat je pincode in 1 van je driehonderd contacten zit, het alsnog moeilijk is - pincodes zijn immuun voor bruteforce, want ze blokkeren de boel na 3 pogingen.

Met dingen als Gmail/etc is dat lastiger te doen - trek bv eens na een paar maanden weer een oude laptop open, en die begint direct elke minuut zijn email te syncen met een verouderd password -> hop, Gmail geblokkeerd.

[fjjl]

Wachtwoorden van belangrijke zaken schrijf ik gewoon op een papiertje en stop het tussen wat boeken. Sterke inbreker die tussen een stapel boeken op zoek gaat naar een papiertje. (Brand e.d. komt zo weinig voor dat je dat risico echt wel kan nemen en anders is sowieso wachtwoorden een bijzaak.)

[Dreamvoid]

Een kladblok is ironisch genoeg behoorlijk veilig - een zeer, zeer beperkt aantal mensen heeft fysiek de mogelijkheid om dat papiertje te zien (plak m natuurlijk niet op je monitor), terwijl honderden miljoenen mensen toegang hebben tot jouw internet-connected devices/services, zelfs een loskoppelbaar USB stickje of HDD is niet veilig als de computer ongemerkt een bot is met keylogger.

[Reactie gewijzigd door Dreamvoid op 23 juli 2024 01:01]

[Blokker_1999]

Eigenlijk is de essentie van dexkcd well correct. We steken zoveel moeite in het verzinnen van moeilijke wachtwoorden die eenvoudig te raden zijn terwijl we eenvoudige oplossingen links laten liggen.

Indien dienstbeheerders hun zaakjes op orde hebben is het herbruiken van wachtwoorden trouwens ook geen onoverkomelijk probleem.

Daar ik op zoveel verschillende platformen werk is het voor mij niet mogelijk om zomaar een passwordmanager te vinden. Er worden wel steeds meer platformen ondersteund, maar toch kom je regelmatig iets tegen waar het niet gaat. En als je dan ineens 'bQ!4}/sag8^py65U+6GTc.ux@L{v/O' zelf moet gaan intypen, dan is de kans op fouten enorm groot, zeker op een mobiel apparaat.

En beheerders die verlangen dat een gebruiker elke 3 maanden zijn wachtwoord veranderd krijgen van mij ook een trap onder het achterwerk. Het zorgt er net voor dat er meer voorspelbaarheid in de wachtwoorden komt daar vele gebruikers gewoon een cijfer toevoegen achter hun wachtwoord.

Geef mij maar een goed, stevig wachtwoord totdat er echt goede oplossingen ontstaan voor dit probleem, oplossingen die vandaag nog niet zo goed voor handen zijn.

Van two-factor authentication ben ik ook nooit een fan geweest. Vooral omdat de belangrijkste diensten die het vandaag aanbieden nu niet direct die diensten zijn aan wie je nog zomaar wat private informatie wenst door te geven.

[SmokingCrop]

Gewoon 2-factor via de app van google bv?
Niet nodig om bv telefoon gegevens door te sturen en dergelijke.

[Verwijderd]

Je kan bij passwordmanagers vaak wel opgeven welke karakters wel-en-niet gebruikt mogen worden. Dan kan je dus wachtwoorden genereren die toch nog relatief makkelijk te typen zijn, maar niet noodzakelijkerwijs zwak.

[Kaasje123]

De opmerking over Strato in het artikel snap ik niet. Ik zie toch echt dit als ik naar Strato ga om in te loggen: http://tweakers.net/ext/f/tg26N8OfhxUwOqGtIrH2VV4t/full.jpg

[Reactie gewijzigd door Kaasje123 op 23 juli 2024 01:01]

[BillyTheClit]

Dit artikel is weer een schoolvoorbeeld van "het probleem in de schoenen van de gebruiker schuiven". Dat er een schrijnend gebrek aan standaardisatie en normering op de markt is is eigenlijk de echte reden van deze problemen.

Als ik een paswoord van 256 tekens gebruik heb ik geen enkele garantie dat de server aan de andere kant deze ook allemaal gaat inzetten (voorbeeld Microsoft) of dat er een behoorlijk multipass hashing algoritme op losgelaten wordt met daarbij de nodige salting.

Op sommige servers worden paswoorden in plain text opgeslagen, in 2014... zie bijvoorbeeld de site http://www.plaintextoffenders.com. Bij mijn internetprovider staat mijn paswoord alvast leesbaar in hun databank en in elke mail die ze me sturen, een klacht hierover leverde niets op.

Iedereen doet namelijk maar wat als het op authenticatie aankomt.
We hebben voor alles ISO standaarden en Thuiswinkel waarborg en andere rommel, maar op het vlak van authenticatie is er te weinig standaardisatie en er is geen verplichting om hieraan te voldoen.

[CurlyMo]

Bij mijn internetprovider staat mijn paswoord alvast leesbaar in hun databank en in elke mail die ze me sturen, een klacht hierover leverde niets op.

Dat is misschien nog wel het grootste probleem, ook in het geval van Apple. Een van de vele reacties die ik heb gehad op een van mijn vele mails:

Hartelijk dank voor uw mail en vraag. De wachtwoorden waarmee wordt gewerkt, zijn wel degelijk versleuteld. Ze zijn gecodeerd opgeslagen in de database. Wanneer iemand zijn wachtwoord is vergeten, wordt het gecodeerde wachtwoord uit de database gedecodeerd met een beveiligingssleutel en verstuurd per mail zodat het leesbaar is voor degene (u in dit geval) die het heeft opgevraagd. Dit alles gaat volautomatisch, dus medewerkers krijgen deze mailtjes niet te zien.

[aileron]

Zoals Bruce Schneider wel eens heeft gezegd, security in general is altijd een afweging tussen security en gebruikersgemak. Een meer secure systeem zal onvermijdelijk ten koste gaan van gebruikersgemak en het is de kunst om daar een goede balans in te vinden.

Voor de mensen die er in geinteresseerd zijn, security dude Steve Gibson is met een authentication systeem gekomen dat hij SQRL noemt wat makkelijk in gebruik moet zijn en tegelijkertijd ook erg veilig.
https://www.grc.com/sqrl/sqrl.htm

[DennusB]

2-factor-auth is niet altijd veilig, zo bleek wel bij de hack van Apple... want de back-up API van iCloud negeerde de 2FA gewoon en je kon gewoon met het (gekraakte) wachtwoord inloggen!

[pietje63]

Het is niet zo dat 2FA niet veilig is, maar de implementatie ervan. De beveiliging is afhankelijk van de zwakste schakel.

Ik heb twee sloten op mijn voordeur, maar laat mijn balkondeur open staan.

[Biersteker]

Als je dan toch die analogie wil trekken.

Je heb een huurhuis (appleID), waarvan je denkt dat je goede sloten hebt, en je mag wel de cilinder (wachtwoord) vervangen, en een anti-inbraakslot plaatsen (2FA). Behalve dat je een deur hebt zonder anti-inbraakslot, waarvan je niet wist dat mensen er ongezien met een stormram tegen aan zit te rammen, totdat de deur begeeft.

[ShellGhost]

Die hack van apple had niks van doen met de 2-factor auth.
Als je ongelimiteerd passwords kan blijven invullen zal je ooit de goede vinden.

[DennusB]

Dat had er wel degelijk mee te maken, want nadat ze bij API 1 (FindMyIphone) het wachtwoord hadden gebruteforced konden ze er mee inloggen op API 2 (Backup van iCloud).... niet zomaar wat roepen als je niet weet hoe het zit.

[Carbon]

Geen van beide API's ondersteunt TFA

[DennusB]

Dat is ook het hele probleem he.... het stond wel ingeschakeld maar de API negeerde het en had voldoende aan username/password. Dat is/word nu dus ook aangepast.

[Carbon]

Dat is ook het hele probleem he.... het stond wel ingeschakeld maar de API negeerde het en had voldoende aan username/password.

m.a.w. TFA werd dus niet gebruikt, ondanks dat schrijf je dat Apple's implementatie van TFA niet veilig is.

Het gaat hier niet om de implementatie van TFA an sich maar de ontbrekende integratie met sommige iCloud diensten.

[DennusB]

Je leest dingen zoals je ze wilt lezen. Maar wat jij wilt Uitslag is hetzelfde : 2FA kon worden omzeild bij bepaalde delen van iCloud

[Carbon]

Je leest dingen zoals je ze wilt lezen.

Nope, je hebt het alleen wat ongelukkig geformuleerd

Soortgelijk voorbeeld:

Stel iemand heeft geen gordel om en hij vliegt als gevolg van een ongeluk door de vooruit van z'n Golf.

De gordel is dus aanwezig maar werd niet gebruikt.

Vervolgens schrijf jij:

"Autogordels van Volkswagen zijn niet altijd veilig"

Snap je het nu?

"2-factor-auth is niet altijd veilig" moet dus zijn "2-factor-auth wordt niet altijd gebruikt"

[Reactie gewijzigd door Carbon op 23 juli 2024 01:01]

[Carbon]

2-factor-auth is niet altijd veilig, zo bleek wel bij de hack van Apple... want de back-up API van iCloud negeerde de 2FA gewoon en je kon gewoon met het (gekraakte) wachtwoord inloggen!

Wacht even!
Hoe kun je een uitspraak doen over de juiste werking van 2FA terwijl 2FA niet werd gebruikt?

[DennusB]

2FA stond ingeschakeld op sommige profielen alleen had Apple er geen check op ingebouwd....

[Carbon]

integratie <> implementatie

[Biersteker]

precies. Dat samen met geen bruteforce protection zorgde ervoor dat op sommige websites een ware handel in het kraken van icloud accounts opbloeide. (ik zal de link maar achterwege laten).

[Tunaflish]

Dat ligt dan niet aan two factor auth, maar aan een gebrekkige procedure van iCloud. Het principe van 2FA kan er niks aan doen als het genegeerd wordt.

[Armin]

2-factor-auth is niet altijd veilig, zo bleek wel bij de hack van Apple

Alleen bleek dus dat de hack van Apple niet kwam door gebrek aan 2FA, maar door celebs die voor de veiligheidsvragen echte antwoorden invulden. Voor een gewone burger al niet slim, maar voor een celeb waar die antwoorden op wikipedia staan erg dom ...

Tenslotte zelfs als het wel via brute force gedaan was, was het juist een bewijs geweest dat het wel werkt. Immers met 2FA zou men zelfs zonder brute force limieten, niet hebben kunnnen inbreken.

[Enai]

Google ook trouwens. Ze sturen een SMS naar je telefoon met erin een code... of je kunt je (relatief korte) backupcode (met enkel cijfers) (waar je er tien van krijgt) gebruiken. *krak*

[angelina]

Als je geen wachtwoordmanager gebruikt dan is het onthouden van een ingewikkeld password best lastig. Ik heb ergens gelezen dat je beter een hele zin als wachtwoord moet gebruiken, schijnt net zo sterk wachtwoord te zijn. Zoiets als "Mijn wachtwoord van vandaag is Maandag!", makkelijk te onthouden en toch lang.

[Brummetje]

Brute force/dictionary attack heeft zo`n wachtwoord (met standaard woorden) binnen een mum van tijd gekraakt

[LOTG]

Nee juist niet. Je wachtwoord bestaat namelijk uit heel veel tekens, en om dat te bruteforcen ben je wel een tijdje bezig. Je dictionary bevat namelijk deze zin helemaal niet, en wat je met een bruteforce dictionary aanval doet is de lijst af gaan.

Je weet namelijk de lengte van het wachtwoord helemaal niet, en je weet ook niet of het wachtwoord al dan niet speciale tekens bevat. Dus tegen de tijd dat jij bent aangekomen bij de bovenstaande zin ben je wel een tijdje verder.

Dus, meer tekens doet het beter dan een kort wachtwoord met van allerlei verschillende characters.

Uitleg

[primanocte]

volgens de password check van intel toch niet echt.. je weet immers niet of iemand z'n wachtwoord zo heeft opgebouwd..dus moet je alle mogelijke combinaties alsnog afgaan

password checker: https://www-ssl.intel.com...en/forms/passwordwin.html

met bovenstaand voorbeeld:
It would take about 1.763869288276994e+41 years to crack your password.

[gpgekko]

Tja, als ik daar 'wachtwoord' in vul, duurt het volgens hun 5 maanden om het te kraken ("Congratulations!"), en toch voel ik me er niet heel veilig bij...

[LOTG]

Ze gebruiken alleen een Engelse dictionary daar. Als je password invult is het 0 seconden. Vul je bovenstaande string in het engels in dan krijg je 230129761355940 years.

[SaiKoTiK]

Dus om het voor dictionary attacks wat moeilijker te maken gebruiken we best een "zin" met woorden uit meerdere talen + wat andere tekens?

Met bovenstaande voorbeeld dan:
Mijn#wachtwoord#d'aujourd'hui#ist#Monntag!
3.815602044400794e+45 years

[jer123c]

het woord wachtwoord als wachtwoord duurt 5 maanden om te kraken maar een wachtwoord van 10 tekens, met een kleine letter, hooftletter cijfer en een leesteken maar een uurtje??

[MadEgg]

Dat geldt voor elke opbouw. Het punt is dat het wel een mogelijkheid geeft om dingen te proberen. Net zoals rainbow tables er vanuit gaan dan je wachtwoord niet al te lang is, zou je hiermee dus een methode kunnen bouwen die er vanuit gaat dat je wachtwoord is opgebouwd uit losse woorden.

Je hoeft dan dus niet alle letters af te gaan maar alleen de combinaties van deze woorden. En dat gaat alweer een stuk sneller.

Ik gebruik tegenwoordig gewoon wachtwoorden van 24 of meer willekeurig gegenereerde karakters die ik beheer met KeePassX, welke dan weer op een server in eigen beheer (mbv OwnCloud) is opgeslagen zodat ik er wel overal toegang toe heb. Nu moet ik zelf dus twee wachtwoorden onthouden: mijn OwnCloud wachtwoord en het wachtwoord van mijn KeePassX bestand. Daarna kan ik overal bij. Bevalt me prima en meer dan veilig genoeg.

[Zer0]

Je hoeft dan dus niet alle letters af te gaan maar alleen de combinaties van deze woorden. En dat gaat alweer een stuk sneller.

Er zijn 26 letter, 10 nummers en een rijtje speciale tekens. Er zijn veel meer woorden, vooral als je verschillende talen meerekent.
Een "wachtwoord" bestaande uit 5 woorden is dus een stuk moeilijker te achterhalen dan een wachtwoord uit 5 tekens.

[MadEgg]

Wel dan 5 tekens ja. Maar niet makkelijker dan een wachtwoord van 10 tekens. En dat onthoud ik persoonlijk een stuk makkelijker dan vier willekeurige woorden (want dat is de bedoeling natuurlijk), met nog wat mutaties erop toegepast.

[Verwijderd]

Ik ben nog steeds op zoek naar iemand die mij kan uitleggen hoe je Keepass dan gebruikt als je regelmatig op andere PC's werkt (flexplekken op je werk bijvoorbeeld). Moet je dan altijd een portable versie op een USB'tje bij je dragen ofzo?

[MadEgg]

Yup. Ik heb mijn KeePass database op een OwnCloud server. Deze moet je openen met een KeePass client. Als je dus regelmatig op andere systemen werkt dan is het waarschijnlijk handing om de client naast je KeePass database te bewaren zodat je die gelijk mee kan downloaden. Zelf gebruik ik doorgaans gewoon dezelfde set systemen en daar zet ik allemaal KeePassX op, anders moet je iets meer moeite doen om het te gebruiken.

[FreezeXJ]

Dat moet helemaal niet, dat geldt alleen als je dat ene password wilt kraken, en verder geen informatie hebt. In de meeste gevallen schiet men met hagel op een grote password-file met miljoenen wachtwoorden. Verschillende methodes snel uitproberen (even de standaardset met "god", "geheim" en "1234" proberen, daarna alle woordenboeken nalopen, en daarna eens een brute force), en als je dan al 10% gekraakt hebt is het prima. Zoals Tweakers ondervond heb je dan soms al 40% in handen, de rest heeft geluk gehad. Letterlijk ieder los wachtwoordje kraken is een heidens karwei, als je het laaghangende fruit plukt heb je genoeg om mee verder te kunnen.

[Marijn_]

Zoals LOTG hierboven al aangaf gebruikt die website alleen een Engels woordenboek. Als je bijvoorbeeld in plaats van "mijnwachtwoordvanvandaagismaandag" gebruik maakt van "mypasswordoftodayismondayevenings" (evenings toegevoegd om aan een gelijk aantal tekens te komen), dan duurt het in plaats van 1,7*10^41 jaar nog "maar" 8243 jaar om te kraken. Natuurlijk nog steeds lang, maar wel 2*10^37 keer korter dan de originele inschatting!

[Garma]

Denk dat dat wel meevalt, ipv alle woorden aflopen (268000 in het NL) moet het algoritme nu alle woorden tot de zevende aflopen. Dat is een exponentiële toename en dus duurt dit aanzienlijk langer

[Reactie gewijzigd door Garma op 23 juli 2024 01:01]

[FreezeXJ]

Yep, van 0.001 seconde wordt het nu 0.2 seconde. Daar zal de gemiddelde hacker niet wacker van liggen. Het gebruik van leestekens heeft meer effect.

[Garma]

Exponentieel, weet je wat dat is? Als het eerst 0.001 sec duurt duurt het bij slechts 1 woord extra 268 seconden. Nog een woord erbij duurt het 90 miljoen seconden

[Wailing_Banshee]

Als je een volwaardige zin wilt aflopen (dus met leestekens) ben je echt wel iets langer bezig dan 0.2 seconden.

De woorden zelf staan misschien dan wel in een woordenboek, maar de leestekens ook? Ik gebruik wel eens zinnen als, "Ik vind dit, dit lange wachtwoord, een goed wachtwoord." Best knap als je dat binnen een seconde kunt kraken...

[Verwijderd]

Demo! Ik ben wel benieuwd hoe je dat zo snel doet, en hoe je quantum-cluster eruit ziet.

[sanderv]

Ik heb hetzelfde ook wel eens gelezen, dus ik nam aan dat door het samenvoegen van woorden tot een zin het aantal mogelijkheden zo exponentieel groeit dat het toch weer moeilijk te raden is. De w00rd3n met letters vervangen door er-op-lijkende cijfers zouden dan juist weer erg onveilig zijn omdat ze vrijwel direct van het woordenboek af te leiden zijn. Uiteindelijk willen we toch graag iets dat we kunnen onthouden, en dus geen random-gegenereerde string van tekens... *zucht*

[Armin]

Uiteindelijk willen we toch graag iets dat we kunnen onthouden, en dus geen random-gegenereerde string van tekens

En dat is precies waarom wachtwoorden van mensen zwak zijn.

Maar je hebt gelijk natuurlijk. Echter voor sites die écht belangrijk zijn, én geen 2FA hebben, zou ik toch door de zure appel heenbijten en een 12-16 teken lang random wachtwoord gebruiken.

Voor de meeste mensen is dat even wennen, maar uiteindelijk geen probleem. Schrijf het op op ene papiertje en stop dat in je portemonnaie. Na maximaal een paar weken zitten ze in het hoofd en kan het papiertje zelfs vernietigd worden.

Voor niet belangrijke sites is een compromis uiteraard geen probleem.

Zeker ook omdat we moeten beseffen dat deze hele dicussie over kraken enkel geldt indien én de wachtwoord database van de betreffende site gestolen wordt, én die site geen goede veiligheidsalgorithmen met salts en multiple rounds gebruikte. Een zwak wachtwoord in combinatie met goede salt en lekker veel hash-rounds is nog steeds goed bestand tegen hackers.

En de ironie hier is ook dat jouw achtwoord enkel veiliger hoeft te zijn dan de meeste anderen. Immers, hackers geven al snel op na x% gekraakt te hebben. Immers bij hacks is vaak haast geboden. Andere accounts worden dan misbruikt, de site ontdekt het en blokeert alles. Later kraakt men dan jouw wachtwoord ook als academische exercitie, maar zolang elk wachtwoord van jou uniek is, maakt dat niet uit.

[sanderv]

Ik heb er geen bezwaar tegen om een ingewikkeld wachtwoord uit mijn hoofd te leren. Maar dan moet het ook nog eens verschillend voor elk systeem, elke website! Pfff...

[Armin]

Enkel de zeer belangrijke sites die geen 2FA ondersteunen.

Indien ze 2FA ondersteunen is een gewoon sterk wachtwoord ook voldoende. Idem indien de data die gestolen kan worden niet zo belangrijk is. Dus voor Tweakers kun je gewoon een lekker makkelijk wachtwoord gebruiken.

[Benji87]

Ik denk het niet, het zijn alsnog 6 verschillende woorden, een uitroepteken en 2 hoofdletters. Als je alle veel voorkomende woorden, variaties met hoofdletters en punten en uitroeptekens in zo'n dictionary gaat stoppen en dan een dictionary attack gaat uitvoeren, ben je denk ik niet sneller uit dan een gewone bruteforce aanval op een kleiner wachtwoord.

@LOTG: Klopt, maar ik bedoelde dat zelfs als de aanvaller zou weten dat het een zin met normale woorden moet zijn, dat je alsnog een waslijst afmoet met combinaties van woorden en variaties met hoofdletters en leestekens. Dus dat zelfs een specifieke tool die zinnen af moet gaan, niet op het voorbeeldwachtwoord zou komen binnen een acceptabele tijd.

[Reactie gewijzigd door Benji87 op 23 juli 2024 01:01]

[LOTG]

Het maakt niet uit dat het gewone woorden zijn, want dat weet de aanvaller helemaal niet. Het gevaar zit het in het gebruik van 1 of 2 normale woorden, of woorden met substituties van letters die generiek zijn om te onthouden. Het is immers voor een redelijk kort woord niet lastig om de variaties op te nemen in je attack.

Het word echter voor de aanvaller pas een probleem als jij meer items aan je string gaat toevoegen, want dat is namelijk voor ieder item een berg meer mogelijkheden. 6 woorden creëert een enorm lang wachtwoord wat heel veel mogelijkheden bevat.
Er zijn veel meer combinaties mogelijk met 6 woorden dan 8 random karakters.

En dan weet de aanvaller nog geeneens of jou wachtwoord bestaat uit letters of tekens. Je bent immers aan het bruteforcen op de ingang, niet je wachtwoord aan het terug halen uit een hash. Hier geld het zelfde verhaal overigens. Meer bits is meer ellende, en een rainbow table bevat ook niet een lijst van random zinnen.

[Dreamvoid]

Wat ik nooit begrijp, wat voor waardeloze server software staat bruteforce attacks toe? Login pogingen beperken tot 1x per 10 seconden maakt bruteforcen zinloos.

[Reactie gewijzigd door Dreamvoid op 23 juli 2024 01:01]

[Brummetje]

Nahjah beperken tot 1x per 10 seconden is toch weer 6 wachtwoorden per minuut en 8640 wachtwoorden per dag... Dat zijn er dus al weer genoeg en als het de moeite waard is voor een hacker en je laat dit lekker lopen voor een geruime tijd (mensen veranderen wachtwoorden vaak niet of nauwelijks) dan kun je er dus al genoeg "raden".

Alleen beveiligingen tegen bruteforce door alleen maar 1x per x seconden toe te laten is in ieder geval niet genoeg.

In de systemen die ik maak wordt het bij iedere foutieve poging opgehoogd... eerste x fout zoveel seconden en dat gaat door tot 5 keer en dan is het zoveel minuten complete blokkade. Als ze het na de blokkade weer fout doen wordt het iedere keer langer tot dat het gewoon een complete blokkade is. En dat is maar 1 van de dingen die ik dan gebruik, je moet het ze natuurlijk moeilijk maken zodat de moeite te veel is om het überhaupt te gaan proberen.

[Dorank]

10 per seconde per wat? Voor totaal aantal logins? Per connectie? Per gebruikersnaam? Per IP? Een combinatie van voorgaande?

Per connectie heeft geen zin, zet de cracker gewoon meerdere connecties op. Per gebruikersnaam, heeft geen zin want dan worden er gewoon meerdere gebruikers tegelijk geprobeerd? Per IP, met een groot genoeg botnet geen probleem als de timeout niet te lang is (als die te lang is sluit je legitieme gebruikers wellicht te snel uit).

[hellum]

Dat gaat heel erg meevallen, (google eens op correct horse battery stapler).

[Verwijderd]

Brute force/dictionary attack heeft zo`n wachtwoord (met standaard woorden) binnen een mum van tijd gekraakt

Nonsense. Denk aan vele jaren met een botnet.

Dit soort informatie is echt bijzonder schadelijk voor normale gebruikers want die denken dan dat er niets meer te redden is. Terwijl een goed wachtwoord de allereerste en belangrijkste verdediging is. Dus nonsense en diegene die je plussen zouden zich moeten schamen.

[Verwijderd]

Dan kun je volgens mij me beter iets als dit gebruiken: M(mijn) w(wachtwoord) v(van) 2(today) I (is) M(maandag) ! (uitroepteken)

Het slaat nergens op als je de achterliggende zin niet weet en met een brute force/dictionary attack kom je er ook niet zomaar door omdat het geen woorden zijn.

[Tourniquet]

Maar het zijn maar zeven tekens. Die verkorte versie is aanzienlijk sneller te kraken dan de volledige zin (17 minuten volgens https://www-ssl.intel.com...en/forms/passwordwin.html)

[Verwijderd]

Daar had ik even niet bij stil gestaan. Je hebt inderdaad helemaal gelijk!

[Asteryz]

Dictionary hoef je niet bang voor te zijn. Vergelijk 8 woorden met een wachtwoord van 8 tekens. Maar in plaats van 100 mogelijke tekens zijn er 268000(Volgens garma hierboven).

Dus inplaats van 100^8=10biljard mogelijkheden zijn er dan 268000^8=2*10^42 (2 Septiljoen geloof ik).

[gaafgassie]

Klopt helemaal!
http://xkcd.com/936/

[Halfdan]

Analyzing the XKCD Passphrase Comic: https://xato.net/passwords/analyzing-the-xkcd-comic/

[MadEgg]

Die wordt veel aangehaald maar ik ben niet overtuigd van de effectiviteit. Zeker, het is een stuk veiliger dan wachtwoorden als 1234 of test, maar voldoende (minstens 10) willekeurige karakters met een groot genoege karakterset zijn lastiger te kraken. Niet met standaard brute-forcen maar wel met gecombineerde dictionary attacks.

Bovendien is het ook niet makkelijker te onthouden: doe dat maar eens voor 10 verschillende sites en weet dan welk 'makkelijk te onthouden' wachtwoord bij welke site hoort. Je gaat ze geheid door elkaar halen.

Nee, doe mij maar http://www.keepassx.org/

[Stoney3K]

Bovendien is het ook niet makkelijker te onthouden: doe dat maar eens voor 10 verschillende sites en weet dan welk 'makkelijk te onthouden' wachtwoord bij welke site hoort. Je gaat ze geheid door elkaar halen.

Ik ben toch beter in het onthouden van filmquotes dan in het onthouden van random strings van 10 karakters.

Bij elke site gewoon een relevante film zoeken en daar een citaat uit halen kan je een aardige collectie aan wachtwoorden opleveren.

[Mr Pingu]

Maar de aanvaller weet niet dat er GEEN tekens inzitten, waardoor de aanvaller dat niet kan uitsluiten. Waardoor alleen de lengte er toe doet en de karakterset irrelevant. Echter als de aanvaller weet dat er geen tekens inzitten, worden de mogelijkheden snel kleiner.

[Verwijderd]

Ja, en dan moet je op een gegeven moment je wachtwoord weer verplicht wijzigen en mag het niet te veel lijken op het vorige wachtwoord moet er minstens een cijfer, hoofdletter, en een van de volgende tekens in voorkomen &%$#! Erg irritant.

Ik werkte altijd met een simpel volgnummer op het zelfde basis wachtwoord over verschillende systemen, echter hadden die systemen allemaal weer met een verschillende verversingsregime. Dus op een gegeven moment had je dan over verschillende systemen hetzelfde wachtwoord maar met een verschillend volgnummer. Ook niet te doen.

Mensen worden daar gek van en gaan toch die password regimes ondermijnen met truukjes.

Het makkelijkst lijkt me toch echt een fingerprint authentication ook al is dat ook niet helemaal waterdicht het is in elk geval gebruiksvriendelijk.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 01:01]

[anboni]

Mensen worden daar gek van en gaan toch die password regimes ondermijnen met truukjes.

Truukjes zoals

Ik werkte altijd met een simpel volgnummer op het zelfde basis wachtwoord over verschillende systemen

bedoel je?

[Verwijderd]

Ja inderdaad

[Nauxuron]

De relevante xkcd

[remunj1988]

Maar dan moet je wel weer onthouden dat je het wachtwoord voor een bepaald iets op maandag hebt gemaakt. Mijn inziens lijkt me dit ook niet erg handig en is Keepass meer toepasbaar met een sterk wachtwoord.

[FreshMaker]

Ik heb overal mijn wachtwoord ingesteld met "incorrect"
Als ik het dan even niet meer weet, krijg ik het juiste van de betreffende site

"your password is incorrect, please try again"

Nog nooit misgegaan

[egnappahz]

Ik denk dat de uitgelekte naaktfoto's ons enkel wat leren over iCloud Security en Apple's security beleid, Dankjewel.

[Audi-Arjan]

omdat?
Voor zover nu bekend is het een phishing actie.
Dat de bekende mensen daar in trappen is net zo dom als mijn oma die er in trapt
bij de Rabobank phishing mails.
Het enige dat je Apple kwalijk kan nemen is dat er geen time-out op het aantal pogingen zat.
Volgens mij was dat echter ook al weer voor de "hack" aangepast.

Eerlijk is eerlijk he, die mensen die nu (naakt) op internet staan hebben zelf de foto's in de cloud gezet.

Overigens blijf ik het raar vinden dat phishing en brute-force onder hacken vallen maar goed.

[egnappahz]

Ik noem het ook niet echt "hacken", maar je moet het de tegenpartij nu ook niet te makkelijk maken.

Je moet als bedrijf voorkomen dat zo een dingen niet op grote schaal kunnen gebeuren. Je kan bv. hiervoor enkele dingen verplichten bij gebruikers in het beveiligingssysteem. En dus je moet ook bv. zon time-out introduceren. Voor de rest zou het dan ook niet mogen uitmaken wat de media en dergelijke allemaal verkondigen, er is iets gebeurd op grote schaal, en dus moet het beter, zeker in zo een wijd-gebruikte, persoonlijke cloud.

Daarbovenop moet je ook geen naaktfotos op de cloud gaan zetten, hier kan ik ook luid mee akkoord gaan

[Verwijderd]

"bij webhoster Strato is dat zelfs maximaal acht tekens."
Serieus? Dat is toch wel erg bizar.

Dat terzijde is KeePass en alternatieven echt een uitkomst voor de gemiddelde IT'er met minimaal 100 wachtwoorden. Belangrijke zaken onthoud je zelf maar voor de andere sites is het echt een uitkomst.

[Repsaj_Nav]

Waarom zit de moeilijkheidsgraad niet in de lengte?
Als er een algoritme met een maximum wordt gebruikt (zoals SHA zoals hierboven aangeven) dan heb je boven dat limiet gelijk. Als het maximum niet wordt overschreden, is een lang wachtwoord wel degelijk moeilijker met brute-force te kraken dan een korte.

Ken je deze?
http://xkcd.com/936/

[Lednov]

Ja.
en een lang wachtwoord is niet per definitie veiliger dan een kort wachtwoord. dat is een illusie. het enige wat een lang wachtwoord biedt, is dat het langer duurt tijdens bruteforce attack.

[JDVB]

Nee, het biedt in de praktijk meer veiligheid.
In de praktijk worden namelijk woordenlijsten gebruikt en de common substitutions uitgeprobeerd.
Een NL woorden(boek)lijst voor een NL website met daarbij de common substitutions laat je Veronica wachtwoord geraden worden.

Gezien de meeste wachtwoorden relatief kort zijn wordt dat op dit moment eerder geprobeerd dan een combinatie van meerdere woorden achter elkaar.
Ga je bij die meerdere woorden ook nog enkele van de door jou genoemde vervangingen toepassen, wordt de kans dat een cracker achter je wachtwoord komt helemaal klein.

[Reactie gewijzigd door JDVB op 23 juli 2024 01:01]

[Nha]

En dat het langer duurt maakt het net wel veiliger. Een wachtwoord als 123456 is volgens you dan even veilig als een wachtwoord dat 500 tekens lang is? Kom nou...

[RagEnigma]

https://www.schneier.com/...03/choosing_secure_1.html

Als je dit leest zul je zien dat wat jij aanraadt ook niet handig is.

[Lednov]

ik heb het zojuist gelezen, en hier wordt over brute force gesproken met die techniek is ELK wachtwoord te achterhalen. hoe dan ook.

je kiest een wachtwoord niet omdat doel tegen te gaan. je verliest het al tijd, al duurt het 1000 jaar. je keist een wachtwoord om de gelegenheid te ontnemen.

en dat is ook wat hij zegt: "Seconds after it was cracked, he noted, "You won't ever find it using brute force." ".

en: "Password crackers try the most common passwords first."

[RagEnigma]

Niet alleen over brute force maar ook over password dictionaries met varianten. Dit maakt het Veronica password een heel slecht password want die wordt er zo uit gevist.

[Lednov]

ja dat zeg ik toch ook? een woord als password is te generiek, Veronica waarschijnlijk ook, het gaat ook niet om het woord Veronica het gaat om de truuk erachter.

dat password crackers letters vervangen voor cijfers is een feit, zoals gezegd tegen brute force verlies je het altijd.

neem een woord wat niet generiek is (generiek bijvoorbeeld). en ook bijvoorkeur een nederlands woord. Engelstalig zit in de dictionaries.

g3N3r!eK is al heel wat minder gevoelig. (gevoelig - g3V0el1G)

[RagEnigma]

het artikel laat zien dat als je dit met engelse woorden doet dat je dan een probleem hebt.
Doe het dan nog net een beetje anders als je mensen toch tips wil geven.
Pak het word gevoelig en maak er eliggevo en ga daarna je tekens wijzigen of voeligge of maak van 2 woorden 1 woord. generiek + gevoelig wordt dan geneelig of gevoriek en daarna nog eens de tekens veranderen. Dan heb je iets wat redelijk makkelijk te onthouden is en nog veilig ook zeker als je dit met 10 of 12 chars doet.

[Sissors]

Wat je nu hebt gedaan is het wachtwoord wat lastiger in te tikken gemaakt, je hebt hem fractie moeilijker te onthouden gemaakt, en nog steeds even moeilijk om te hacken.

Jij bent niet de enige die basisvervangingen kan doen, die worden bij een dictionary attack net zo hard gebruikt, en die kennen ook de eisen waaraan een wachtwoord moet voldoen, dus alleen die proberen ze.

Stel je voor dat je als wachtwoord "iloveyou" hebt (dat is er ook zo eentje die iedereen gebruikt blijkbaar). Nu zitten we op generieke site met eis dat er nummers in zitten, hoofdletters en speciale tekens. Nu zal voor een enorm gedeelte van de mensen met dat wachtwoord het nieuwe wachtwoord zijn: "Il0v3y0u!". Nu is die lastiger leesbaar op je scherm, maar die dictionary attack heeft hem nog nagenoeg net zo snel (de enige vraag is of alle letter <> cijfer vervangingen worden gemaakt). De sterkte van een wachtwoord zit niet in het aantal speciale tekens en dat soort geneuzel, maar in hoe uniek hij is.

[xFeverr]

Toch vreemd, mijn strato password is toch echt langer dan 8 tekens

[useruser]

Soms wordt zo een wachtwoord gewoon afgekapt na 8 tekens. Jij tikt vrolijk de rest in, maar alleen de eerste 8 zijn van belang.

Is extreem amateuristisch, maar het gebeurd nog steeds.

[Verwijderd]

Op een hoop plaatsen. Waarschijnlijk omdat oude software (zoals crypt(3) in de Unix-software) altijd maar 8 characters deed. Ik verander mijn wachtwoorden niet zo vaak, het is al weer een tijdje geleden dat ik er voor het laatst tegenaan liep.

Ook ergerlijk, passwords die geen leestekens mogen bevatten ! Zoals komma, punt, underscore, hyphen, brackets, etc.

Ook ergerlijk. Websites die voor mij gaan bepalen wat een acceptabel wachtwoord is. Bij de ene site moet je een hoofdletter er in hebben. Bij de andere site twee cijfers. Of een hoofdletter en een cijfer. Bij een andere site mogen de cijfers niet als laatste characters zijn. Soms minimaal 6 characters, soms 7, soms 8. Je wordt er gek van.

Beste oplossing: gewoon wachtwoorden toestaan van alle lengtes. Met misschien een praktische upper-bound van 255 characters of zo. Of 1000. En alle, maar dan ook alle ASCII characters toelaten. Misschien nog mooier om andere unicode charactersets ook toe te laten.

Kan er iemand even een opensource library daar voor schrijven ?
Kan er iemand eventjes een propaganda campagne beginnen ?
Thanks in advance.

[Verwijderd]

En alle, maar dan ook alle ASCII characters toelaten.

Doe dan meteen unicode support "(ಠ_ಠ )"

[Reactie gewijzigd door Verwijderd op 23 juli 2024 01:01]

[Verwijderd]

Dat schreef ik in de zin direct daar achter.

Ik was zelf ooit een programmeur van de oude stempel. Een char is 8-bits voor mij. Ik heb helaas geen ervaring met unicode. En dus heb ik geen idee hoe veel werk het zou zijn om alle passwords unicode te maken.

[Verwijderd]

wtv (what the vaag) - toch 's meer (of juist minder) koffie drinken; die zin totaal niet gezien

[Enai]

つ ◕_◕ ༽つ Give SECURITIDE

[TweakingRens]

Ook ergerlijk. Websites die voor mij gaan bepalen wat een acceptabel wachtwoord is.

Zeker nooit bij AH gewerkt?

Het wachtwoord moet minimaal 8 posities lang zijn
Het wachtwoord mag maximaal 2 keer hetzelfde teken bevatten
Het wachtwoord moet minimaal 2 cijfer bevatten
Het wachtwoord mag geen spatie of # of + of & of < bevatten
Het wachtwoord moet anders zijn dan de vorige 6 wachtwoorden
Het wachtwoord mag niet gelijk zijn aan uw gebruikersnaam
Het wachtwoord mag niet lijken op uw voornaam en of achternaam

En dan moet je het ook nog iedere maand veranderen...

[A Lurker]

Wat een onzinnige set aan eisen. Sommigen begrijp ik wel, maar minimaal 2 cijfers? Alsof een wachtwoord met toevallig 1 cijfer pertinent onveiliger is dan eentje met meer.

En ik onderstreep het verhaal, ik moet mijn keypass ook specifiek vertellen wat voor soort wachtwoord hij moet genereren per toepassing.

Wat ik zelf voor gekke dingen ben tegen gekomen:

- Geen leestekens toestaan, enkel cijfers en letters. Spaties begrijp ik nog, maar !, @, #, $ etc is toch best wel een goede aanwinst voor lastigere wachtwoorden.
- Een maximum stellen van 16 characters, en dan ook nog een foutje maken en daadwerkelijk maar een maximum van 15 toelaten.
- Niet met cijfers mogen beginnen

Om te huilen af en toe....

[Stoney3K]

- Geen leestekens toestaan, enkel cijfers en letters. Spaties begrijp ik nog, maar !, @, #, $ etc is toch best wel een goede aanwinst voor lastigere wachtwoorden.

Leg mij eens uit waarom?

andere karakters gebruiken in dezelfde set (ASCII) maakt je wachtwoord niet makkelijker om te raden. Alleen moeilijker om te onthouden.

Die redenering rust op een (foute) aanname dat een aanvaller alleen maar [Aa-Zz] en [0-9] als mogelijke karakters op een wachtwoord los zou laten.

De lengte van een wachtwoord maakt veel meer uit. Een wachtwoord van 8 tekens is even makkelijk om te raden als het om "Bakermat" zou gaanl, als wanneer het zou gaan om [ESC] [SYN] [NULL] Ka4$ [BELL], om even een zijstraat in de rare ASCII-karakterset te zoeken.

Een wachtwoord wat zegt "Kaas is de bakermat van de maatschappij" is veel moelijker te raden omdat het veel langer is, maar iedere idioot kan het onthouden.

[Cameleon73]

Jouw voorbeeld klopt niet. "Bakermat" zou enorm veel sneller geraden worden, omdat er tegenwoordig gebruik gemaakt wordt van woordlijsten. Jouw 2e voorbeeld [ESC] [SYN] [NULL] Ka4$ [BELL] zal door de huidige password crackers zeer waarschijnlijk niet eens gevonden worden, omdat ze de meeste karakters niet zouden proberen.

Da's ook de reden dat "dihreqon" veel veiliger is dan "B@kerm4t" ... die laatste wordt via een woordlijst + standaard karakter vervanging zo door een computer geraden.

[Stoney3K]

Jouw voorbeeld klopt niet. "Bakermat" zou enorm veel sneller geraden worden, omdat er tegenwoordig gebruik gemaakt wordt van woordlijsten. Jouw 2e voorbeeld [ESC] [SYN] [NULL] Ka4$ [BELL] zal door de huidige password crackers zeer waarschijnlijk niet eens gevonden worden, omdat ze de meeste karakters niet zouden proberen.

Dat ligt natuurlijk even aan de verschillende aanvalsvectoren. Het ene voorbeeld is kwetsbaarder voor een dictionary-attack, maar als het om een brute-force aanval zou gaan, dan zijn ze allebei even sterk of zwak.

De enige verdediging tegen zo'n dictionary-attack is om ook daar het aantal mogelijkheden uit te breiden. Als je in plaats van 1 woord, al 2 woorden gebruikt, is de complexiteit van het wachtwoord al kwadratisch toegenomen, áls een aanvaller al in de gaten heeft dat ie 2 woorden moet gokken, en niet één.

Bij elk woord wat je aan zo'n zin toevoegt, wordt de complexiteit namelijk een factor groter die gelijk staat aan de lengte van de woordenlijst.

[Enai]

Het risico met dat soort wachtwoorden is dat de dienst het wel aanvaardt bij het registreren van een account maar vervolgens niet bij het inloggen. En dan heb je een probleem.

[A Lurker]

Het gaat mij niet om de makkelijkheid om te onthouden, maar om kunstmatige restricties in policies die eigenlijk bedoeld zijn om de gemiddelde consument soort van verplichten om een moeilijk wachtwoord te gebruiken, terwijl er niet echt goed nagedacht wordt over nadelige gevolgen van bepaalde password policies.

Ik gebruik zelf keepass en het probleem is dat het maximum aantal characters vaak laag is, en daarom vind ik het nogal beperkend als je enkel alphanumerieke characters mag gebruiken.

Die redenering rust op een (foute) aanname dat een aanvaller alleen maar [Aa-Zz] en [0-9] als mogelijke karakters op een wachtwoord los zou laten.

Dat is wel erg naief. Dat zou betekenen dat als ik een wachtwoord heb wat enkel bestaat uit ! dat het nooit geraden wordt. Neen, het gaat juist om het aantal mogelijkheden, en dat kun je uitbreiden door a) je wachtwoord langer te maken of b) de aantal mogelijkheden per character te vergroten.

Aantal mogelijkheden is simpelweg een machtsvermenigvuldiging van de twee, dus of je nu je wachtwoord langer maakt, of je laat meer verschillende characters toe, het eind effect is hetzelfde; er zijn meer verschillende wachtwoorden mogelijk.

Hele zinnen zijn zeker makkelijker te onthouden, maar zolang het niet de norm is om hele lange wachtwoorden te (mogen) hebben, begrijp ik niet waarom bepaalde characters uit een character set gewoon verboden worden.

Maar daarbuiten mag van mij ook de maximale lengte omhoog, dan kun je tenminste alle kanten op.

[Reactie gewijzigd door A Lurker op 23 juli 2024 01:01]

[Stoney3K]

Hele zinnen zijn zeker makkelijker te onthouden, maar zolang het niet de norm is om hele lange wachtwoorden te (mogen) hebben, begrijp ik niet waarom bepaalde characters uit een character set gewoon verboden worden.

Ik denk dat dat meer te maken heeft met de manier waarop een wachtwoord wordt opgeslagen en/of verwerkt. Wat eigenlijk weer een resultaat is van brak programmeren: Als je bijvoorbeeld een teken als ', # of $ toelaat, kan het goed zijn dat dat in de back-end gebruikt wordt als speciaal teken (zoals voor het afsluiten van een string).

Nu is dat natuurlijk prima op te lossen door de invoer van je gebruikers op een zinnige manier te coderen, maar maak dat de programmeurs van sommige back-ends maar eens wijs.

[Diamondo25]

Gelukkig bestaan er meestal wel escape functies. Zelfs HTTP escaped de & en = karakters bij een POST aanvraag.

[Enai]

12345678

[Armin]

Met misschien een praktische upper-bound van 255 characters of zo. Of 1000.

Of 20 ...

Dat is namelijk de lengte van SHA1 wat vaak de onderliggende hash is. Langere wachtwoorden heeft dus geen nut, anders dan dat het mogelijk wat entropie toevoegt.

Maar langer dan 12 bij een goed wachtwoord is al twijfelachtig en met 16 redelijk random tekens zit je al in het astronomische gebied dat niemand het ooit hackt.

De lengte van de meeste wachtwoorden is niet het probleem. De voorspelbaarheid is. Langer maken kan dan een indirecte methode zijn om het complexer te maken, maar voor de leek kan het juist de aandacht afleiden.

[Verwijderd]

Het achterliggende algorithme zou best wel eens kunnen veranderen in de komende 100 jaar .... Waarom een random getal als 20 nu kiezen ? Des noods laat je 1000 characters toe, en gebruik je nu alleen de eerste 20. Dan kun je later het onderliggende algorithm veranderen zonder dat de gebruiker er iets van hoeft te merken.

Toen ik nog een kleine jongen was, en het Internet nog gewoon zwart-wit was, was 8 characters al meer dan genoeg voor de toenmalige encryptie en rekenkracht.

Een langer wachtwoord kan voor minder voorspelbaarheid zorgen. Met langere wachtwoorden kun je echte pass-phrases doen. Nu neem je een zin die je makkelijk kunt onthouden, en gebruik je alleen de eerste letter in je passphrase. Ik noem maar iets, bv: Ajax is echt een veel betere voetbalclub dan Feyenoord. Wachtwoord: AieevbvcdF. 10 Characters. Helemaal goed als je leestekens een hoofdletter meeneemt.

Met meer dan 20 letters kun je ook gewoon de hele zin als pass-phrase gebruiken. Hoef je niet meer na te denken of voetbalclub nu een v of vc was.

[Armin]

Het achterliggende algorithme zou best wel eens kunnen veranderen in de komende 100 jaar .... Waarom een random getal als 20 nu kiezen ? Des noods laat je 1000 characters toe, en gebruik je nu alleen de eerste 20

Je mist hoe opslag werkt. Jouw wachtwoord wordt nergens opgeslagen. Enkel de resulterende hash (na salting en multiple rounds).

Jouw 1000 tekens wachtwoord wordt dus opgeslagen in een 20 tekens hash. Als men over "100 jaar" dus besluit meer tekens toe te staan, is jouw 1000 teken wachtwoord dus nog steeds 20 teklens lang, plus dat omdat het hasing algorithme verandert men toch iedereen zijn wachtwoord zal moeten resetten...

Maar vooral dat langer dan 20 teken nihil extra veiligheid geeft indien die 20 tekens random genoeg zijn. Langer is dus niet veiliger.

[Verwijderd]

Nee, maar wel makkelijker. En daar gaat het hier om. En ik weet vrij precies hoe je passwords opslaat in een password file, tyvm.

[JDVB]

Waarom een wachtwoord resetten?

Simpel, je houdt twee tabelletjes bij met hashes in plaats van 1.

omdat het hasing algorithme verandert men toch iedereen zijn wachtwoord zal moeten resetten

Logt een gebruiker in met zijn juiste wachtwoord, dan genereer je de nieuwe hash, verwijder deze uit de oude tabel en gebruik voortaan alleen de nieuwe hash.
Na een X periode zullen alle actieve gebruikers gebruik maken van de nieuwe methode zonder dat deze er iets van gemerkt hebben.

Na de X periode de overige wachtwoorden verwijderen en een wachtwoord reset verplichten. De betrefende gebruikers zullen simpelweg denken dat ze hun wachtwoord niet meer wisten (te lang geleden voor het laatst ingelogd) en een reset link in de email is dan prima.

[Armin]

Na een X periode zullen alle actieve gebruikers gebruik maken van de nieuwe methode zonder dat deze er iets van gemerkt hebben.

Dat is wat ik bedoelde.

MIjn term resetten was wellicht wat verwarrend, maar ik doelde daarmee op het verplicht moeten wijzigen bij inloggen.

[Teijgetje]

Strato vraagt om minimaal 8 en maximaal 12 karakters

[Beuker]

Wat je eens moet proberen is toch maar 8 karakters in typen en kijken of je kunt inloggen. :-)

Bij Sun/Oracle Solaris vroeger kon je inderdaad maar 8 karakters hebben, dus misschien draait dat platform van hun nog wel op Solaris? (Gokje)

[Fluttershy]

Je moest eens weten war voor een rare eisen aan wachtwoorden sommige bedrijven hebben.

De belastingdienst met haar zkaelijk logins bijvoorbeeld. Waar je geen numerieke tekens achter elkaar mag gebruiken. Of met een numeriek teken mag beginnen...

Vodafone had voorheen ook een mooie; er mochten alleen alfanumerieke tekens in staan. Want stel je toch eens voor, een wachtwoord met leestekens... Dat moeten we toch niet willen? Ik vroeg mij direct af waarom niet... En heb toen maar besloten om iedere keer mijn wachtwoord te 'vergeten'; een SMSje met een nieuw tijdelijk wachtwoord leek mij nog het veiligste.

Van het bizarre van de belastingdienst tot het incapabele van Vodafone; sommige bedrijven hebben geen flauw idee wat ze aanmoeten met wachtwoorden. En dat vind ik heel erg jammer en eng.

[JJ93]

Toen ik belastingaangifte wou doen voor mijn eenmanszaak kwam ik daar ook achter ja. Kostte me een aantal pogingen om een wachtwoord te bedenken dat geaccepteerd werd. Wat ik overigens ook niet het veiligste vind is het feit dat je BTW-nummer hetzelfde is als je BSN...

Ik gebruik zelf ook vaak throw-away wachtwoorden bij onbelangrijke sites. Maar helaas komt het redelijk vaak voor dat er een aantal eisen worden gesteld. Bijvoorbeeld een hoofdletter of cijfer, en dan plak ik die er altijd achter o.i.d. Als ik dan terug kom op de site staat dit er bij het inloggen niet bij, en weet ik dus niet meer wat ik precies had bedacht

Ondertussen heb ik zoveel accounts gemaakt op verschillende sites waar van ik nu niet eens de naam meer van weet. Maarja als de database dan een keer uitlekt ben ik de pineut betreft mijn throw-away accounts. Niks voor niks throw-away.. maar toch liever niet.

[HansvDr]

Ik heb het ook met DigiD gehad. Ik kan al die zooi niet onthouden, dus staat het gewoon op papier.

[Stoney3K]

Toen ik belastingaangifte wou doen voor mijn eenmanszaak kwam ik daar ook achter ja. Kostte me een aantal pogingen om een wachtwoord te bedenken dat geaccepteerd werd. Wat ik overigens ook niet het veiligste vind is het feit dat je BTW-nummer hetzelfde is als je BSN...

Wat eigenlijk als éénmanszaak compleet achterlijk is.

Ze promoten overal dat je nergens zo maar je BSN achter moet laten, maar als ondernemer ben je op je correspondentie verplicht om je BTW-nummer te vermelden. Op elke brief die je dus in naam van de zaak schrijft, geef je je BSN prijs.

En een simpele opzoekpoging in het register van de KvK, en je komt net zo makkelijk achter de NAW-gegevens die bij dat BSN horen.

Als iemand mijn identiteit wil jatten hoef ik dus niet eens informatie "weg te geven" of ergens te laten slingeren, dat kunnen ze gewoon doen met informatie die ik als ondernemer toch al verplicht ben om openbaar te maken, samen met een vrij doorzoekbare database.

[Verwijderd]

https://pbs.twimg.com/media/BidQpQRIMAAG7OL.jpg:large

[Weltschmerz]

Dat laatste wachtwoord heeft geen cijfers, hoe kan het dan in gebruik zijn? Joke makes no sense man! ; )

[Armin]

Ik vroeg mij direct af waarom niet... En heb toen maar besloten om iedere keer mijn wachtwoord te 'vergeten'; een SMSje met een nieuw tijdelijk wachtwoord leek mij nog het veiligste.

Je hebt daar mogelijk gelijk je antwoord.

Waarschijnlijk gebruikt men 7bit GSM encoding voor die SMS, en kan het wachtwoord dus ook enkel tekens bevatten die onderdeel zijn van die tekenset.

[Diamondo25]

Knap bedacht, maar een tijdelijk wachtwoord hoeft niet zo veilig te zijn als een door de gebruiker ingestelde wachtwoord (het is immers tijdelijk).

[Verwijderd]

Er zijn er nog meer.

Telenet in België laat ook maar 8 tekens toe.
Je kan bij het aanmaken wel tot 64 tekens invullen maar als je dan enkel de eerste 8 ingeeft is alles ok om aan te melden.

En als je eenmaal toegang hebt dan zit je meteen in iemands persoonlijke mail, kan je bestellingen doen op zijn naam en natuurlijk ook wachtwoorden gaan resetten van andere zaken.
Want iedereen weet dat de nieuwe wchtwoorden naar de persoonlijke mail verzonden worden.

[elhopo]

Er is eigenlijk geen goede manier om nu je wachtwoorden veilig te houden. Ik vertrouw wachtwoord bijhoud tools niet, en stel dat je ergens eens op een vreemde pc moet inloggen en je je wachtwoord tool niet bij je hebt... Voor iedere website een ander wachtwoord is niet te doen, dus heb je al snel dubbele wachtwoorden (voor iedere bestelling die je op internet doet moet je al inloggen met een wachtwoord).

Ik gebruik nu verschillende wachtwoorden voor verschillende levels van veiligheid. Een eenvoudige webwinkel waar ik een keer wat bestel hoeft niet veilig. Email weer wel, en bijvoorbeeld PayPal is dan nog beter beveiligd.

Mijn oplossing werkt ook nog niet altijd even goed, omdat er webwinkels zijn die eisen dat je wachtwoord kleine en grote letters moet hebben, en cijfers en leestekens (en minimaal 10 karakters lang)... Er is wel eens gezegd dat wachtwoorden voor mensen lastig te onthouden zijn maar voor computers juist heel goed. en daar schuilt wel een kern van waarheid in. En al heb je het nog zo goed voor elkaar, als er een achterdeurtje is waardoor de site wordt gehackt kunnen ze nog overal bij...

[.SnifraM]

Ik vertrouw wachtwoord bijhoud tools niet, en stel dat je ergens eens op een vreemde pc moet inloggen en je je wachtwoord tool niet bij je hebt...

Als je er voor zorgt dat je het wachtwoord van je email kan onthouden en 2-factor authentication op je mail gebruikt, kun je voor die enkele keer dat dit gebeurd een forgot password doen en zo alsnog inloggen.

[Reactie gewijzigd door .SnifraM op 23 juli 2024 01:01]

[DonLexos]

Ja of je gebruikt er 1 die je op je telefoon hebt staan (niet auto inloggen instellen om obvious redenen !!)

[Carbon]

Er is eigenlijk geen goede manier om nu je wachtwoorden veilig te houden.

Middels hashing kun je eenvoudig sterke wachtwoorden genereren!
Het enige wat je moet onthouden is de gebruikte methode.

Een paar voorbeelden:

site: amazon.de
gedeeld geheim: mijngeheim

Het password wordt dan:
md5 -s amazon.demijngeheim -> 628ab7ef87033cb1b17ba29b3988fc01

site: 192.168.1.1 (b.v. de router)
md5 -s 192.168.1.1mijngeheim -> 6307ad0dfff31b4d3f2b230edaaab80a

Uiteraard zijn er talloze variaties mogelijk.

[Reactie gewijzigd door Carbon op 23 juli 2024 01:01]

[Blue-eagle]

Die eisen maken het nog makkelijker om te brute-forcen ook. Het programma weet inmiddels dat het wachtwoord in ieder geval 1 hoofdletter, 1 cijfer, en 1 speciaal teken bevat. Dat maakt het heel makkelijk om alle brute-force pogingen die daar niet aan voldoen over te slaan.