Kwaliteitseisen aan wachtwoorden hangt natuurlijk ook af van de risico's. Voor een netwerk/windows omgeving is de best practice lengte 8 posities, voor de admin accounts is langer aan te raden.

Bij ons is de PW age' op 30 dagen ingesteld. Zelf ben ik meer voorstander van 60 dagen.' Vergeet niet ook 'complexity' af te dwingen, dat is ook gebruikelijk.

Bij ons staat het ook op 30 dagen. Persoonlijk vind ik dat echt kort om telkens weer met een goed paswoord op de proppen te komen. Wat je dan ook veel hoort is dat gebruikers November2013 of iets dergelijks als paswoord gaan gebruiken, wat dan nog veel erger is dan een sterk wachtwoord lang behouden in mijn ogen.

Complexity is inderdaad ook zeer belangrijk om te forceren. Dit in combinatie met een dictionary check is al een aardig eindje in de goede richting. :-)

Theoretisch vind ik de maximum password age te berekenen door een wachtwoord te genereren wat (net) voldoet aan de password policy zoals deze enforced wordt. Daarna kun je onderzoeken hoe lang het zou duren om dit wachtwoord, met moderne middelen, te brute-forcen. De tijd die hiervoor nodig is geeft je een goede indicatie van de maximum password age.

Helemaal mee eens !

Ja, met social engineering kom je ver

Bedankt CSO en Prx, voor de reacties zover.

Een paar overwegingen:

- Enforce password history gaat samen met Minimum password age. Als een gebruiker direct zijn wachtwoord nog een keer kan veranderen zal een slimme gebruiker in jullie geval dat 5 keer doen om weer op het zelfde wachtwoord uit te komen. Zo hoeft hij 1 keer per 90 dagen zijn wachtwoord 6 keer te wijzigen om altijd het zelfde wachtwoord te houden.
- Minimum password length gaat samen met complexity. Zonder complexity zullen veel gebruikers kiezen voor een woord uit een woordenboek. Met complexity kunnen gebruikers niet heel makkelijk een passphrase (ditisbesteengoedwachtwoordhoor) gebruiken.
- De Maximum password age gaat samen met kans op uitlekken. Hoe grote de kans en de gevolgen van het uitlekken van een wachtwoord de korter de duur.

Wij hebben:
Enforce password history: 13 (voorkomt Augustus1, September1, Oktober1)
Maximum password age: 90
Minimum password age: 1
Minimum password length: 8
Complexity: aan
Lockout : 7 pogingen
Lockout time: 15 minuten

Het doel van een maximum password age is voorkomen dat een account ongemerkt langer dan de gestelde termijn misbruikt kan worden. Het verlengen heeft niet direct impact op de mate van beveiliging echter een langer termijn leiden tot een vergrote impact bij een incident.

Let op: in sommige branches zijn dit soort termijn in norm, richtlijnen of wet- en regelgeving vastgelegd. De directie ziet dit vaak over het hoofd, als er voor jou branch ook een norm of richtlijn is die je moet volgen zou je dit aan kunnen dragen bij de directie van jou organisatie.

Wat betreft de lengte van het password, vind ik persoonlijk dat 7 te kort en zou ik liever 10 adviseren, waarbij je afdwingt dat er kleine letter, hoofd letter, cijfer en speciale tekens worden gebruikt (ik zie hierover niks terug in je topic) . Dit advies komt deels wordt uit de mate waarin consumenten computer (cpu of gpu) gemiddeld nodig heeft om de hash van een wachtwoord te bruteforce (uitzonderingen daargelaten, lees; 6 gpu's in een systeem of een distibuted cracking systeem met meerdere computers)

In aanvulling op bovengenoemde suggesties: zorg dat een password policy op alle platformen binnen de organisatie bruikbaar is. Als de organisatie naast de Windows domain controller bijv. nog een Unix-servertje heeft draaien met
een totaal andere password policy, slaat de verwarring al snel toe. Een policy moet zoveel mogelijk platform onafhankelijk zijn.

Inderdaad. Wat je heel veel ziet in het password-policy wereldje is technocratisch gebabbel wat totaal geen rekening
houdt met menselijke eigenschappen. Men ziet totaal over het hoofd dat men met dergelijke draconische regels het
tegengestelde bereikt van wat wenselijk is.
Beter dat de mensen een goed wachtwoord kiezen wat ze dan een half jaar of zelfs langer kunnen gebruiken, dan dat ze
gedwongen worden om het steeds te veranderen, het dan niet meer kunnen onthouden, en dan een escape kiezen zoals
hierboven.

Ik wil graag iedereen bedanken tot zover !
IK neem de bestaande adviezen mee.

Zelf zit ik er aan te denken om ook een demonstratie te geven ( in een virtuele omgeving) d.m.v. backtrack ) of iets dergelijk.

Hebben jullie nog leuke adviezen of programma's met een woordenboek attack ?

Wat dacht je van de 'complexity' eis ;)

Yep, maar vaak zie je mensen dan raar kijken dus vandaar dat ik het maar een beetje simpel probeer uit te stippen. Overigens kennen we die term ook gewoon in het Nederlands, de complexiteit eis ;)

Ik hoop dat de topic starter hier wat mee kan, in elk geval succes ermee !

En dat moet je dus relateren aan de tijd dat je jouw logs bewaart (zie https://www.security.nl/posting/366759#posting366884).

Maar feitelijk vind ik de verplichting om het wachtwoord regelmatig te wijzigen om de door Predjuh genoemde reden, totaal onzinnig (tenzij je mensen verplicht elke dag hun wachtwoord te wijzigen). In veel gevallen ontstaat de ergste schade kort na het verkrijgen van de onrechtmatige toegang, en in die gevallen waarbij het langer duurt is de schade vaak zo groot dat de duur van het misbruik nauwelijks nog iets uitmaakt.

Andere "goede" redenen ken ik al helemaal niet, de nadelen wel. Mensen gaan gewoon een iterator achter hun wachtwoord zetten (SinterPiet&WitteKlaas1, SinterPiet&WitteKlaas2, SinterPiet&WitteKlaas3 ...). Of erger, ze verzinnen iets nieuws en om te voorkomen dat ze het vergeten schrijven ze het op een post-it die onder het toetsenbord of gewoon op de rand van het scherm geplakt wordt. De vraag om te wijzigen komt altijd ongelegen, de kans is groot dat ze, in de haast, een keer hun Hotmail wachtwoord gaan gebruiken.

Iedereen weet dat dit gebeurt, en dat op zich verlaagt weer het gevoel van de noodzaak tot veilig werken: "één van mijn collega's gebruikt welkom01, welkom02 etc., - waarom zou ik moeilijk doen?

Kortom, ik vind dit middel erger dan de kwaal. Laat mensen 1x een goed wachtwoord kiezen en laat ze dat houden - totdat er een bijzondere reden is om het een te wijzigen (zoals gerelateerde beveiligingsincidenten, functiewijziging etc). En maak de gebruiker zo security-aware dat als het een keer noodzakelijk is om het wachtwoord te wijzigen (bijv. na een gerelateerd beveiligingsincident) de gebruiker begrijpt waarom het noodzakelijk is dat zij/hij een nieuw en "krachtig" wachtwoord verzint.

O maar dat werkt zo niet in Windows hoor!
Als je maximum password age bereikt is dan wordt je account niet geblokkeerd, maar kun je nog gewoon met dat
verlopen wachtwoord aanmelden alleen moet je het dan meteen wijzigen.
Ik vind dit een grote makke maar zo is het kennelijk ontworpen, als je dit anders wilt (bijvoorbeeld accounts met verlopen
wachtwoord automatisch locken) dan moet je zelf aan het scripten.

Volgens mij kunnen passwords de prullenbak in en moeten mensen ipv rare policies overstappen of 2 factor auth.
Ik snap dat je service accounts hebt waar dit niet mogelijk voor is, die zou je onder een password policy kunnen laten vallen maar voor dagelijks beheer en gebruik zou ik absoluut opteren aan iets als Kerberos + 2 factor auth en dan lekker met je ticket door hoppen/SSO.

Iedereen bedankt voor zijn reactie !

Ik kan mij niet helemaal vinden in de onderstaande reactie, maar dat kon u niet weten.


Bij deze MKB zijn er gebruikers die werken op een terminal server. Zij loggen vaak in vanaf een privé computer.
Waarop: geen, verlopen en of een verouderde virusscanner staat geïnstalleerd.
Ook zou het zo kunnen zijn dat ze werken met verouderende 3e party software

<zakelijk thuis werken, werkgever moet voorzien(EENS)>

Indien er iemand is die een verbinding maakt vanaf een besmette computer ( b.v. Keylogger, Trojan)
Dan kunnen de wachtwoorden en gebruikersnamen gelogd worden.

Het monitoren van deze loggegevens is dan ook belangrijk. Door de password age te verlagen ,dwing je de gebruiker om hun wachtwoorden te veranderen. Een gebruiker zal nooit uit zich zelf een wachtwoord veranderen
( zou wel moeten, zie infectie)

Uiteraard valt er dan ook wel iets te zeggen over two step verification.



De "Password must meet complexity requirements", stond trouwens wel aan (excuus)

Hierbij helpt alleen een max password age van 1 dag. Als iemand het wachtwoord te pakken heeft gekregen, gaat hij heus geen dagen of weken wachten voordat hij het gebruikt. Als je voor dergelijke zaken bang bent, dan moet je kiezen voor OTP's. Er zijn tegenwoordig heel eenvoudige (en goedkope) methoden hiervoor.



Een gebruiker die zijn wachtwoord vaak moet wijzigen gaat toch met volgnummers werken. Die komt uit op zaken als BjC!+-xm2PWa-1, BjC!+-xm2PWa-2, BjC!+-xm2PWa-3, BjC!+-xm2PWa-4 enz.(Ja, ik gebruik dit soort wachtwoorden standaard)

Of hij schrijft het op een briefje en plakt het op zijn beeldscherm. Of nog mooier: zet het in een tekstbestand zodat hij het met knippen en plakken kan invullen.

Wij zijn na zorgvuldige afweging van kans en impact uitgekomen op 1 jaar voor normale gebruikers. Voor beheerders is de periode korter en ik hoop volgend jaar OTP in te kunnen voeren.


Bovenstaand voorbeeld van een wachtwoord blijkt bijvoorbeeld bij Ziggo niet te werken. :(

Peter

Betere policy:

Enforce password history 0
Maximum password age 999999
Minimum password age 0
Minimum password length 6

Dit is de enige werkende policy. Elke keer dat iemand een wachtwoord moet wijzigen, en vooral als je een vorig wachtwoord niet mag gebruiken, wordt het wachtwoord minder sterk. Mensen zijn niet goed in wachtwoorden onthouden, is het dan niet slimmer om een paar goede te hebben en die te gebruiken?

Daarnaast ga ik jou echt niet mijn bankwachtwoord geven; mijn bank slaat wachtwoorden waarschijnlijk erg veilig op maar jij niet. Dus jij krijgt waarschijnlijk, afhankelijk van hoe belangrijk het account voor mij is en hoe veilig ik het systeem inschat, een veel minder sterk wachtwoord. Als je dat niet accepteert krijg je helemaal een wachtwoord in de zin van "rot op met je policy123" wat ik vervolgens nooit mee gebruik en elke keer een wachtwoordreset aanvraag.

Zie ook deze vraag met antwoord op de security stackexchange:

http://security.stackexchange.com/questions/4704/how-does-changing-your-password-every-90-days-increase-security

Een korte quote daaruit: "There was a study by Microsoft concluding the password expiration policy does not increase the security in real life scenarios."

Dus hou op met deze onzin en stop met het pesten van je gebruikers. Zorg dat hun wachtwoorden goed zijn, geef ze tips, en help ze. Ga ze niet irriteren.

Vergeet niet dat hoe complexer een wachtwoord en hoe vaker je 'm moet veranderen hoe groter de kans dat het wachtwoord op een (spreekwoordelijk) geel papiertje terechtkomt. Bedenk dat dit best eens riskanter kan zijn dan de kans dat iemand de lijst met wachtwoorden te pakken krijgt en er een GPU-aangedreven wachtwoordkraker met gigantische woordenlijst op loslaat.

Met andere woorden, pas goed op dat je het kind niet met het badwater weggooit. Wellicht een beter idee om met de directie om de tafel te gaan zitten en goed na te denken over wat, wanneer, waar, en hoe beveiligd dient te worden, aan de hand van risico en kosten van inbraak en recovery.

Je kan dat kraken bijvoorbeeld al lastiger maken door zorgvuldig de wachtwoordendatabase af te schermen, wat voor een intern bedrijfsnetwerk makkelijker is dan voor, zeg, een website. Dan hoef je de gebruikers daar minder mee lastig te vallen. Ook kun je procedures instellen die ervoor zorgen dat wachtwoorden bij vertrek expliciet uitgezet worden. Zorg bv. dat er in het checklijstje van personeelszaken een richtlijn account uitzetten toegevoegd wordt. Dan is een wachtwoordlimiet ineens minder belangrijk.

Wellicht dat (veel) verschillende richtlijnen voor verschillende groepen gebruikers teveel gevraagd is in het MKB (vrijwel zeker), maar helder hebben wat je beveiligen wil is waardevoller dan kijken wat als best practices gezien wordt -- kan goed zijn dat het personeel die vooral ziet als werknemertje pesten. De beveiliging heeft vaak (terecht) een slechte naam en als het personeel de goedbedoelde regels gaat tegenwerken is het doel onhaalbaar. Tel de gele papiertjes en tel uit je winst.

Samengevat, niet al te veel doodstaren op verlooptermijnen en complexiteit van wachtwoorden. Er is nog veel meer eromheen waarmee je wellicht betere resultaten haalt. Al is dat mensenwerk en lastiger in een loginscherm in te bouwen.

Beste Peter,

Waarom is dit nog "mooier"? Wat is het bezwaar hiervan/-tegen dan? Een "elk tekstbestand lezende trojan (of script op website etc.) die alles doorstuurd naar een server"?!
(Dit tekstbestand heet natuurlijk niet; "Hierin_Staat_Mijn_LoginID_En_Paswoord.txt"!)
Trouwens, hoe knip en plak je vanuit een tekstbestand als je nog moet inloggen op Windows?

Anoniemand

Heb je voorbeelden.

Ik zou niet voor "best practice"gaan. Maar overeenkomstig ITIL-V3 voor "good practice".
Het verschil is dat het eerste de indruk geeft dat het niet te verbeteren is .... klaar. Het tweede eist dat je constant in een cyclus evalueert of het wel goed is. De eist niet te onwerkbaar maar wel doelmatig

Als je "standard of good practice" nakijkt kom je vanzelf op ISO27k ITIL en COBIT. Dat zijn de soort richtlijnen die gewoonlijk gelden. Als je in de richtijnen bij de overheid geinteresseerd bent vind je het via NORA terug. Ook bij de DNB en NCSC zul je het terugvinden.

Als er veel remote gewerkt wordt, is 2-factor authenticatie eigenlijk een must (en vanzelfsprekend een ge-encrypteerde tunnel naar te terminalserver).
2-factor authenticatie is tegenwoordig zonder al te grote kosten te realiseren (kan ook met SMS)
Verder ervoor zorgen dat men voor het benaderen van interne applicaties zoveel mogelijk met single-sign-on kan werken, en dat er gebruik gemaakt wordt van 1 centrale user/pwd bestand (lees Active Directory).
Als er ook op externe applicaties (websites) extern ingelogd moet worden, kan je met lastpass faciliteren dat men sterke en unieke wachtwoorden gebruikt.

2-factor authenticatie lijkt leuk maar ook hier loop je vast op gebruikers die het maar lastig vinden.

Als je RSA-tokens gebruikt worden die bewaard bij de computer, in de laptoptas of in de bureaula (of erger, in een centrale onafgesloten kast met een username erop geplakt).

Bij SMS authenticatie krijg je slimme gebruikers die hun telefoon 'vergeten' mee te nemen of op te laden. Waarna hun manager de IT afdeling de schuld geeft.

Oh, werkte ergens waar de baas niet alleen op kantoor werkte maar ook behoorlijk wat in zijn thuiskantoor deed. En hij had maar een token (van een derde partij redelijk vitaal voor het bedrijf, verdere details niet belangrijk). Dus toen ik wegging, hield hij lekker zelf mijn token (in plaats van het de derde partij terug te geven), want die kon'ie op kantoor laten liggen. Mijn token had niet de administratieve rechten die zijn token wel had, en het scheelde hem gehannes met voortdurend een token bij zich hebben, en met teveel rechten hebben voor de taak waar hij mee bezig was. Puntje om over na te denken.

Zeker computerbeveiligers hebben nogal eens de neiging om zich te verliezen in technische ingewikkeldheden, en te weinig oog te hebben voor hoe te zorgen dat wat er moet gebeuren veilig genoeg gebeurt zonder dat de beveiliging het werk in de weg zit.

"2-factor authenticatie lijkt leuk maar ook hier loop je vast op gebruikers die het maar lastig vinden."

Daar loop je niet op vast toch? Daar lopen die gebruikers wellicht zelf op vast. Maar dat is hun probleem.

Wij gebruiken Vasco tokens die als app op de telefoon geinstalleerd worden en met een key geladen worden.
Die kunnen ze wel in hun bureaula bewaren maar de meeste mensen willen toch bereikbaar zijn dus hun telefoon
nemen ze altijd mee. Die vergeten ze dan ook lang zo snel niet als zo'n fysiek token, geven ze niet aan een collega
die de avond onder hun account wil werken, etc.

"Dus toen ik wegging, hield hij lekker zelf mijn token"

Daar geldt hetzelfde. Als je weggaat lever je je telefoon in of je houdt hem en de key wordt aan iemand anders
gegeven. Of je dan zelf de app wist of niet is niet zo belangrijk want met jouw account werkt ie toch niet meer.

Het is nog steeds zo dat de meeste inbraken in systemen door eigen medewerkers plaats vindt. Zie alleen maar hoe vaak er in ziekenhuizen even naar informatie over een bekende patient gezocht wordt. Of agenten die gebruik maken van codes van collegas voor toegang tot de CIOT database e.d. Daarom is een geel briefje met wachtwoord ook niet zo slim op het werk. Thuis, met alleen je vrouw, kan dat weer wel. Hetzelfde geldt voor wachtwoorden in tekstbestanden. Vaak zijn die eenvoudig in te zien door collegas.

Peter

Google Authenticator
Yubikey

Het is natuurlijk relatief, maar je hoeft geen honderden euro's meer uit te geven voor een OTP met eigen display e.d.

Peter

Ik zou hier in ieder geval toch een minimale lengte van 8 tekens gaan hanteren.

Peter

Het meest favoriete antwoord lijkt te zijn dat je het moet doen omdat het een tijd duurt voor je wachtwoord database is gekraakt. :(

De andere antwoorden lijken me zinniger.

Peter

Allereerst bedankt voor het (gedeeltelijk) beantwoorden van mijn vragen. Maar ik kan het niet met je antwoorden eens zijn. Hoezo zijn die (tekstbestanden met logins en wachtwoorden) vaak eenvoudig in te zien door collega's? Hoe kom je daar nou bij? Niet waar ik heb gewerkt hoor! Nogmaals, hoe knip en plak je vanuit een tekstbestand als je nog moet inloggen op Windows? Dat is namelijk waar het hier over gaat (Windows Domain Controller, remember?), en hoe zou een collega dan een tekstbestand eenvoudig kunnen inzien? En helemaal als deze op een USB stick staat die je niet afgeeft... Blaten als een schaap kunnen we allemaal wel Peter! Verklaar je nader alsjeblieft!

Een kleine toevoeging, maar niet geheel onbelangrijk. Zorg er voor dat je ActiveDirectory de wachtwoorden niet in LM format opslaat. Een hack op je ActiveDirectory zal het kraken van wachtwoorden super vereenvoudigen. Wachtwoorden > 8 char. Dit gezien de beschikbare Rainbow tables. Voor de rest van de policy kan ik me wel in het boven staande vinden. Hoofd en kleine letters. Special char