Pest og kolera

Det er måske lidt sølle, men det hænder, at jeg kommer til at bladre lidt i DS 484 uden egentlig grund.

Som du nok kan forestille dig, er det hverken den store spænding eller humor, som præger DS 484. Men i dag kom jeg faktisk til at grine højlydt.

Jeg faldt over 11.3.1 Brug af adgangskoder. I d) står der:

[Brugeren skal] vælge adgangskode med en sådan sammensætning og længde, at de:
**

  1. *er nemme at huske*
  2. *ikke kan gættes eller udledes af let tilgængelige oplysninger om eksempelvis navne, telefonnumre, fødselsdatoer osv.*
  3. *ikke findes i ordbøger eller ordlister (dictionary attack)*
  4. *ikke indeholder flere på hinanden følgende ens tal eller bogstaver eller kun tal eller bogstaver*

Jeg fik flash back til min CISSP-eksamen, hvor jeg i 6 stive timer sad og udvalgte hvilke sætninger, der var mindst rigtige blandt 4-5 valgmuligheder, der alle var mere eller mindre rigtige. 

Der er bare lige det, at DS 484 ikke tillader at fravælge et krav.

Et godt eksempel på, at sikkerhed er en selvmodsigende størrelse.

I de gode gamle dage, hvor man blev betragtet som virkelig underlig, hvis man ikke uden videre overtrådte 11.3.1 h)

[Brugeren skal] ikke dele personlig adgangskode med andre

gav jeg faktisk min daværende adgangskode til en tekniker, der lige skulle noget på min maskine. Adgangskoden overholdt hverken d) 2 eller 3.

Adgangskoden var navnet på en figur i et digt, som jeg holdt meget af, efterfulgt at et enkelt tal (ja, ja, men som sagt var det i gamle dage). 

For at gøre det endnu sværere for ham at huske bagefter gav jeg ham adgangskoden bogstav for bogstav. Det havde jeg dog ikke behøvet. Teknikeren læste øjensynligt ikke digte. Han var vildt imponeret over hvor 'sindssyg en adgangskode', der var tale om.

Jeg konkluderede blot, at det tydeligvis afhænger af, hvilket mindset man render rundt med, om noget er let at gætte eller ej. 

Hvis man lavede en analyse, vil jeg formode, at ingeniørers adgangskoder har en tendens til at minde om hinanden, mens de vil være forskellige fra humanisters adgangskoder (jeg forudsætter selvfølgelig, at humanister kan finde ud af at lave en adgangskode).

På samme måde som en kryptograf kan spotte et primtal, som bare er et tal for os andre, vil vores adgangskoder ikke altid kunne gættes, hvis blot den rigtige bliver sat på opgaven (eventuelt med adgang til at snuse rundt i dit hjem)?

Kan du virkelig påstå, at din bedste adgangskode ikke blot er en funktion af det, du ved' Af den du er'

Kommentarer (12)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Klavs Klavsen

Jeg har altid lært (ved ikke lige hvorfra jeg har fået idéen dog) at anvende et billede som mit kodeord, inkl. lidt "scrambling".

Det gør det dejligt let at huske og meget svært at brute-force.

forestil dig f.ex. et billede af en Lampe med frynser.
kodeord:
L@mp3MedFryns3r
kunne f.ex. så blive kodeordet, med den simple substitutionsregel: lille e=3, lille a=@

Derudover kan man vælge et billede med et antal - f.ex. 10 frynser og istedet skrive #10Fryns3r som den del. Så har man også fået lidt flere alternative karakterer med, som vil tvinge en bruteforce'er til at prøve andet end bare a-z og 0-9 og samtidigt har kodeordet en god længde.

Prøv selv - det er forbløffende nemt at huske :)

  • 0
  • 0
Claus Agerskov

Nogle af mine adgangskoder opfylder da ikke ovenstående krav, men det er ofte også dem, der benyttes på steder, hvor det ikke er så vigtigt igen - eksempelvis her på Version2 - men de er under ingen omstændigheder umiddelbare. Tidligere har jeg benyttet Ager29boj men det var før jeg selv kom til at hedde Agerskov (hed Sørensen før). 29 er min fødselsdag og boj er starten på mit mellemnavn Bojer.

Den første adgangskode jeg havde var UjKo)8 (eller noget lignende). Efter jeg havde været på ferie første gang, kunne jeg ikke umiddelbart huske den, da jeg havde glemt referencebogstavet, om det var med eller mod uret og om jeg startede med SHIFT-nede eller oppe.

I ovennævte tilfælde var det "I" jeg tog en tur omkring mod uret og startende med "U". Det tog et kvarter at finde den. Og den overholdt faktisk alle kravene ovenfor. Jeg har dog ikke benyttet metoden siden, men dog anbefalet den til andre, hvis man samtidigt satte et par tegn på derudover.

Jeg har tidligere også benyttet BigSis.9148,Go hvor der er taget udgangspunkt i George Orwells (Go) klassisker 1984 (byttet om på cifrene parvis), hvor begrebet Big Brother (BigSis som forkortelse for Big Sister i stedet for brother) kommer fra.

PS - hvad er det, der er så grinagtig ved kravene til adgangskoden?

  • 0
  • 0
Jesper Laisen

>hvad er det, der er så grinagtig ved kravene til adgangskoden?

Jeg synes blot, at krav 1 står i klar modsætning til krav 2-4.

Hvis en adgangskode er let at huske, er det oftest, fordi den er meningsbærende og dermed lettere at gætte.

I situationen virkede det en anelse absurd med så modsatrettede krav.

Men det er jo netop det, som sikkerhed er. Blancering af modsatrettede krav.

  • 0
  • 0
Morten Fordsmand

Mon ikke det var "JENS"?

I hvert fald nemt at huske - ak ja men det var også i starten af 80'erne.

Men man skal også huske at et andet krav til et "løsen" er at det skal udskiftes med rimelige mellemrum, og det er nu det bliver festligt.
For for hvert system man skal kunne identificere sig over for skal man opfinde et password, som udemærket beskrevet ovefor, huske og holde styr på hvilkt sysem ntop dette passord skal brges til.

Og så siger de at det er nemt at bruge computere.

  • 0
  • 0
Lasse Nielsen

Fordi passwords typisk er så korte at de er sårbare over for brute force-angreb.

Hvis det tager et halvt år at brute-force et password, men passwordet skiftes hver tredje måned, så er systemet sikkert.
Hvis passwordet skiftes en gang om året, så kan man være komprimiteret halvdelen af tiden.

Det er selvfølgelig et problem at maskinerne bliver hurtigere og hurtigere, for vi kan ikke skifte password for tit - så bliver det netop ikke til at huske.

/L

  • 0
  • 0
Jacob Christian Munch-Andersen

Fordi passwords typisk er så korte at de er sårbare over for brute force-angreb.

Det er jo noget fis, smid 2 tegn ekstra på og brute force tager noget i retning af 1000 gange så lang tid.

Er der i øvrigt nogensinde nogen af jer som har tænkt på at øge passwordsikkerheden ved at øge mængden af beregninger som det tager at verificere et password?

Vælges fx blot 6 tilfældige tegn blandt 80 mulige giver det 262 mia muligheder, det tager 3 døgn at brute force hvis man kan tjekke 1 mio muligheder i sekundet. Men hvis verificeringen er gjort beregningstung således at den tager 1/10 sekund per tjek, så er brute force tiden oppe på 831 år.

  • 0
  • 0
Jacob Christian Munch-Andersen

Kommer an på angrebs typen, et login over netværk er selvfølgelig beskyttet ved at begrænset antallet af tilladte forsøg, men skal man bryde en kryptering kan man godt komme op på rigtigt mange forsøg i sekundet. Hvor mange kommer i høj grad an på implementeringen, er verificeringen blot en alm. hashing så ender vi vel et sted i størrelsesordenen 1 mio per sekund, i mange situationer kan man nøjes med at dekryptere en lille fil og så tjekke den, hvilket kan give adskillige tusinde angreb per sekund. Et system med hash har den fordel at brugeren får det at vide med det samme hvis hyn taster forkert, min pointe er så at man bør prøve at ramme en mellemløsning, ved bare at lægge en lille bitte smule til responstiden opnår man en højere sikkerhed. Man bør styre tiden for et verificeringsforsøg for at opnå en optimal kombination af sikkerhed og hurtighed.

Pointen gælder selvfølgelig kun i nogle applikationer, en almindelig hashing algoritme bør være så hurtig som muligt, og kan man på anden vis begrænse angriberens mulighed for at foretage mange forsøg så er det at foretrække.

Det der undrer mig er at jeg aldrig har set overvejelser i den retning beskrevet før.

  • 0
  • 0
Log ind eller Opret konto for at kommentere