Ik stuur bedrijven die gebruik maken van absurde wachtwoordvereisten altijd een klacht. Voor mensen die gebruik maken van generators is het vaak gedoe omdat bijvoorbeeld een uitroepteken in het gegenereerde wachtwoord ontbreekt. Moet je weer handmatig gaan prutsen om te voldoen aan de eisen. Voor mensen die géén gebruik maken van generators is het een incentive om waardeloze wachtwoorden te gebruiken. Iets als "Welkom2023!!" kan een goed wachtwoord zijn, maar "52D3329F7EEC565E18BBE05431C1F6C8D187AD724BD198" niet. Het is nog erger als er een maximumlengte wordt gesteld, naast verplicht 3x X, 3x Y, 3x Z. Schei uit met dat soort knoeiwerk.
[Reactie gewijzigd door Klauwhamer op 10 mei 2023 10:29]
Maximale lengte op passwords zouden lijfstraffen moeten opleveren voor de ontwikkelaar in kwestie.
Maximale lengte is soms wel degelijk nuttig. Als een service bijvoorbeeld bcrypt gebruikt om wachtwoorden te hashen, zit je bijvoorbeeld met een maximale input van 72 bytes. De rest wordt gewoon afgeknipt.
Zitten websites op moderne hashes als argon2 dan vervalt dat (je hoeft geen wachtwoord van 4GB) maar migreren van hashingalgoritme heeft vaak niet zo'n hoge prioriteit.
Ja, die achterlijke maximumlengtes van 20 tekens mogen een keer voorbij zijn, maar 64 tekens is eigenlijk ook wel meer dan genoeg.
Fair enough. De nuance zit 'm erin dat een wachtwoord prima tot, zeg, 32 tekens hoeft te zijn. Of 72 bytes in het geval van bcrypt. Of een andere technische limiet maar 20 is écht te kort voor écht veilige wachtwoorden of wachtwoordzinnen.
Niet om dat boven limiet van twintig te verdedigen hoor, maar een deftig uniek wachtwoord van een karaktertje of 12~15 is echt wel genoeg voor dingen die je niet zomaar kan brute forcen zoals websites.
Soms moet je ook nog wel eens gewoon een wachtwoord uit je manager overtikken ergens en dan helpt 't niet als je steeds 't uiterste opzoekt en 64 karakters moet overtikken.
Je kan een debiel lang wachtwoord overwegen voor je wachtwoord manager voor het geval van een gevalletje Last Pass, maar ook daar, als dat in verkeerde handen is moet je sowieso dat en alles wat er in staat vernieuwen. Ook al is je wachtwoord langer dan het cumulatief van de werken van Shakespeare.
[Reactie gewijzigd door Polderviking op 10 mei 2023 14:00]
Niet om dat boven limiet van twintig te verdedigen hoor, maar een deftig uniek wachtwoord van een karaktertje of 12~15 is echt wel genoeg voor dingen die je niet zomaar kan brute forcen zoals websites.
12-15 is wel erg kort als je passphrases wil gebruiken.
13 willekeurige A-Z a-z 0-9 tekens (bv: I49QVBCAiRLnW) geeft ongeveer 1023 mogelijkheden.
Om een vergelijkbare sterkte te krijgen met een passphrase heb je 7 willekeurige woorden nodig uit een woordenlijst van 2000 woorden. bv: write rotten meanwhile mother ornament bucket deed. Kost ongeveer 50 tekens.
Met dat in het achterhoofd is een limiet van 15 wel heel weinig. Terwijl passphrases wel grote voordelen hebben (makkelijker te onthouden, makkelijker te typen).
Maximale lengte is soms wel degelijk nuttig. Als een service bijvoorbeeld bcrypt gebruikt om wachtwoorden te hashen, zit je bijvoorbeeld met een maximale input van 72 bytes. De rest wordt gewoon afgeknipt.
Het nut in deze is dan dat jij als ontwikkelaar mensen beperkt een veiliger wachtwoord te kiezen omdat je een algoritme gebruikt welke niet voorzien in een goede oplossing? Dat lijkt mij juist helemaal niet nuttig maar hooguit een onnodige beperking of workaround
Helaas heb je als ontwikkelaar niet altijd invloed op het hashingalgoritme dat gebruikt wordt, helemaal als je moet kunnen authenticeren tegen verschillende services, maar dan ben je nog wel even bezig.
Wil je samenwerken met LDAP dan moet je voor moderne crypto op Ubuntu Server op zijn minst upgrade naar 22.04, want 20.04 heeft nog geen Argon2. Het is geen SHA256 meer, dat is gelukkig al heel wat...
Eens, en tegelijkertijd vind ik schijnveiligheid van het verplichten van speciale tekens, een cijfer en een hoofdletter net zo kwalijk, terwijl een wachtwoord dat 2x zo lang is en uit random tekens bestaat niet mag.
Die verplichting van speciale tekens zorgt er in 90% van de gevallen voor dat iemand gewoon 1! aan het eind toevoegt en begint met een hoofdletter. Is dat nou echt zo veilig? Nee.
Klopt, het maakt het niet perse veiliger - maar als toevoeging maak je het voor bruteforcing wel een stuk complexer.
Wachtwoorden minimaal 18 karakters lang mét speciale tekens erin vanuit een passwordmanager is nog steeds het beste (als je dan toch gebonden bent aan passwords). In combinatie met MFA natuurlijk. En nog beter is passwordloos (dus beschermen met FIDO of andere methodes) maar dat zal helaas nog wel even duren.
Bruteforcen is zo complex niet, een beetje bruteforcer ondersteund al die trucjes wel. Hoe meer beperkingen je oplegt op je wachtwoord beleid, hoe makkelijker het brute forcen juist wordt.
Neemt een bruteforcer niet standaard speciale tekens mee? Wie gaat er nou alleen via lowercase karakters een password proberen te kraken? Tuurlijk, je kan het proberen een paar minuutjes lang, maar daar kraak je een lang wachtwoord niet mee.
Ligt eraan of je begint met dictionary attacks, of 'well known password lists' .. (Of is het dan eigenlijk geen brute-force meer?)
[Reactie gewijzigd door DigitalExorcist op 10 mei 2023 11:17]
Nog steeds een brute force, maar een iets slimmere. Vergeet de rainbow tables niet, dus salten is ook nodig.
En brute force gebruikt ook truckjes als password, Password, p255w0rd, passw0rd etc. De permutaties met letter/nummer vervanging zitten ook in de password list/common passwords.
De brute force begint niet met a, b, c, .., z, 0, 1, aa, ab, etc...
Verplicht een nummer of een special teken maakt het aantal mogelijkheden kleiner. Als je weet dat er minimaal 1 cijfer in het wachtwoord moet zitten dan hoef je op 1 plek slecht de nummers 0 t/m 9 hoeft te proberen ipv de hele karakter set. Een passphrase zoals correct-horse-battery-staple voelt voor mij beter dan verplichte speciale tekens (die je trouwens ook in een passphrase mag gebruiken)
Als je weet dat er minimaal 1 cijfer in het wachtwoord moet zitten dan hoef je op 1 plek slecht de nummers 0 t/m 9 hoeft te proberen ipv de hele karakter set.
Die positie weet je natuurlijk niet.
[Reactie gewijzigd door Bor op 10 mei 2023 22:27]
Die positie wet je natuurlijk niet. Dat het aantal mogelijkheden afneemt is onjuist.
Stel dat je wachtwoord 4 characters moet zijn en dat je alleen de letters A,B,C en de cijfers 7, 8, 9 mag gebruiken.
Dan heb je 6^4=1296 combinaties.
Als je verplicht 1 cijfer moet gebruiken dan kan je op 3 posities alles gebruiken wat 6^3 = 216 combinatie levert. Op 1 positie staat dan een cijfer en in dit geval zijn er 3 mogelijkheden (ipv 6) dus in totaal 219 combinaties.
In dit voobeeld is het 1296 versus 219 combinaties
edit
6^4? -> Inderdaad helemaal gelijk. Aangepast
[Reactie gewijzigd door MrScotty op 11 mei 2023 00:13]
Ik heb het in mijn voorbeeld over het verschil tussen iets als Welkom01! en 3vjskd94urhjfe9w3hb8ve9r
Wat is veiliger?
Het gaat om password entropy, dus de complexiteit van het wachtwoord als geheel. Dat is dus het aantal verschillende soorten karakters EN de lengte ervan. Maar geen van allen hoeft verplicht te zijn, want je kan met slechts 1 van de gebruikte password policies het gewenste entropy doel bereiken.
Zelfs 30 random cijfers tussen 1 en 4 is veiliger dan Welkom01!
Ik kan me echt opwinden over de simpele gedachtengang van password policy beheerders. Er zijn genoeg studies geweest die bewijzen dat verplichtingen van bepaalde karakters niets toevoegen aan de veiligheid, maar eerder het tegenovergestelde.
Agreed.
Ik kap zelf alleen alles boven 250 tekens af om slow-aanvallen te voorkomen (bcrypt en co vind een half boek niet zo leuk).
Ga jij een systeem ontwerpen waarin wachtwoorden van honderdduizend tekens in passen?
Of 2GB lang? Of langer? Een bovengrens zal nodig zijn. Er is /altijd/ ergens een grens.
Als je bedoelt dat die grens fatsoenlijk hoog zou moeten zijn, ben ik het helemaal met je eens
De complete Lord of the Rings in l33tsp34k als wachtwoord. I'm in.
Plus verplicht 100meter op blote voeten over legoblokjes laten lopen als ze paste functie of automatisch aanvullen door een password manager tegenhouden.
Volgens de Conventie van Geneve is dát niet toegestaan... oorlogsmisdrijven.
Ergste is, Nederlandse banken hebben zelfs nog steeds een limiet... En zelfs max 20...
en 2FA via SMS. De horror.
Hebben ze niet ooit eens een belangrijke website (weet niet meer dewelke) platgekregen omdat gebruikers gigantische strings als passwords ingaven?
Zou me niet verbazen.. onhandig programmeerwerk heb je overal 😜
Ik ben heel blij met de toevoeging, omdat ik nu dus inderdaad niet meer handmatig een uitroepteken achter m'n wachtwoorden hoef te zetten. Dat is overigens wel de enige klacht die ik (af en toe) van websites krijg, verder werkt het een ingebouwde manager in de browser heel prettig.
En voor Firefox zelf gebruik ik een idiote wachtwoordzin die ik goed kan onthouden, maar door geen computer te kraken valt (het eerst komende decennium, dan). Daarmee vind ik dat ik mijn verantwoordelijkheid voorlopig wel genomen heb
Als een bedrijf wachtwoorden eist, waar alleen letters en cijfers gewenst zijn en/of een maximum van 12 tekens, dan ga ik pas klagen. Als zij niet aan mijn wensen kunnen of willen voldoen, dan haak ik af.
Iets als "Welkom2023!!" kan een goed wachtwoord zijn
Nee hoor, het voorbeeld wat je hier aanhaalt is een van de meest gebruikte wachtwoorden (net als jaargetijden etc) en het toevoegen van een uitroepteken op het eind is dermate "menselijk" dat vrijwel elke password cracker hier rekening mee houdt.
Euh? Ik geef dit aan als iets dat mogelijk wél wordt geaccepteerd omdat het aan domme kriteria voldoet, in tegenstelling tot mijn andere voorbeeld ("Uw gekozen wachtwoord voldoet niet aan de eisen, er zijn geen lowercase characters gevonden, probeer het nog maar eens!"). Heeft ook niets te maken met een "password cracker".
Het gaat om de default instelling vanaf deze versie;
Passwords automatically generated by Firefox now include special characters, giving users more secure passwords by default.
Bij dit soort wijzigingen vraag ik mij af waarom dit er überhaupt vanaf het begin af aan al niet in zat. De default zou zo secure mogelijk moeten zijn.
[Reactie gewijzigd door Bor op 10 mei 2023 10:00]
Bij dit soort wijzigingen vraag ik mij af waarom dit er überhaupt vanaf het begin af aan al niet in zat. De default zou zo secure mogelijk moeten zijn.
Vroeger waren er meer (brakke) websites die bepaalde speciale tekens niet toestonden. Een alternatief voor een veiliger willekeurig wachtwoord is simpelweg om het wachtwoord langer te maken.
Wanneer ben je voor het laatst een dergelijke site tegen gekomen? Ik al jaren niet meer. En om daarvoor nu de default onnodig onveilig te maken vind ik ook wat. Dat had ook opgelost kunnen worden door bv standaard 2 wachtwoorden te genereren of de gebruiker een keuze te geven alvorens een ww te genereren met een duidelijke uitleg of waarschuwing.
Wanneer ben je voor het laatst een dergelijke site tegen gekomen?
Vaak genoeg, ik heb laatst toevallig van het gros van mijn online accounts ook het emailadres gewijzigd naar iets unieks, en dan ook gelijk het wachtwoord wijzigen waar nodig. Bij een aantal sites heb je een selectie van speciale tekens die je mag gebruiken, niet gewoon alles en bij een aantal mag je gewoon geen speciale characters gebruiken. Ook bij verschillende sites waarbij je een maximum character lengte hebt. Hier een klein overzichtje van een aantal sites die ik in de laatste 3 jaar bekeken heb (en waar ik een notitie bij heb gezet in de PW manager):
- paypal (8-20 characters)
- tidal (niet alle speciale characters toegestaan)
- mediamarkt (max 15 characters)
- megekko (max 20 characters)
Bij onze lokale bibliotheek was het nog erger. Daar werden tijdens het setten van een wachtwoord bepaalde karakters geaccepteerd, die tijdens het inloggen niet meer werden geaccepteerd. Dat duurde even voordat ik daar achter was.
Ik heb een keer een wachtwoord gehad waarin de combinatie "^o" zat.
Dat is lachen als je je wachtwoord probeert in te typen op een toetsenbord dat ingesteld is als Nederlands. De ^o wordt dan een ô en je wachtwoord is niet geldig.
Ik kwam er pas achter dat dit aan de hand was nádat de helpdesk mijn wachtwoord had gereset
Dat probleem heb je natuurlijk altijd met meerdere van de special characters, ook als je toetsenbord is ingesteld op US International.
Ik kijk gewoon altijd als ik zo'n character intyp, of er een extra bolletje/sterretje in het invulveld bijkomt.
Zo niet, dan heb je de kans idd dat het volgende character een letter met accent wordt. (afhankelijk van die volgende letter).
Is natuurlijk makkelijk op te lossen of rekening mee te houden...
Als je zo'n special character ingetypt hebt wat als accent gebruikt kan worden, en je ziet géén extra tekentje in het WW veld erbij komen, dan eerst ff een keer op de spatiebalk tikken.
Ja, klopt, maar als je jarenlang wachtwoord/computer combinaties hebt gehad waar dat niet speelde, dan let je er niet op. Sinds die eerste keer let ik er inderdaad al op bij het genereren van een ww in bitwarden. Leestekens vóór klinkers = nog een keer genereren
Dat lijkt me dan een goede reden om tekens als '`^"~ niet toe te staan.
Het is al even geleden maar er was een grote Nederlandse bank die de mogelijkheid had om langere wachtwoorden aan te maken dan je kon invoeren, resulterende in niet werkende login. Genoeg rare quirks rondom dit soort dingen.
Wanneer ben je voor het laatst een dergelijke site tegen gekomen? Ik al jaren niet meer.
'Vroeger' is lang geleden. Soms duurt het gewoon lang voordat wijzigingen doorgevoerd worden.
En om daarvoor nu de default onnodig onveilig te maken vind ik ook wat.
Was de standaardinstelling onnodig onveilig, of simpelweg minder veilig als dat het nu is? Blijkt ergens dat het risico daadwerkelijk groter is voor gebruikers die op een ouderwetse manier een willekeurig wachtwoord genereerden voor een online dienst?
Dat had ook opgelost kunnen worden door bv standaard 2 wachtwoorden te genereren of de gebruiker een keuze te geven alvorens een ww te genereren met een duidelijke uitleg of waarschuwing.
Dat is handig als je een technisch onderlegde gebruiker hebt. Maar een gewone gebruiker geef je geen keuze, want daar kunnen ze niet mee omgaan.
Zoals genoemd kan je een wachtwoord met een beperkte tekenreeks ook simpelweg langer maken om eenzelfde beveiligingsniveau te verkrijgen. Voor een wachtwoordmanager maakt het niet uit hoe lang een wachtwoord is.
[Reactie gewijzigd door The Zep Man op 10 mei 2023 10:41]
Ik zie nog genoeg plekken waar bijvoorbeeld $, ?, &, ', ", ` niet geaccepteerd worden. Ik krijg dan meteen twijfels over de implementatie kwaliteit.
Dunea.nl, ongeveer 3 maanden geleden. En bij het wijzigen van het wachtwoord is het geen probleem. Maar als je er daarna mee wil inloggen werkt het niet, net alsof speciale karakters (in ieder geval % en ) ) gewoon stilletjes op de achtergrond worden weggehaald.
Was een uitdaging om dit aan de klantenservice uit te leggen.
Daar zal wel een of andere web application firewall voorzitten, die dergelijke tekens uit form fields stript in een poging te beschermen tegen allerlei injection aanvallen.
Ik werk bij een niet nader te noemen enorm IT bedrijf waarbij ik bepaalde tekens niet mag gebruiken waardoor ik bewust mijn wachtwoord moet verzwakken. Lang leve legacy systemen die geïntegreerd zijn in het bedrijfsbreed SSO platform.
Dat sommige speciale tekens niet mogen? Kom ik nog regelmatig tegen. Zelfde met max characters of dat speciale tekens vereiste zijn. Komt omdat ze niet entropie berekenen maar meer domatische (veelal dommere) eisen er op na houden.
Ik ben voor wachtwoordzinnen ipv arsenaal aan speciale tekens. Helaas max characters komt van bovenstaande problemen naar mijn ervaring nog het meest voor.
Precies dit. Wachtwoordzinnen. Waarom zou je niet gewoon "Godcholera zit ik wéér een lang wachtwoord te typen.." als wachtwoord gebruiken? -- Ik geef nu uiteraard maar een voorbeeld, maar veel mensen weten niet eens dat een spatie óók een karakter is (of liever: hoort te zijn). En deze passphrase heeft een entropie door 't dak.
Ons eigen ING. Maximaal 16 karakters, en het mag een zeer beperkt setje aan speciale karakters zijn, zit er altijd mee te klooien als ik m'n wachtwoord moet wijzigen daar.
Ja, op de ene pagina staat welke tekens je mag gebruiken en op een volgende pagina mag je je dat dan proberen te herinneren.
Ik kwam toevallig gisteren nog een site (grote Nederlandse bank) tegen die speciale tekens verplicht stelt in het wachtwoord maar die ondertussen de * niet toestond. Het eerste wachtwoord dat door mijn password manager was gegenereerd werd dan ook niet geaccepteerd.
Wanneer ben je voor het laatst een dergelijke site tegen gekomen?
30 seconden geleden. Tidal.
Paar dagen geleden, na tijden, weer eens via de website op ING ingelogd. Moest uiteraard mijn wachtwoord wijzigen.. Maximaal 20 tekens en heel veel speciale tekens die niet gebruikt kunnen worden. Heb dus handmatig het gegenereerde wachtwoord van mijn passwordmanager kunnen aanpassen naar wel ondersteunde tekens.
Het is een internationale bank, met misschien wel het belangrijkste wachtwoord, en daar kunnen niet eens lange wachtwoorden met alle tekens gebruikt worden?!
Enkele dagen terug nog 1 tegen gekomen. Je blijft sites tegenkomen die zeer selectief zijn in hun speciale tekens alsook sites die bijvoorbeeld beperken hoe lang je wachtwoord maximaal mag zijn.
Deze maand nog. Bij Mailjet (bepaald geen kleine jongen) werkt het overdragen van een account niet als er een ampersand (&) in het wachtwoord staat. Is uiteraard een fout van Mailjet, maar ik ben er all in all wel een halve dag mee zoet geweest.
ING.nl heeft eisen betreffende de speciale karakters die je kunt gebruiken. Zwaar irritant. Heb een paar keer op de genereer-knop moeten drukken voor mijn password manager een veilig wachtwoord maakte dat ook daadwerkelijk gepakt werd.
Ik kom nog wel vaker dit soort onzin tegen, bij webshops bijvoorbeeld. Een paar keer heb ik daarom mijn bestelling maar ergens anders geplaatst, ik vertrouw een website niet als ze niet om kunnen gaan met een euroteken in mijn wachtwoord.
Ik heb één keer een financiële website gebruikt die wachtwoorden met <>&/; weigerde. Ik wil niet weten waarom ze zich probeerden te wapenen tegen XSS in hun wachtwoordveld, maar dat was gewoon komisch incompetent.
Ik ben het helaas nog genoeg tegengekomen. Ook andersom, dat een specialteken er in moet zitten.
Ik vraag mij wel af of een speciaal teken echt iets toevoegt in de zin van veiligheid. Firefox en andere genereren al een unieke string met cijfers en letters, dus het toevoegen van speciale symbolen lijkt me niet echt nodig.
Is er iemand die weet of het toevoegen van speciale tekens invloed heeft op het algoritme (zoals bcrypt) het veiliger maakt?
Een Windowswachtwoord van alleen kleine letters is snel te achterhalen met een rainbowtable, met speciale tekens er in lukt het niet.
Maar, en ik hoop, dat de meeste websites/apps toch een beter algoritme gebruiken om wachtwoord te hashen.
Gisteren
12-20 characters lang
2+ kleine letters
2+ hoofdletters
2+ cijfers
2+ speciale tekens
Maar toen was mijn wachtwoord niet goed omdat ik een # had gebruikt en dat mocht niet. Er werd ook meteen bij vermeld dat enkele andere tekens niet mochten. Al die tekens eruit gesloopt en vervangen met andere, maar mijn wachtwoord was nog steeds niet goed omdat er blijkbaar nog een reeks van speciale tekens was die niet mocht, wat nooit eerder verteld is. Uit wanhoop maar van alle leestekens uitroeptekens en vraagtekens gemaakt.
Extra opties toevoegen is niet altijd beter voor de ervaringen van gebruikers. Volgens mij zijn 2 letters langer meer mogelijke wachtwoorden dan de tekens toevoegen. Er is dus geen reden om te stellen dat wachtwoorden minder veilig zijn als er geen speciale tekens in zitten. Uiteindelijk gaat het om de ingestelde bits die de generator aanhoudt.
Het is op dit moment natuurlijk gewoon irritant als je op een website zit waar een speciaal character in het wachtwoord moet staan. Had het artikel moeten lezen maar vond het een te lange tekst
[Reactie gewijzigd door Guus... op 10 mei 2023 10:28]
MoneYou had dergelijke beperkingen er gewoon in zitten tot aan het einde van ze. Ook de minimale en maximale lengte stond gewoon in de foutmelding vermeld. Langer dat 12 karakters (uit mijn hoofd) kon niet... en dat terwijl juist langer het al een stuk minder vlot te bruteforcen maakt.
Ik kom het sporadisch wel nog tegen. Vind het wel altijd heel vreemd maar het gebeurd nog. Wel veel minder vaak dan vroeger.
Vorige week nog. Ze bestaan nog.
Helaas zie ik het nog te vaak, maar het neemt gelukkig wel snel af.
Hopelijk gaan ze niet te snel en laten ze whitespace aan het begin / eind niet toe. Die characters moet je gewoon weghalen voordat het wachtwoord wordt gechecked of je moet als site-maker een duidelijke foutmelding in je front-end genereren.
En dan heb je sites met de combinatie "maximaal 8 tekens" en "enkel alphanumeriek"... Ik denk zelfs dat mijn ISP standaard zo'n wachtwoorden genereert als je je wachtwoord reset.
Bij resetten van wachtwoorden is het niet bevordelijk voor de eindgebruiker als je daar ook random speciale tekens doorheen haalt.
De voorkeur gaat b.v. ook uit dat je 0 en O of l en I en soortgelijke karakters niet beide gebruikt.
Intune/Endpoint doet ook default 4 letters 3 cijfers bij ww resets. Bedoeling is dat het een soort one time pin is, want je wijzigt het (normaal) direct. Dan hoeft het niet zo heel complex.
Complexe wachtwoorden gebruik je vooral mocht de hash of het ww zelf lekken.
Bij gegenereerde wachtwoorden zonder speciale tekens heb je 62 tekens om mee te werken. Met speciale tekens krijg je er 32 bij. Maar met een random wachtwoord dat lang genoeg is heb je meer dan genoeg entropie.
De reden om speciale tekens te eisen in een wachtwoord is om mensen te dwingen hun wachtwoord wat verder weg te brengen van standaard woorden en lettercombinaties. Niet om de entropie te verhogen, die is groot zat bij 12 tekens van bijna 6 bits elk.
De reden om speciale tekens te eisen in een wachtwoord is om mensen te dwingen hun wachtwoord wat verder weg te brengen van standaard woorden en lettercombinaties.
Als je puur naar de door jou aangedragen reden kijkt (waar ik het niet direct mee eens ben gezien wachtwoorden nogal eens op lengte worden beperkt) krijg je het gedrag waarbij mensen standaard bijvoorbeeld elk wachtwoord door een uitroepteken laten volgen.
Als je speciale tekens toevoegt, verandert Welkom2023 in Welkom2023! en ben je geen stap dichter bij. Klassieke cracktools hebben zelfs een speciale modus die eerst leestekens aan het begin en einde probeert (vaak ook met een woordenboek om sneller te zijn) voordat ze compleet willekeurige wachtwoorden gaan brute forcen. Dat werkt met een consumenten-GPU nog verrassend goed.
Om dit tegen te gaan zijn er tools (onder andere één van dropbox die je zo van Github kunt plukken) die een inschatting maken van hoe veilig je wachtwoord is. Daar zit een heuristiek op die dingen als willekeurigheid, jaartallen, speciale tekens op het einde, en meer van dat soort regels meeneemt.
Het is niet de bedoeling om daar super strikt mee te zijn (verbied speciale tekens op het einde en je maakt wachtwoorden alleen zwakker) maar zo kun je redelijk effectief alsnog voorkomen dat iemand een uitroepteken achter naam en geboortejaar zet als wachtwoord.
Inderdaad. Voor de passwordgenerator maakt het niet uit of die een A, b, Z of _, * of { genereert.
Ik weet dat het vandaag de dag niet meer zou moeten uitmaken, maar oudere interfaces/websites kunnen niet overweg met speciale karakters.
Langs de andere kant: als een form wel speciale karakters aanvaard, dan zal het theoretisch gezien even moeilijk zijn om AaA te bruteforcen als !è§
Als de interface niet overweg kan met speciale tekens die binnen de Latin-1 reeks vallen, is het beter om gewoon geen account te maken.
Dat oude bagger niet met unicode overweg kan en flipt als ik een ♿ in mijn wachtwoord zet is één ding, maar een * of een { moet gewoon lukken.
ik spreek niet enkel over websites, maar ook over webinterfaces. Zo ken ik toestellen die zelfs enkel cijfers aanvaarden. Ja ze zijn EOL, maar als het bedrijf ze niet wil vervangen dan is het makkelijker gezegd dan gedaan om geen service meer af te nemen/verlenen.
Wow. Dit is letterlijk het punt van dit artikel maar wordt niet aangehaald door Tweakers.
Fijn dat Firefox dat doet. Maar wat belachelijk blijft, is dat eenmaal het wachtwoord opgeslagen in Firefox, enkel het wachtwoord van Windows of welk ander besturingssysteem het enige wachtwoord is wat de wachtwoorden zelf beveiligt. Heb je in Windows toegang toe iemands account, kun je eenvoudig alle opgeslagen wachtwoorden zien. iOS/wachtwoorden en Windows/Edge doen dat toch echt een stap beter.
Gebruikersafhankelijk lijkt me. Je hebt immers de optie een 'masterpassword' in te stellen. Hiermee kan 'iedereen' niet zomaar al je wachtwoorden zien dus.
Maar die optie is geen default. Is een hacker eenmaal binnen, dan keert de hele wachtwoordservice van Firefox zich tegen de gebruiker, zonder dat hoofdwachtwoord.
Is een hacker eenmaal binnen met een remote exploit dan hoeft hij alleen maar even te wachten totdat je inlogged bij je password manager en dan heeft hij dat password ook.
Merkte het inderdaad in de Nightly. Ik gebruik alleen Firefox voor password management, ook op Android. Helaas werkt het op Android nog vaak een beetje buggy, en dat is al jaren zo.
Ik loop hier vaak tegenaan met Firefox inderdaad. Het zou ook fijn zijn als ze de wachtwoord-vereisten van een website automatisch kunnen toepassen.
Iets als een passwordrules-attribute: https://github.com/whatwg/html/issues/3518
What's next. Apple die een belfunctie toevoegd aan de iPhone?
Ik vind het voldoende nieuwswaardig omdat ze er niks mee deden.
Ik ben hier iig blij mee. Ik hoop overigens ook dat we de eisen kunnen instellen.
bijvoorbeeld 2 cijfers, 1 speciaal teken 10 lang ofzo.
Vind het redelijk schokkend dat Firefox dit niet standaard al dééd eigenlijk......
Ik snap het wel, er zijn best wel veel sites die niet álle tekens toestaan maar slechts een subset. Er zijn zelfs een hoop maar een vrij kleine set toestaan. Als je daar niet al te veel mee te maken wil hebben moet je de meeste "vreemde" tekens uitsluiten en blijven er maar een handvol tekens over. Die gaan het verschil ook niet maken.
Een lang wachtwoord is dan veel belangrijker dan je tekenset uitbreiden met een paar tekens. Aangezien het ww toch door de computer wordt beheerd en niet door een mens hoeft te worden onthouden is het niet nodig om het ww kort te houden.
Ik heb doorgaans het (niet-onderbouwde) gevoel dat een site waar je géén speciale tekens als wachtwoord in kan voeren, vatbaar is voor (SQL)injections. Zo van.. hey als mijn password ' | DROP TABLE is, gaat er wat stuk.
... blijven er maar een handvol tekens over. Die gaan het verschil ook niet maken.
Een lang wachtwoord is dan veel belangrijker dan je tekenset uitbreiden met een paar tekens.
Zelfs als je alle (ASCII) leestekens mag gebruiken zet het bijna geen zoden aan de dijk. Wachtwoord lengte is echt veel belangrijker.
Als je een wachtwoord hebt van 10 willekeurige (hoofd)letters/cijfers, dan helpt het toevoegen van alle ASCII leestekens evenveel als het toevoegen van één extra (hoofd)letter/cijfer. That's it.
10 willekeurige letters/cijfers/leestekens geeft 9410 ≈ 1020 mogelijkheden.
11 willekeurige letters/cijfers geeft 6211 ≈ 1020 mogelijkheden.
Eens, maar Apple doet het bijvoorbeeld ook niet. Al die wachtwoorden zijn eigenlijk altijd A-z+0-9 in format xxxx-xxxx-xxxx-xxxx. Eigenlijk bizar dat het zo werkt. Het zal allicht veilig zijn, maar waarom niet extra veilig?
Geen idee waarom dat is. Ik gebruik sinds een jaar of wat de (self hosted) BitWarden, zowel op iOS als Linux als Windows. Die doet dat netjes wel..
Hoewel ik zelf nu langzaam overstap op een FIDO token. Passwords zijn sowieso oldskool en mogen uitgefaseerd worden wat mij betreft...
Als ik deze tabel bekijk https://images.squarespac...97d1ab78/image-asset.jpeg, dan is jouw paswoord binnen het uur gekraakt. Lengte lijkt mij een meer belangrijke factor dan speciale tekens.
Even een verduidelijking van je post / de tabel: dat gaat er natuurlijk wel vanuit dat je kan brute-forcen, i.e. dat de database met gehashde passwords wordt gelekt. Wachtwoorden proberen over een netwerkverbinding gaat 'm niet worden.
[Reactie gewijzigd door uiltje op 10 mei 2023 12:11]
Het gaat daarnaast ook uit van nogal zwakke encryptie.
As a result, the 2023 Hive Systems Password Table is based on the power of the RTX 4090 with 12 GPUs against MD5.
MD5 wordt toch al sinds sint-juttumus als "kapot" beschouwd.
Kennelijk komen ze het nog wel veel tegen, en is dat het argument voor dit uitgangspunt.
Niet heel gek beredeneerd. Maar dat tabel is dus bijvoorbeeld niet zomaar als zodanig toepasbaar op je uitgelekte LassPass wachtwoord/kluis.
[Reactie gewijzigd door Polderviking op 10 mei 2023 14:36]
Voor wachtwoord hashing is MD5 nog prima geschikt hoor, aangenomen dat je meerdere iteraties (i.e. een password hash) gebruikt, want anders is elke hash onvoldoende. Collision resistance is inderdaad al tijden stuk, maar daar gebruik je het hier niet voor. Dat is een probleem bij bijvoorbeeld handtekeningen.
Ja dan moet je wel lezen hoe ze die tabel berekend hebben, want daar zitten nogal wat kanttekeningen aan. Ze gaan er namelijk van uit dat:
- De aanvaller je wachtwoord hash heeft buitgemaakt, een offline aanval dus.
- De hash-functie in kwestie is MD5, dat zou niemand meer mogen gebruiken (maar komt in de praktijk helaas wel nog voor)
- De aanvaller heeft (via een cloud-platform) de beschikking over 10000 (!) Nvidia A100 Tensor Core GPUs (dat is zo'n €100M aan hardware)
Begrijp me niet verkeerd, het is een waardevol perspectief om te zien hoe snel wachtwoorden gekraakt kunnen worden onder die omstandigheden. Maar het is niet echt een realistisch model voor bv Kevinp's tweakers.net wachtwoord.
[Reactie gewijzigd door deadinspace op 11 mei 2023 15:10]
Je kan erom lachen, maar raar genoeg heeft Apple geen belfunctie op iPads met simkaart.
Wat ik niet snap is waar al die sites zich mee bemoeien. Die reeks aan tekens zijn gewoon getallen. Wat boeit het een bot of hacker wat dat getal betekent.
Is dit niet 100÷ geneuzel over schijnveiligheid! 10 tekens zijn 10 tekens.
Wel blij dat Firefox dit eindelijk fixt
[Reactie gewijzigd door svideo op 10 mei 2023 11:16]
Ho ho, niet overdrijven he? Je wilt echt geen wachtwoorden die met een whitespace beginnen bijvoorbeeld, of die Unicode onprintbare tekens bevatten. ASCII alfanumeriek + speciale tekens is - in ieder geval voor landen met het Latin-alfabet prima.
Maakt toch al niks meer uit. Ga in België je wachtwoord in typen en je faalt!
Iedere nitwit blijft toetsenborden toevoegen met de 'taal' Nederlands.
Mijn vorige it-er kocht braaf voor mij een laptop met een Engels toetsenbord. Heerlijk!
Toch een wachtwoord met 3 verschillende blanks . Of allemaal emoticons. Leuk toch.
Lijkt super veilig.
Wat ik niet snap is waar al die sites zich mee bemoeien. Die reeks aan tekens zijn gewoon getallen. Wat boeit het een bot of hacker wat dat getal betekent.
In mijn ervaring is het een opeenstapeling van onderliggende problemen waardoor er allerlei moeilijke randgevallen ontstaan omdat bepaalde tekens een speciale behandeling krijgen. Uiteindelijk besluit de programmeur maar om al dat soort tekens uit te sluiten.
Het begint vaak al met een gebrekkig systeem om inkomende data te verwerken. Daar zitten vaak hele naieve functies achter die aannames doen als "tekst staat altijd tussen aanhalingstekens', of andere regels over speciale tekens. Een modern applicatieframework heeft daar geen probleem mee maar lang niet alle software maakt daar gebruik van. Vaak proberen programmeurs zelf even een wachtwoord-systeem of invoerframework op te zetten omdat het makkelijk lijkt. Tegen de tijd dat ze ontdekken dat het niet zo is blijkt het hele systeem er om heen te zijn gebouwd waardoor veranderen moeilijk wordt.
In plaats daarvan proberen ze achteraf wat fixes toe te voegen, maar omdat ze ze fundamenteel een verkeerde aanpak volgen helpen die fixes nauwelijks maar maakt het de boel wel steeds complexer met nog meer randgevallen. Vervolgens worden alle vreemde tekens uitgesloten om het aantal randgevallen te verkleinen.
Een site met veel wachtwoordregels is voor mij dus bij voorbaat verdacht. Het suggereert dat er software gebruikt wordt van minder hoge kwaliteit, of het is ingericht door iemand die het allemaal niet echt goed begrijpt en niet zelfstandig na heeft gedacht over de behoeftes en de gevolgen daarvan.
Het is ook een beetje te veel gevraagd dat iedere programmeur/beheerder dat soort zaken in detail begrijpt en vandaar het advies om zoveel mogelijk gebruik te maken van standaard componenten en niet zelf het wiel opnieuw uit te vinden. Alles rond security is moeilijk, net als alles rond het verwerken van inkomende data. Wees niet zo naief te denken dat jij wél alles goed doet wat hele teams aan programmeurs jarenlang over het hoofd zien.
[Reactie gewijzigd door CAPSLOCK2000 op 10 mei 2023 11:38]
Naam Getal Uitroepteken dat is de samenstelling van de meeste wachtwoorden in Nederland.
Aldus een paar weken geleden geopperd in het TV programma KASSA!.
Dat speciale teken wordt nu dus ook gegenereerd door FF. Alleen staat deze niet vanzelfsprekend achteraan.
Daar moest ik gelijk aan denken. En als systeembeheerder jaren terug ook vaak de meest vreemde redenaties te horen gekregen over hoe een veilig wachtwoord samengesteld dient te worden.
Dan hadden ze, het management, in het weekend weer een of ander artikel gelezen. En of ik dat even wilde implementeren. Ja ja. Twee of zelfs drie traps verificatie is belangrijk. En authenticatie en autorisatie. Wie je bent en wat je mag.
Zelf ben ik meer van de parafrases. Bijvoorbeeld MijnMoederMaaktLekkereKippensoep.
Of KroketMeloenStoelGang Dus een frituursnack, fruit, meubilair en deel van een woning.
[Reactie gewijzigd door pentode op 10 mei 2023 12:03]
Ow ik dacht meer aan de methode "StoelGang" na het eten van een MeloenKroket
Maar on-topic: Vreemd dat dit er al niet heel lang standaard inzit. Dit mag toch al wel lange tijd als 'standaard' beschouwd worden.
[Reactie gewijzigd door rdfeij op 10 mei 2023 11:45]
Een ideale manier om je wachtwoord te onthouden ;-) Tegenwoordig kan dat met wachtwoordmanagers.
Maar vroeger zat werkplekken gezien waar de wachtwoorden op post-it werden geschreven. Voor in de agenda. Of onder het toetsenbord.
Of elke maand een nieuw wachtwoord. Dan werd er weer wat achter geplakt. KroketMeloenStoelGang1
Ja, on-topic waarom dit niet de standaard was. Misschien zagen ze het nut van speciale tekens (ook) niet in.
[Reactie gewijzigd door pentode op 10 mei 2023 11:53]
MijnMoederMaaktLekkereKippensoep is minder sterk omdat het een zin uit een boek kan zijn. Het is beter om willekeurige woorden te gebruiken.
de wachtwoorden die ik aanmaak voor bv banken en webpagina’s waar mijn creditcard en naw gegevens zijn opgeslagen zijn redelijk complex en beginnen met een code die nergens staat opgeschreven. Ik kan dus niet een firefox, safari of chrome deze laten bewaren want die slaat ook die code op. Jammer dat je dus niet kan kiezen om bv de eerste 5 karakters eruit weg kan laten.
Verder is mijn ios wel snel te achterhalen (meekijken) maar om op ios mijn appleID wachtwoord aan te passen is weer niet toegestaan en ook sommige notes openen zal ook niet snel lukken
Op dit item kan niet meer gereageerd worden.
Author: Mrs. Jennifer Washington
Last Updated: 1698950642
Views: 1155
Rating: 4.7 / 5 (34 voted)
Reviews: 83% of readers found this page helpful
Name: Mrs. Jennifer Washington
Birthday: 1999-07-01
Address: 123 Janet Common Apt. 363, Sherylberg, CT 77478
Phone: +3685792570123311
Job: Air Marshal
Hobby: Beekeeping, Magic Tricks, Playing Guitar, Origami, Cross-Stitching, Orienteering, Sculpting
Introduction: My name is Mrs. Jennifer Washington, I am a dedicated, fearless, Adventurous, enterprising, unguarded, radiant, important person who loves writing and wants to share my knowledge and understanding with you.