Ingen i driften bør kunne se brugernes passwords, og det skal den, der gennemgår miljøet, heller ikke. Alligevel kan det kontrolleres, om de passwords, der bruges, står på en liste over lækkede eller svage koder. Metoden er at sammenligne hashværdier: den form, passwordet gemmes i, holdes op mod hashværdierne af de kendte dårlige passwords.
Metoden er beskrevet i vejledningen til de statslige tekniske minimumskrav. Hvad der skal aftales, før den køres, beskriver ingen af kilderne. Det afsnit i artiklen er praksis.
Hvad minimumskravene siger
Statens myndigheder kan ikke fravige de tekniske minimumskrav. Private virksomheder kan bruge dem som sammenligning, og netop på dette punkt er de usædvanligt konkrete.
Krav 12 siger, at der tjekkes mod en liste over lækkede eller svage passwords ved alle oprettelser og ændringer af passwords, eller mindst én gang om måneden, eller begge dele. Konti med lækkede eller svage passwords tvinges til at skifte ved næste logon, og ejere af systemer og servicekonti orienteres med henblik på skift. Alle brugerkonti i de centrale brugerdatabaser er omfattet, herunder administrator-, system- og servicekonti.
Vejledningen til kravene, afsnit 3.4, beskriver, hvordan det kan gøres:
- Sammenligning af hashværdier · et værktøj eller et script sammenligner hashværdien af de anvendte passwords med en liste over lækkede eller svage passwords.
- Listen hentes ned · så kontrollen sker på eget system, uden at passwords deles med en tredjepart. Vejledningen peger på en offentligt tilgængelig liste over lækkede passwords.
- Lokale svage passwords tilføjes · vejledningens eget eksempel er myndighedens navn efterfulgt af tal. For en virksomhed svarer det til firmanavnet, byen eller produktnavne med tal efter.
- Tjek ved oprettelse og ændring · virker også, hvor passwords gemmes med salt, fordi kontrollen sker, mens passwordet stadig er kendt.
SAMSIK anbefaler i sin vejledning om passwordsikkerhed fra 2026 en negativliste mod udbredte passwords. Det er samme tanke, set fra den side, hvor nye passwords afvises, før de tages i brug.
To slags kontrol
Vejledningen beskriver i virkeligheden to kontroller, der supplerer hinanden. Den ene sker løbende, når et password oprettes eller ændres, og forhindrer, at et dårligt password kommer ind. Den anden sker med jævne mellemrum på de passwords, der allerede er i brug, og finder dem, der er blevet lækket, efter at de blev valgt.
En gennemgang spørger til begge. Den første påvises med opsætningen af den funktion, der afviser passwords. Den anden påvises med resultatet af seneste kørsel: dato, antal kontrollerede konti, antal fund og hvad der skete med dem.
Hvorfor kontrollen er værd at køre
CISA og NSA beskriver i deres rådgivning om hyppige fejlopsætninger en vurdering, hvor deres hold på 12 timer knækkede over 80 procent af brugernes passwords i et Active Directory. Det er én vurdering og ikke en statistik for miljøer i almindelighed. Den viser, hvad der kan ske, når passwords er korte og forudsigelige, og den er grunden til, at CISA lægger vægt på længde.
Kontrollen mod listen svarer på et mere afgrænset spørgsmål: står nogen af jeres passwords på en liste, angribere også har?
Aftalen før kontrollen
Ingen af de læste kilder siger, hvilken aftale kontrollen kræver. Det følgende er praksis og bør tilpasses jeres egne regler.
Kontrollen arbejder med hashværdier af passwords, og de er følsomme oplysninger i sig selv. Derfor er det almindeligt at aftale skriftligt, før kontrollen køres:
- Hvem kører kontrollen · helst driften selv, på eget system, så hashværdierne ikke forlader miljøet.
- Hvordan hashværdierne opbevares undervejs · og at de slettes, når kontrollen er færdig, med dato for sletningen.
- Hvad resultatet må indeholde · fx kontonavne og antal fund, men aldrig passwords eller hashværdier.
- Hvem der får resultatet · og hvordan de berørte brugere og kontoejere får besked.
Laver en ekstern gennemgang kontrollen, er aftalen endnu vigtigere. En ekstern bør som udgangspunkt få resultatet og ikke selve hashværdierne. Det er vores anbefaling og ikke en kildes.
Tvunget skift ved fund
Minimumskravene tvinger skift, når et password er lækket eller svagt. Det er et skift ved tegn på kompromittering, og her er kilderne enige. Om passwords også skal skiftes med faste mellemrum, er de derimod uenige. Bilaget til forordning 2024/2690 taler om skift med planlagte mellemrum for de omfattede virksomhedstyper, mens SAMSIK, NIST og CISA’s baseline for Entra ID går imod faste skift. Uenigheden er beskrevet i adgangskodepolitikken holdt op mod nyere vejledning.
Hvad det kræver, og hvad det koster at lade være
Det kræver en liste over lækkede passwords, et værktøj eller script, der kan sammenligne hashværdier på eget system, en skriftlig aftale om håndteringen og en arbejdsgang for at få de berørte til at skifte. Servicekonti kræver særlig omtanke, fordi et skift skal koordineres med det program, der bruger kontoen.
Uden kontrollen ved I ikke, om nogen af jeres passwords allerede står på en liste, som andre kan bruge. Kontoen ser normal ud i loggen, også når den bliver brugt af en anden.
Det skal I lade være med
- At sende hashværdier til en ekstern tjeneste · vejledningen peger på kontrol på eget system.
- At gemme resultatet med passwords eller hashværdier · kontonavn og fund er nok.
- At glemme servicekonti og administratorkonti · de er også omfattet af krav 12.
Det skal gennemgangen kunne vise
- ☐ Opsætningen af kontrollen ved oprettelse og ændring af passwords.
- ☐ Dato og resultat for seneste kontrol af passwords i brug.
- ☐ En skriftlig aftale om håndtering og sletning af hashværdier.
- ☐ Bevis for, at berørte konti er tvunget til skift, og at ejere af servicekonti er orienteret.
- ☐ Den lokale tilføjelse til listen over svage passwords.
Kilder
- De tekniske minimumskrav for statslige myndigheder 2024, opdateret september 2025, krav 12, læst 13. november 2026.
- Styrelsen for Samfundssikkerhed, Vejledning til de tekniske minimumskrav, september 2025, afsnit 1.2 og 3.4, læst 13. november 2026.
- SAMSIK, Passwordsikkerhed, oktober 2026, side 21, læst 13. november 2026.
- CISA og NSA, AA23-278A Top Ten Cybersecurity Misconfigurations, 5. oktober 2023, punkt 9, læst 13. november 2026.
- Gennemførelsesforordning (EU) 2024/2690, bilaget, punkt 11.6.2, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Find ud af, om jeres katalog afviser passwords fra en liste ved oprettelse og ændring, og hvornår passwords i brug sidst blev kontrolleret.
Læs også: Servicekonti · Konfigurationsudtræk hos auditoren
→ Kontakt · Tlf. 70 13 63 23 · Teknisk sikkerhedsgennemgang hos Nielco IT
