Het zou natuurlijk netjes zijn als een wachtwoord minimaal 32 karakters lang zou kunnen zijn, maar is dit echt noodzakelijk? Een online account kan niet zo 1-2-3 worden gekraakt mbv een bruteforce (max 5 pogingen per gegeven tijd is het meestal?).

Het is merkwaardig dat Microsoft jarenlang een deel van je wachtwoord negeert zonder dit te vermelden. De kans dat hier in een online situatie misbruik van gemaakt kan worden is natuurlijk niet zo heel groot, maar databases met inloggegevens hebben de laatste tijd nog wel eens de neiging om op straat te belanden.

Wat natuurlijk ook wel gek is, is dat Microsoft een nieuw "Microsoft account" introduceert en daar de beperkingen van de oude situatie in laat zitten. En waarom de lengte van het wachtwoord beperken als deze uiteindelijk toch in een hash beland?

Online accounts worden zo vaak met brute force te pakken genomen. En zo zijn er nog wel meer truukjes om wachtwoorden te pakken te krijgen, het gebeurt dagelijks. En als iemand een wachtwoord van 120 karakters wil, dan moet dat kunnen. Is in ieder geval een stuk veiliger dan abcd1234.

Ter info dit was altijd al alleen liet hotmail voorloper outlook.com inlog via de browser toe door enkel de eerte 16 karakters te rekenen. Het
Enige verschil is nu dat je als gebruiker geinformeerd er over wordt dus al had je jaten terug zelf 50 cijfers ingetikt de eerste
16 werden geteld. Ook de reden dat veel mensen problemen gehad meh pop accounts in mail toevoegen.

Een enkele account niet, nee. Maar er bestaat een omgekeerde methode, waarbij de hacker kiest voor 1 wachtwoord en daarmee probeert in te loggen met een paar miljoen accountnamen. Het enige wat je nodig hebt is een adressenlijst zoals spammers die gebruiken. Ga eerst de lijst af met wachtwoord ABC123, ga dan nogmaals de lijst langs met een tweede wachtwoord, en dan een derde, vierde, vijfde... Laat dit werk uitvoeren door een botnet van 10.000 systemen en zo kun je langzaam maar zeker honderden accounts kraken.
Enige wat je moet weten is wat populaire wachtwoorden zijn. Michael Garibaldi uit Babylon 5 had bijvoorbeeld "Peek-a-boo" als wachtwoord want wie zou dat raden? Na de betreffende aflevering, waarschijnlijk alle hackers die deze aflevering hebben gezien...
Het probleem is vooral de wachtwoord-collision. Meerdere gebruikers die gewoon hetzelfde wachtwoord gebruiken, zonder dit van elkaar te weten. Daarom was de hack in de LinkedIn database ook zo waardevol omdat men er aanwijzingen vond van de meest populaire wachtwoorden.

Als langere wachtwoorden zijn toegestaan, of passphrases zoals bij Google, dan is de kans dat twee of meer gebruikers hetzelfde wachtwoord gebruiken ook vele malen kleiner en is deze omgekeerde hack-aanval dus nutteloos. Maar zolang wachtwoorden een beperkte lengte hebben is deze omgekeerde brute-force methode erg effectief.

Beetje zoals mijn ISP: Telenet. Al jaren is ons wachtwoord niet langer dan 8 karakters. Je kan er ook méér intypen, maar dat wordt gewoonweg genegeerd. Niet te begrijpen... Ik denk dat er heel wat gebruikers blij zouden zijn mochten we 16 karakters mogen gebruiken.

Mijn wachtwoorden zijn standaard langer dan 16 tekens, gewoon uit veiligheid.
MS blundert nu steeds vaker, eerst was door een gebruiker steveballmer@outlook.com aangemaakt, en ook accounts als donotreply@outlook.com en nu dit.
Is veiligheid wel een prioriteit bij Microsoft?

Hoe moeilijk kan het zijn??

1) Gebruik salt and hashing voordat je wachtwoorden opslaat.

2) Sta zo veel mogelijke karakters voor het wachtwoord (min 256) toe en maak visueel duidelijk als iemand meer dan dit aantal karakters heeft ingevoerd.

3) Ga aanmoedigen om langere en complexere wachtwoorden te gebruiken.

4) Ga vooral niet doen alsof alles ok is en vervolgens gebruik je enkel de eerste x karakters van een oorspronkelijk langer wachtwoord voordat je deze in de database opslaat.

Kom op MS, we leven in 2012. We weten inmiddels wel dat 8 karakters niet meer voldoen. Dat het gros van de gebruikers alsnog "password" als wachtwoord gebruikt betekent niet dat je je authenticatie procedure niet op orde hoeft te hebben.

Ik begrijp werkelijk niet dat programmeurs c.q. hun managers er niet bij stil staan.

Jammer, maar wat de meest basale security awareness aangaat wordt er zelfs bij grote software bedrijven ontiegelijk geprutst.

Tuurlijk.
Beweer je nou serieus dat de populaire dubbele wachtwoorden die gevonden worden 16 chars zijn ?

get real.
En , voor zo ver dat zo af en toe het geval zou zijn, dat die opeens boven de 16 karakters wel zouden gaan afwijken ?

Je kunt bijna met zekerheid aannemen dat een populair "dubbel" wachtwoord van zo'n lengte een bekende zin , quote of frase is, en dat als een groter aantal letters meegenomen wordt de gebruikers ervan dus vanuit dezelfde bron verlengen.

Voor de kans op dubbele wachtwoorden moet je zeker niet rekenen met een uniforme verdeling van letterfrequenties, maar met een uniforme mensheid...

Nu deze tekortkoming in het nieuws staat zal het vast niet lang duren voordat
Microsoft dit aangepast zal hebben.
Volgens mij ook PR foutje om aan te geven dat er eigenlijk geen verandering is,
het was altijd al 16 tekens. :)
Gewoon probleem erkennen en zsm aanpassen.

Bedankt, dan kunnen we beginnen met bruteforcen vanaf 17 tekens. ;)

ach ja, microsoft, lang volgehouden dat een bestandsnaam niet langer dan 8 karakters kon zijn. verkeerde bitjes zuinigheid.

Ik pas hem maandelijks aan, dus wens je veel succes.

Gelukkig dat je gelijk even aantoont dat je de 'basale security awareness' mist. Een SHA1 password-hash is 160 bits, een SHA256 (je verwacht het niet) 256 bits. Bits, niet bytes. Meer dan 20 of 32 karakters gaat geen enkel voordeel opleveren voor de resulterende hash. Meer tiepwerk zonder enig zinnig resultaat. Meer opslag, zonder enig meetbaar voordeel qua security. Meer rekenwerk en dus energiegebruik en het maakt geen reet uit.

Om dat te onderstrepen: de huidige 'wedstrijd' voor een SHA-3 algoritme gaat uit van 256, 384 en 512 bit hashes. Met de lessen van MD4, MD5 en SHA-1 in het achterhoofd is er gekozen voor een totaal andere opzet van het berekenen van de hash, niet voor een extreem verlengde hash. Waarom?

Niet waar. Er bestaat ook nog zoiets als entropie. Zie b.v. http://en.wikipedia.org/wiki/Entropy_(information_theory). Jouw 20 karakters hebben een VEEL lagere entropie dan 160 bits, zeker als het wachtworod niet 100% random gekozen is.

De vraag is hoeveel personen daadwerkelijk een wachtwoord hebben van meer dan 16 karakters. Dat aantal is veelal op de vingers van 1 hand te tellen. De volgende vraag is dan: wat is het risico dat het wachtwoord wordt afgekapt op 16 karakters? Het antwoord op die vraag heb ik nog nergens gezien.

Zijn wachtwoorden niet sowieso passé? Meer karakters maken wachtwoorden niet persé veiliger, een combinatie van allerlei karakters wel, en dan hoeft een wachtwoord echt geen 16 karakters te zijn. Daarnaast, hoe langer een wachtwoord hoe meer mensen geneigd zijn om het té simpel te houden.
Wachtwoorden alleen gaan gewoon niet meer werken, als we het gebruiksgemak ook nog een in ogenschouw nemen. Dat zal voor de toekomst toch echt in combinatie met een 2e of misschien wel een 3e factor moeten. Dus niet alleen 'iets wat je weet' maar ook 'iets dat je hebt' of zelfs 'iets dat je bent'. Je ziet al notebooks verschijnen met daarop software waarmee je via 'face regocnition' kan inloggen. Nu stelt dat nog niet zoveel voor, want hou er een foto van jezelf voor en het werkt ook, maar dat neemt niet weg dat het wel een ontwikkeling is waar we naar toe moeten.

@burne101:
Wat ik begrijp in je verhaal is dat je zegt, een wachtwoord is 20 bytes, dat is 20*8bits=160 bits. Als je meer tekens gebruikt dan past dat niet meer in de hash en de rest is daarom overtollige informatie.

Maar het gaat bij wachtwoorden meer om de willekeur, ook wel entropie genoemd. Daarnaast wordt er per teken in een wachtwoord maar een subset gebruikt van de gehele byte.

Een 20 karakter lang random wachtwoord met alleen hoofdletters, kleine letters, cijfers en speciale tekens heeft volgens de wachtwoord generator van KeePass slechts 132 bits aan entropie.

De meeste mensen vinden volledig random wachtwoorden met speciale tekens zeer lastig te onthouden. In de praktijk is meer dan 20 karakters voor encryptie niet ongewoon. Daarnaast gebruiken mensen vaak ook passphrases, hele zinnen om dan aan de 120+bits aan willekeur te komen, moet je een zin van zo'n 19 woorden invullen.

Daarnaast is er in de SHA2 familie ook SHA-512.

De grond van de zaak is dat er minder symbolen gebruikt werden dan de gebruiker ingaf zonder verwittiging.
Dat doe je niet. "probeerditmaartekraken" is redelijk ok, "probeerd" is dat niet. Zo'n verschil wil ik weten.

anonym 19:42 vat het goed samen: waarom??

Deze discussie laat ook wel weer zien dat cryptografie te moeilijk is tenzij voor uitzonderingen, waar ik me niet bij reken.

golem: beginnen vanaf 17 levert nauwelijks iets van winst op totale tijdsduur.

burne101: entropy! zelfs met 1 letter is je hash al full-size, dat is niet het punt: 30 symbolen is 240bits,
meestal geen 240 bit aan entropy

Dan wens ik je daar veel success mee. Hoeveel jaar heb je de tijd ?

Dit impliceert ook dat Microsoft (en anderen) de wachtwoorden ongecodeerd opslaan. Er is namelijk geen enkele andere reden waarom je de lengte zou willen beperkte. Een hash is een hash, of je die nou maakt van een string van 1024 bytes of van 16 bytes. Dus het is wachten op het volgende schandaal..?

Die reden is er wel.
Ergens moet je de invoer afkappen (4G ? ) , gewoon omdat je in de verwerkingsketen geen ongelimiteerde invoer kunt toestaan.
Die lengte moet op alle plekken waar passwords ingevoerd worden gelijk zijn.

Omdat de hash van een string die op 16 karakters afgekapt is, anders is dan de hash van een string die op 32 karakters is afgekapt, maar waarvan de eerste 16 gelijk zijn.

Als je voor nogal grote lengtes kiest, ga je ook problemen krijgen dat client software z'n eigen beperkingen heeft, en mensen die met de ene client (browser) een lang password gekozen hebben, met hun smartphone imap client misschien dat lange password niet KUNNEN meegeven.

Het zijn (als ik alleen maar kijk op dit forum) maar heel weinig mensen die dat zelf snappen. En al helemaal niet als zo'n beperkte client misschien wel een stille beperking heeft (lang veld accepteren, truncated string sturen).

Kortom, met een dergelijke dienst moet je ergens een keuze maken, die door een ongetwijfeld grote en historisch gegroeide codebase consequent doorvoeren, en een hoop afwegingen maken die veel verder gaan dan simpelweg "groter = beter dus MAXINT buffer".

Nee hoor. We hebben binnen ons bedrijf een applicatie die wachtwoorden ook afkapt, maar waarbij de wachtwoorden gecodeerd worden opgeslagen. In ons geval betreft het een legacy applicatie die door de jaren heen functioneel is aangepast, alleen niet de password functionaliteit. Het risico dat misbruik wordt gemaakt van de afkapping is ingeschat als zeer laag, mede doordat de applicatie en het netwerk waarop het draait op meerdere manieren is beveiligd. Als gevogl daarvan komt er geen budget vrij voor het aanpassen van de code. Met name door de leeftijd van de applicatie en de ontbrekende documentatie vereist die aanpassing zoveel uren, dat het risico is geaccepteerd.

Geen idee wat de reden is voor Microsoft. Misschien hebben ze ook een risicoafweging gemaakt.

@burne101 , de passwordlengte heeft geen relatie met de resulterende hash , die heeft een fixed lengte , maar je kun een kompleert document door een hash algoritme heen gooien, vervolgens in het document 1 byte veranderen en de hash kan geheel anders zijn (avelanche effect) . Dus het hashing algoritme beperkt niet de passwordlengte .