Undgå dårlige adgangskoder i Active Directory

Jeg ved ikke om det er til nogen bestemt deltager i kommentartråden eller mit oprindelige indlæg

Jeg er ikke overbevist om at det øger sikkerheden at sætte en udløbsdata for passwords på 60 eller måske 90 dage hvis vi snakker om brugere med almindelig domain user adgang.

Hej Jakob,

Tak for din kommentar. Jeg ved ikke om det er til nogen bestemt deltager i kommentartråden eller mit oprindelige indlæg, men vil blot henlede opmærksomheden på dette indlæg, hvor netop den med udløb behandles: https://www.version2.dk/blog/adgangskoder-670319

Mvh /Jakob

Jeg er ikke overbevist om at det øger sikkerheden at sætte en udløbsdata for passwords på 60 eller måske 90 dage hvis vi snakker om brugere med almindelig domain user adgang. Awareness og vilje er nævnt tidligere i tråden, jeg tror det er nemmere at overbevise brugerne om at de skal lave et godt password hvis de får lov at beholde det i 180 dage. Og så er det vigtigt at lave single-signon på sine systemer så brugerne ikke skal tampe det password ind hele tiden og så igen.

Hvor er det der er behov for at være særlig opmærksom omkring passwords ?

Enig med Jakob i at Fine Grained Password Policies i AD er en overset feature - ok den har sine begrænsninger, men tænk over hvor fedt det er at kunne styre sine interne adgange ud fra hvor høje privilegier de anvender.

Jeg vil mene, at AD servicekonti som ofte er tildelt ekstra (privilegerede) rettigheder bør være i høj risiko vurdering... Hvorfor ?

Vi tildeler (for) ofte disse privilegier og sætter passwordudløbet til uendeligt - mange gange fordi leverandører af softwareløsninger opererer med de højest tænkelige privilegier - så virker alt - og alle er glade. Og - puha - hvem tør efterfølgende røre ved en service konto der driver et vigtigt system - nu er det jo implementeret ??? Og hvad med passwordet? - Det må/kan ALDRIG skiftes!

En QuickWIN løsning:

Den nemme måde at begrænse de umiddelbare risici der er forbundet med service accounts som er medlem af " Domain Admins" eller lign., er at forhindre muligheden for at anvende disse konti kan logge på interaktivt - dvs. så kan de i det mindste ikke misbruges til at logge på via en konsol, RDP, eller anden direkte tilgang til et system.

Dette kan gøres relativt enkelt i Active Directory via en Group Policy, men bør naturligvis testes af inden det slippes løs i et produktionsmiljø.

Password politikker bør helt sikkert være differentierede, således at brugerkonti med flest beføjelser rammes af de skrappeste krav. Der har eksisteret mulighed for at lave fine-grained password plicies i Active Directory i snart 10 år rundt regnet. Det anvendes bare ikke særlig ofte, mærkeligt nok.

To-faktor validering er en helt anden snak - og noget dyrere i praksis i relation til Active Directory og Windows miljøer. Her taler vi smartcards, som dog også kan lave virtuelt disse dage, med anvendelse af TPM-chips på bundkortet. Hvorvidt det i praksis er en ægte 2nd faktor er en anden diskussion.

Vi slipper dog ikke for adgangskoder lige foreløbig... Og så er det heller ikke sværere at lave en stærk kode. At mange misforstår at "stærk" med "kompleks" er en helt anden sag.

Men et-eller-andet sted syntes jeg også de krakilske password politikker skal stå lidt mål med hvad man forsøger at beskytte.

Når man stort set kun har minimal adgang til netværket, så er en politik om ofte skifte password en smule overkill. Var det ikke bedre med to-faktor validering? Man skal stadigvæk huske en besværligt password og derudover indtaste sekundær kode, der skifter hele tiden.

Om det er en elektronisk nøglering, tilsendt SMS eller noget andet, er teknikaliteter.

Det er ikke noget problem at man i ny og næ glemmer sin adgangskode efter ferien, såfremt helpdesk er grundige med at tjekke brugerens identitet inden de nulstiller kontoen (ellers oplagt Social Engineering angreb).

I øvrigt er det ikke svært at lave lange adgangskoder som er nemme at huske - lange koder kan rent faktisk godt være simple!

Og sidste pointe: hellere skrive adgangskoden ned og opbevare den fysisk sikkert på ens person (ligesom ens NemID kort), end at benytte "Sommer2015". Det er ikke en anbefaling, men hvis man absolut skal vælge, så ville jeg vælge den nedskrevne kode.

Nu er det ikke at genere brugerne, at bede dem lave bedre adgangskoder end "Sommer2015" osv.

Jeg kan godt finde på password, der er tilpas besværligt at knække, men selv jeg har mine grænser for hvor let jeg kan huske mit password, når det skal udskiftes efter 60 dage.

Der er da sket mere end 1 gang, at jeg har måtte kontakte IT for at få nulstillet mit password. :-)

... og så ender man til sidst i ren protest med at lave simple passwords, fordi jeg skulle gerne kunne huske mit password efter jeg har holdt en kort ferie.

Alternativt skal jeg skrive mit password ned et eller andet sted, og det kan vi hurtigt blive enige om er en dårlig ide? :-)

genere brugerne:https://cesgdigital.blog.gov.uk/2015/09/08/making-security-better-passwords/Idethttps://xkcd.com/538/

Det problem, som nærværende værktøj adresserer, er, (regelmæssigt) at identificere brugere med de dårligste adgangskoder, nemlig de koder som er blandt de aller første gæt for en angriber. Det er ofte ekstremt nemt at få den første bruger ad denne vej - selv i nogle tilfælde med direkte adgang via ekstern OWA m.v. Det skal selvfølgelig bruges fornuftigt sammen med eksisterende awareness tiltag og kan nemt udbygges/tilrettes efter behag.

Lad mig tilføje, at awareness desværre aldrig kan stå alene. Man er nødt til at kontrollere. Nærværende værktøj udgøre en fast kontrol af om brugerne/admins/helpdesk faktisk gør som man har aftalt.

Fuldstændig enig i, at nyoprettede brugere - og folk der får nulstillet adgangskoder - skal have unikke og stærke adgangskoder. Det er en meget dårlig praksis at starte med Velkommen1, Start123, [firmanavn]+[årstal] osv., som man desværre stadig ser derude. De bør være blandt de adgangskoder man søger efter fast - og konti kan evt. låses, nulstilles eller sættes til at skift kode ved næste login.

Din ide med at analysere på flere forekomster af samme adgangskode/hash er en fin ting lige at inkludere, selvom det måske falder lidt udenfor det oprindelige scope.

Det er trivielt som Domain Admin at dumpe alle AD passwords, og bruge OCLHashcat til at knække dem, gerne suppleret med wordlists.

Har gjort det nogle gange. Har dog altid holdt brugere og passwords i hver sin fil, så man skal kombinere dem for at have en 1:1. Og dermed kan jeg undlade at gøre mig bekendt med den enkelte brugers password.

Men det er ikke der problemet er. Problemet er et awarenes issue. Startende med Helpdesk, som skal lære at brugerne skal tildeles tilfældigt unikke passwords. Ellers ender man med hundredevis af brugere med samme password, om aldrig har været logget på. Eller lås brugere der skal skifte password, men som ikke har været logget på.

Awarenes er langt bedre end regler og løftede pegefingre, og resulterer ikke i samme grad af upopularitet. Knækkede passwords, eller bare tæl antal sammenfaldende hashes, og så har man argumentet til HelpDesk eller en kampagne.

For det store problem er måske ikke en bruger med Sommer2015, problemet er hvis 10, 20 eller 100 brugere har det samme password (uanset hvad det så er). For så bliver det kendt.

Det er jo en glimrende måde at teste restore af AD i lukket setup , det kunne med fordel automatiseres og så derefter tests passwords

:-)

https://xkcd.com/936/http://correcthorsebatterystaple.net/