welkom123 werkt bij 90% van mijn collega's :'( .
O en ik kreeg laatst commentaar, van onze ICT, dat ik een te moeilijk wachtwoord heb. Moest ff mijn wachtwoord in voeren nadat ze wat gefixed hadden.
Kunnen systeem beheerders de boel niet zo inrichten dat de top 100 van meest gebruikte wachtwoorden en wachtwoorden die ooit door een collega zijn gebruikt niet kunnen? Maar goed zolang ik commentaar krijg dat mijn wachtwoorden te moeilijk zijn zullen we nog wel van dit soort lijstjes houden.

Uitstekend leesvoer voor diegenen die bezig zijn een Microsoft AD password policy (wachtwoordbeleid) op te stellen, gegeven de vaak zeer zwakke hashes (en mogelijke pass-the-hash attacks) die gebruikt worden, vooral omdat dit geschreven lijkt te zijn door pentesters die zo nauwkeurig mogelijk als kwaadwillende aanvallers denken.

De MS defaults (min. 8 karakters, enable complexity en de m.i. vreselijke 42 dagen expiration; zie bijv. de tabel onder http://technet.microsoft.com/en-us/library/cc875839.aspx#ECAA) gaan je dus niet redden...

@Dick99999: goede argumenten voor jouw lange wachtwoorden/pass-phrases!

Het artikel spreekt van "thousands of network penetration tests" (de pentesters waren dus "al binnen", hadden dus lokale netwerktoegang) maar verder wordt niet duidelijk op welke wijze precies Trustwave de meeste hashes heeft verkregen. Als een aanvaller domain admin weet te worden is dat natuurlijk een absoluut drama. Hou echter ook rekening met netwerktools zoals Responder (https://github.com/Spiderlabs/Responder).

Passwords, wat een drama.
2 factor met TOTP en je bent van al die ellende zoals policies en moeilijke memorabele passwords af.
geen post-its meer met passwords.

Ik snap dat je het niet overal in kan gieten maar elke portal die je gebruik kan maken van bijv Google Auth (een TOTP oplossing waarbij NIKS naar Google wordt gestuurd) zal een verademing zijn voor gebruikers.
Geen nare password policies afdwingen, de kracht zit hem in de TOTP en niet in je ()*JKSDhiuu8N(SD&n897SDn7SD7n76SD&6nSD^ wachtwoord.

Er is geen relatie tussen de sterkte van een wachtwoord en de sterkte van de hash. De sterkte van een hash wordt bepaald door gebruikte hashmethode. Op Windows is LMHash heel zwak, NTLM1 redelijk en NTLM2 sterk.

Overigens maakt de sterkte van hash/wachtwoord niet uit voor 'pass-the-hash': zo'n aanval werkt prima met elk type hash (net als met kerberos tickets trouwens).

Huh???
Hoe weten zij dat je pw te moeilijk is?
Gebruiken ze soms keyloggers, proberen ze zelf je pw te achterhalen?
Ik ken geen enkele systeembeheerder die een complex user pw een probleem vindt. (tenzij die user zijn pw steeds vergeet)

Bij mijn vorige werkgever hebben ze zo'n systeem.
Als je een pw wijzigt, wordt deze met een not-done lijst vergeleken. Ik weet alleen niet precies hoe ze het hadden ingericht.

Ik had dit laatst toen ik voor, ik meen kpn, een wachtwoord moest aanmaken. Ik kreeg steeds de melding dat het controle wachtwoord niet gelijk was als het origineel. Totdat ik uiteindelijk merkte dat het controle wachtwoord stopte met typen na 16 tekens.

De regels nalezende mocht ik een wachtwoord van 32 tekens aanmaken. Dat deel werkte, maar wat heb je daar aan als je in het veld, waar je het wachtwoord moet herhalen, maar 16 mag intikken?

Laatst een nieuw wachtwoord bij eBay aangemaakt, die hadden ook al zoiets, en allerlei leestekens accepteerde het formulier ook niet, zonder daar duidelijk over te zijn, erg handig..

Kan dat niet even gevaarlijk zijn als wachtwoorden in klare tekst opslaan? Wat wel zou kunnen is dat het oude wachtwoord aan een lijst wordt toegevoegd, maar het nieuwe wachtwoord toevoegen, is echt gevaarlijk (je schreef ook dat je niet wist hoe het was ingericht).

mij werd gevraagd bij een oud werkgever ( security ) om mijn wachtwoord te verkorten, gezien ze geen passphrases ondersteunden...

Ze vonden het maar raar dat ik meer als 12 karakters had als wachtwoord.

Dat bedrijf heeft (IT-)security zeer hoog in het vaandel staan. Ik denk dat het "gevaarlijke" wel mee valt.
Ze hebben een applicatie draaien dat via ldap een verbinding heeft met active directory.
Pw wijzigingen lopen via die applicatie en die applicatie heeft een database met de not-done lijst.
De pw's (d.w.z. de hash daarvan) wordt alleen in AD opgeslagen en niet in die database.

Overgeslagen:
1/ Data classificatie als de data "public" is waarom wil je dan een user/password policy voeren?
2/ Hoe gevoeliger de gegevens des te beter die beschermd zouden moeten worden. Enkel een password, eng -> 2factor
3/ Password policies moeten hekenbaar nut hebben, anders krijg je de stickertjes op de machines
4/ Service accounts test accounts hebben een andere strategy nodig.
5/ sommige systemen laten je wel meer tekens intypen, maar kappen af op lengte 8 voor de hash
6/ gebruik van zelfgebouwde aanlogsysteempjes omdat dat zo makkelijk lijkt (geen Rbac).

Het gedoe, doet me denken aan dilbert. http://dilbert.com/strips/comic/1998-04-06/?Page=1.
Wanneer gaan we het serieus oppakken en er over nadenken?
Dat in plaats van als een burocraat wat regeltjes proberen door te voeren.

Ik zat bij ICT en typte daar mijn wachtwoord in. Doordat het niet goed was moest ik weer uitloggen zij weer inloggen veranderen etc etc. Na een paar keer te zijn ingelogd kreeg ik de opmerking dat mijn wachtwoord wel erg lang was. Afkorting van een zinnetje met upper en lowercase, tekentjes etc dus af en toe shift. klinkt als of ik een boek tik voor inloggen. Heb een keer mijn wachtwoord aan ICT gegeven (persoonlijk niet via de telefoon) keer daarna "he je wachtwoord werkt niet hoe kan dat?" Wat denk je? Ik kies natuurlijk een ander wachtwoord. Nu resetten ze het wachtwoord maar als ze dat nodig vinden.
Maar goed we krijgen een nieuw VPN systeem en iedereen heeft zijn/haar wachtwoord over de mail gekregen :-). O ja en die is niet aan te passen. Nu heb ik dus een kort (4 tekens) volkomen onlogisch (voor mij) wachtwoord. Gelukkig hoef ik die niet te onthouden staat namelijk gewoon in mijn mail box. Als ik volgende maand een nieuw wachtwoord moet kiezen zal ik ook "welkom123" doen :-( of "wrong" krijgen de melding "password is wrong" :-)

Sorry,moet dit herschrijven

Vooral die expirations zijn een ramp. Vind je het gek dat mensen dan overgaan tot wachtwoorden als "[maand]123!"; als je elke maand verplicht moet wijzigen, en het nieuwe wachtwoord mag niet gelijk zijn aan de 1.424.235 vorige wachtwoorden, dan ga je al gauw voor de hand liggende combo's kiezen.

---- edit: woord gemiddeld aangepast, moest maximaal zijn

De vermeldde top-wachtwoorden zijn tekenend voor de wachtwoord cultuur bij slechts 6% (top 10 opgeteld) van de betreffende mensen mensen, bij een aanname dat 50% van de 576.533 wachtwoorden uniek zijn.

Er is iets mis met het advies/ bevinding van deze firma:
Misconceptions Surrounding Password Complexity & Length [uit het rapport]
Many general users and some IT administrators incorrectly assume that using various uppercase letters, lowercase letters, numbers and special characters in a password will make it more secure. The practice would likely make it harder for a human to guess your individual password, but it does not make recovering the password any more resource-intensive for password-cracking tools. Only increasing the number of characters in the password dramatically affects the time it will take an automated tool to recover the password.

Het hele deel rond 'incorrectly assume' is niet waar en in strijd met wat algemeen door experts wordt uitgedragen. EDIT: Mits en alleen indien de tekens willekeurig gekozen worden (via een wachtwwoord generator van een goede wachtwoord kluis bijvoorbeeld)
En dat is vrij simpel te bewijzen:
- Kraken van een wachtwoord van kleine letters zoals jckcmxsd neemt maximaal (gemiddeld was fout, zie volgende post van Erik) 200 miljard (2E11) gissingen
- Een wachtwoord van willekeurige tekens, zoals &1}h3i5Zis neemt maximaal (gemiddeld was fout) 6E15 gissingen.
Als het eerste wachtwoord in een maand geraden wordt, neemt het andere wachtwoord 30.000 maanden om te raden, ofwel 25 eeuwen!

Dat zij toch 92% van de wachtwoorden gekraakt hebben moet aan LM of de instellingen van NTLM liggen. Dat zijn namelijk de hashes die zij opgevangen hebben. (Het rapport vermeldt niet of het wachtwoord of chalange hashes waren). LM wachtwoord hashes zijn gewoon in minuten te kraken t/m 14 tekens omdat meer dan 7 tekens bijna geen sterkte toevoegt bij windows LM.
Vraag is wat er met de NTLM hashes voor bijzonders was. NTLM (versie1) hashes zijn niet zomaar even te kraken indien meer dan 8 tekens zijn gebruikt. En zeker niet als zo'n 40% van de wachtwoorden 3 soorten teken categorieën gebruikt, zoals klene letters en hoofdletters en cijfers.

Het advies wachtzinnen te gebruiken houdt geen rekening met het feit dat veel sites geen lange wachtwoorden accepteren (een zin van 4 willekeurige woorden is al snel meer dan 20 tekens) en dat de woorden in de wachtzin willekeurig gekozen moeten worden, bijvoorbeeld met een dobbelsteen of goede random generator en een woordenlijst.

26^8 = ca. 2E11, statistisch heb je een match op de helft, dus 1E11.

Uit https://gsr.trustwave.com/topics/business-password-analysis/2014-business-password-analysis/: Inderdaad lijken de onderzoekers te focussen op NTLM hashes. Waar ze die 17.3 miljard vandaan halen weet ik niet, in de sectie "Performance" in http://hashcat.net/oclhashcat/ zie ik 14.789 miljard calculations/second, aan de andere kant haalt een PC met 8 stuks AMD R9 290X naar verluidt maar liefst ruim 174 miljard (1.7E11) NTLM berekeningen/s.

Laat ik van een enkele grafische kaart uitgaan. Omdat er binnenkort ongetwijfeld snellere grafische kaarten zijn rond ik dit af naar 2E10 hashes per seconde. M.a.w., binnenkort kun je in gemiddeld 5 seconden een 8-character lowercase NTLM password hash kraken met een enkele grafische kaart.

Ik zie 33 bijzondere leestekens op mijn toetsenbord: `~!@#$%^&*()-_=+[{]}\|;:'",<.>/? , dus 33 inclusief spatie. (26+26+10+33)^8 = ca. 6E15, maar ook hier geldt dat je statistisch gezien na de helft van de pogingen een match hebt, dus 3E15.

Als het eerste type wachtwoord gemiddeld in 5 seconden geraden kan worden, kan het tweede type wachtwoord gemiddeld in 5*30000 seconden = minder dan 2 dagen geraden worden.

Dit alles gaat ervan uit dat mensen perfecte random password generatoren zijn, maar dat is helaas verre van waar. Mensen kiezen meestal een woord dat ze kennen, en als een "password complexity" policy hen verplicht om hoofdletters, cijfers en bijzondere leestekens te gebruiken, zie je patronen ontstaan zoals in de tweede helft van het Trustwave artikel wordt getoond. In Nederland wordt bovendien vaak afgeraden om karakters te gebruiken die op een Nederlands toetsenbord op een andere plaats zitten, wat de karakterset verder inperkt.

Veel bedrijven geven bovendien suggesties voor het bedenken van wachtwoorden. Als je, naast de bekende menselijke zwaktes, die suggesties verwerkt in een tool als PACK (zie https://github.com/iphelix/PACK), vliegen -bij wijze van spreken- de gekraakte wachtwoorden van 8 karakters je om de oren (ook bij andere dan NTLM hashes, maar volgens http://en.wikipedia.org/wiki/Hashcat zijn GPU's niet goed in het kraken van bcrypt hashes).

Inderdaad en sorry, ik heb gemiddeld geschreven, maar totale aantallen genoemd. Mijn tool SimThrow neemt het (soms gewogen) gemiddelde pas mee bij de berekening van de hersteltijd.

Ik vermoed dat zij in hun advies juist geen random keuze bedoelen, Dan zijn z.g. masked aanvallen (i.p.v. brute force) effectief. Maked haalt het gemiddelde omlaag, maar niet als alles random gekozen wordt. Voorbeelden zijn:
ULLLLLNNN en ULLLLLLN (U=uppercase,L=lowercase,N=number)
zie https://gsr.trustwave.com/topics/business-password-analysis/2014-business-password-analysis/

Alles een reden te meer lijkt mij, om de wachtwoordgenerator uit wachtwoordkluizen te gebruiken en over te stappen op minimaal 10 willekeurig gekozen tekens.
Een weinig aangehaald voordeel van wachtwoordkluizen is, dat deze je tegen een bepaald type phishing beschermen, namelijk tegen voor de mens sterk gelijkende nep site adressen. De kluis herkent het nep adres niet en zal niet tot invullen overgaan.

De capaciteiten van GPU's zijn alleen zeer spectaculair bij zwakke (snelle) hashes. Als een goed afleidingsfunctie wordt gebruikt bij het hashen vam wachtwoorden, is zelfs het monster met 25 GPU's machteloos (zie cijfers voor BCrypt en SHA512Crypt op http://heim.ifi.uio.no/hennikl/passwords12/www_docs/Jeremi_Gosney_Password_Cracking_HPC_Passwords12.pdf