Digitaliseringsstyrelsen: Vi holder øje med DanID

Selvom jeg anvender NemID, er jeg stadig lamslået over at der ikke skelnes mellem store og små bogstaver i ens password.

Digitaliseringsstyrelsen kigger også på den her sag: http://newz.dk/forum/software/aabent-brev-til-dani...

Der er mange brugere, der er trygge ved løsningen.

Det er dog ikke noget mål for sikkerheden.

mireigi (1) skrev:

Selvom jeg anvender NemID,

Hvordan undgår du det?

mireigi (1) skrev:

er jeg stadig lamslået over at der ikke skelnes mellem store og små bogstaver i ens password.

Det er dog et af de mindste problemer med nemid . Man skal bare lave sit password 15% længere.

mireigi (1) skrev:

Selvom jeg anvender NemID, er jeg stadig lamslået over at der ikke skelnes mellem store og små bogstaver i ens password.

Er der ikke?
Jeg har ellers både store og små i mit kodeord, kan godt være at jeg lige skal tjekke næste gang om det passer :P

#3: intet forhindrer dig i at taste store bogstaver ind. At NemID ignorerer case er så noget andet. du kan sikkert slippe afsted med at skrive din kode med rent lowercase. som #2 skriver, giver case sensitivity ikke megen ekstra sikkerhed. lav du en kode på de 48 tegn nemid understøtter og lær den uden ad, så er den sikker nok, til at man ikke gætter koden på de 5-10 forsøg man har før koden spærres (5 forsøg, herefter 8 timers lockout, 5 forsøg mere, herefter skal du have ny kode tilsendt, been there;-)

nogen der ved om den gamle digitale signatur, som visse folk hylder, har været udsat for misbrug? eller har den ikke haft hackernes interesse, da man ikke kunne snuppe penge med den?

#4 Hvilket minder mig om en helt anden angrebsvinkel.

Med en liste af cpr numre kunne man måske automatisere de 5 forsøg - og så 5 igen efter 8 timer.

Så kunne man låse store dele af danmark ud :)

---

Har lige testet. Der er heldigvist ikke forskel i output for gyldige / ugyldige cpr numre. Så man kan ikke frasortere de ugyldige / ubrugelige cpr numre. Så man kommer til at lave langt flere hits mod danid end nødvendigt. Men givet lidt ressourcer skulle det nu nok kunne lade sig gøre. (Et botnet f.eks.)

LordMike (5) skrev:

Så kunne man låse store dele af danmark ud

5 forsøg per CPR nummer er jo et forkert kriterie når ikke man ikke har nogen form for bevis for at forsøgene kommer fra det CPR nummer.

Man kunne foretage følgende angreb. Tag en liste over hyppigst anvendte passwords start med det mest anvendte, undersøg om det opfylder password politikken til nemid, gå videre til det næstmest anvendte og fortsæt indtil man har 10 passwords.

Generer CPR numre med korrekt checksum. Kombiner evt. med statistikker over antal personer født per dato og antag at CPR numrene blev tildelt i rækkefølge så man ved hvilke der blev brugt og hvilke der ikke blev.

På den måde har man måske en liste med 20 millioner CPR numre hvoraf 4 millioner er gyldige, og 10 passwords som tillades af politikken. Gå i gang med at afprøve de 200 millioner kombinationer. (De 8 timers lockout kan mere eller mindre ignoreres da man nok kommer til at bruge mere end 8 timer på at gennemføre alle disse loginforsøg.)

Hvor mange korrekte passwords tror I man ville finde, hvis man gennemførte de 200 millioner forsøg? Sagt på en anden måde, hvor mange danskere har valgt et af de 10 mest almindelige passwords?

Throttling bør være per IP ikke per CPR nummer. Man kunne have krævet flere engangskoder jo flere forkerte passwords der har været forsøgt, men det gør til gengæld phishing lidt nemmere.

F.eks. 5 forsøg med 1 engangskode, 20 forsøg med 2 engangskoder, 100 forsøg med 3 engangskoder, 500 forsøg med 4 engangskoder, 2000 forsøg med 5 engangskoder, 10000 forsøg med 6 engangskoder, osv.

Desuden bliver man jo ikke spurgte om engangskode sammen med password. Man bliver først spurgt om engangskode når der har været indtastet et korrekt password. Det gør det nemmere at brute force passwords. Og reducerer den sikkerhed som engangskoderne giver. Til gengæld beskytter det imod DoS angreb ved at opbruge alle engangskoderne. Sådan et DoS angreb kunne man have beskyttet imod ved at spørge efter samme engangskode hver gang indtil den har været indtastet korrekt.

På den anden side er det måske bedre at acceptere muligheden for DoS angreb i første omgang, hvis blot man er sikker på at opdage hvis det sker.

I øvrigt bemærkede jeg lige noget interessant. Der er et offentligt site der har baggrundsbillede med en login boks lookalike: https://login.sikker-adgang.dk/fobslogin/images/ne...

Tilsyneladende bruger de den til at sikre at man kan se login boksen allerede før applet er indlæst. Det skal nok gøre fejlene nemmere at forstå hvis applet af en eller anden grund ikke kan indlæses. Og så kan brugerne jo også sidde og undre sig over hvorfor der er en periode hvor cursoren ikke blinker og man intet kan taste.

Mht til kryptiske password henleder jeg lige til vores allesammens gud:

http://xkcd.com/936/

hvis nogen hacker mig, tror jeg højst de får ondt af mig

Det er vel også kun på sin plads at de holder øje med dem de har solgt borgernes identitet til. Danid skulle jo nødig skumme fløden uden en passende mængde fløde flyder tilbage til djøfferne...

Nyheden skrev:

Ifølge Vicedirektør Lars Frelle-Petersen i den nyligt oprettede Digitaliseringsstyrelse, skal danskerne dog ikke være bekymret for sikkerheden, men i stedet sætte deres lid til, at det offentlige har styr på sagerne.

For det er jo lige det det offentlige er kendt for...

LordMike (5) skrev:

Men givet lidt ressourcer skulle det nu nok kunne lade sig gøre. (Et botnet f.eks.)

Man kunne også bruge en Cloud-service, fx Amazon's

Nyheden skrev:

Ifølge Vicedirektør Lars Frelle-Petersen i den nyligt oprettede Digitaliseringsstyrelse, skal danskerne dog ikke være bekymret for sikkerheden, men i stedet sætte deres lid til, at det offentlige har styr på sagerne.

Hvis der ikke er nogen der stiller spørgsmålstegn ved hvad myndighederne gør eller ikke gør, kan der hurtigt ske en masse dårlige ting.

Jeg syntes nu det er fint at så mange er efter DanId, det er trods alt en samfundsmæssig ret vigtig ting de administrerer!

SlettetBruger (7) skrev:

Mht til kryptiske password henleder jeg lige til vores allesammens gud

Jeg synes personligt at 44 bits entropi er alt for lidt. Jeg bruger passwords med 130 bits entropi.

Ja ja, alle firmaer siger de er enormt gode og gør alt rigtig, det hedder PR.

LordMike (5) skrev:

#4 Hvilket minder mig om en helt anden angrebsvinkel.

Med en liste af cpr numre kunne man måske automatisere de 5 forsøg - og så 5 igen efter 8 timer.

Man kan, og det er nok bedst, slå fra at man kan logge ind med CPR-nummer, så man kan i hvert fald beskytte sig selv mod den slags.

kasperd (12) skrev:

Jeg bruger passwords med 130 bits entropi.

Mit Windowspassword:
Entropy: 142.2 bits

muahaha

#15
Muahaha.. Dit 142,2 bits entropi password er beskyttet af LM - effektivt reduceret til 2x 7 cifre som kan bruteforces på ingen tid ..

Muahahha :D

---------------

#11
Ja, amazon cloud tæller som en ressource :)

#14
Det har jeg f.eks. gjort. Jeg ville også gerne slå login med nemid aftale nr. fra - men det kunne jeg ikke. Så har fortsat 2 usernames -.-.

cryo (14) skrev:

Man kan, og det er nok bedst, slå fra at man kan logge ind med CPR-nummer, så man kan i hvert fald beskytte sig selv mod den slags.

En endnu bedre løsning er at bruge et godt password.

I bedste fald ligger der ca. 23 bits entropi i bruger ID. Hvis du tilføjer tilfældige tegn til dit password har de ca. 5 bits entropi per tegn. Det vil sige at 4-5 tegn mere i passwordet kan kompensere for et bruger ID der er uendeligt nemt at gætte.

Egentlig kunne man tage det password man bruger i dag og tilføje sit brugernavn og CPR nummer til slutningen. Hvis ikke der er sikkerhedshuller i måden de håndterer passwords på ville det forbedre sikkerheden ved at man dermed skulle kende alle tre for at logge ind.

Der er selvfølgelig et par hager ved den idé. For det første er det ikke til at vide om passwords håndteres forsvarligt, men hvis passwords ikke håndteres forsvarligt er muligheden for at udlede dit CPR nummer fra dit password nok det mindste problem.

En anden hage er at password politikken sikkert ikke tillader det. Password politikker har det med at forsøge at undgå det dummeste brugere overhovedet kan finde på. At man ved samme lejlighed kommer til at forhindre brugere i at anvende passwords konstrueret på en måde der styrker sikkerheden overvejes sjældent.

Hvis du har et brugernavn på f.eks. 5 tegn og et password på 8 tegn, så opnår du lidt bedre sikkerhed ved at indsætte dit brugernavn et sted mellem de 8 tegn og derved have et password på 13 tegn. Men af de to passwords er det meget sandsynligt at det på 8 tegn accepteres, men det på 13 tegn afvises fordi der er en politik som siger det ikke må indeholde dit brugernavn.

En password politik der afviser passwords fordi de indeholder en "ulovlig" delstreng betyder at korte passwords er nemmere at få accepteret end lange passwords, fordi jo længere et password er, des større er chancen for at der et eller andet sted i passwordet er en "ulovlig" delstreng.

LordMike (16) skrev:

LM

Please explain.

Mente nok jeg havde hørt det før Vores Amerikanske moderselskab tvang os i sidste uge til at disable et eller andet LM Hash værk. må lige finde nogen papirer ^^

SlettetBruger (19) skrev:

tvang os i sidste uge til at disable et eller andet LM Hash

Som jeg husker det var problemet at LM i sin oprindelige form kun understøttede passwords på op til 7 tegn og gemte usaltede MD5 hashes af passwords.

Det var ikke specielt sikkert. De 7 tegn var forholdsvist nemme at brute force, specielt hvis man ikke varierede sit valg af karakterer ret meget.

En opdateret version fordoblede den understøttede længde fra 7 til 14 tegn. Men det skete ved at gemme to MD5 hashes, en af de første 7 tegn og en af de sidste 7 tegn.

Det vil sige at hvis du f.eks. valgte et password på 13 tegn, lad os f.eks. tage "kodeord16883!", så ville det blive gemt som hashværdien af "kodeord" og hashværdien af "16883!"

Det vil sige at de to hashes kunne brute forces hver for sig. Og hvis man havde mindre end de 14 tegn, så ville anden del være endnu nemmere at brute force fordi den var kortere end 7 tegn. Og hvis samtidigt alle specialtegnene var i slutningen af passwordet, så ville første del være nemmere at brute force fordi den ikke havde så stor variation af tegn.

Det er i hvert fald sådan jeg har forstået de beskrivelser jeg har læst af problemet. Jeg har dog aldrig selv rørt ved den type passwords.

Så vidt jeg har forstået kunne man undgå svagheden ved at kræve at passwords var på minimum 15 tegn. Hvis man vælger et password på 15 tegn ville man så vidt jeg har forstået ikke få passwordet gemt i dette bagudkompatible format og dermed undgå svagheden.

Hvis jeg har forstået det rigtigt er

LordMike (16) skrev:

Dit 142,2 bits entropi password er beskyttet af LM

faktuelt forkert fordi et password med så megen entropi er for langt til at blive gemt i LM formatet.

#20

Hvis jeg husker korrekt så vil et password på 15 eller flere tegn blive gemt i NTLMv2 . Det er også værd at bemærke at LM er disablet som default fra vista of frem efter i klient versionerne af windows og i windows server 2k8 og frem efter.