patrick mylund nielsen bloghoved

ENISA's password-tips til udviklere og brugere

ENISA, EU's netværks- og informationssikkerhedsagentur, udgav for en uges tid siden en kort oversigt (PDF) over de seneste kompromitteringer af password hash digests fra forskellige sites--LinkedIn, eHarmony, Yahoo, Nvidia, m.fl.--samt deres råd til hvad både udviklere og brugere kan gøre for at forbedre situationen.

Kortfattet:

Udviklere

  • Scramble passwords ordentligt. Ingen klartekst; brug en saltet og langsom algoritme som f.eks. bcrypt eller SHA-256 [i en konstruktion som PBKDF2-HMAC-SHA256-100000]
  • Sørg for at have en ordentlig SDLC: de fleste af disse hacks bliver udført via SQL injections(!)
  • Lav en ordentlig password-politik (minimum-længde, kompleksitet, fornyelsesinterval), og brug to-faktor-autenticering
  • Sig noget, hvis I bliver hacked

Brugere

  • Brug ikke det samme password to steder
  • Skift dit password øjeblikkeligt hvis det bliver stjålet
  • Brug et password over 8 karakterer, gerne en passphrase/kodesætning. Et password der er nemt at huske er ikke nødvendigvis nemt at gætte, og vice versa.
  • Skift passwords ofte
  • Brug en password manager
  • Brug login-tjenester [som f.eks. OpenID via Google], der understøtter to-faktor-autenticering, når det er muligt

IMO: Unikke og totalt tilfældige passwords håndteret af en password manager med et master password der er en lang passphrase (hvor kompleksiteten er underordnet) eller et langt, tilfældigt password, der er skrevet ned på papir, med to-faktor via mobilen når det er muligt, er det, der samtidig er mest sikkert og praktisk. Det er en god idé at skifte passwords ofte, men kun hvis du ikke selv skal huske dem. Et password med # i stedet for ! i slutningen er ikke sværere at gætte. (Ligeledes med kompleksiteten: det bliver ofte til a -> @, s -> 5, o -> 0, osv., og det gør det jo kun sværere at huske. Tilfældighedsfaktoren i en sådan erstatning er meget lavere end hvis passwordet bare var en karakter længere i stedet.)

Jeg synes, at det er fedt, at en offentlig instans siger, "spænd hjelmen", og at rådene er korte og fornuftige. Dog ville jeg ønske almindelige brugere valgte passwords, der i gennemsnit var længere end 8-10 karakterer. Hvad synes I?

Disclosure: Én af deres referencer er en artikel, jeg har skrevet.

Kommentarer (38)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Rasmus Toftdahl Olesen

Rigtigt gode råd og det følger i fodsporene på de tanker jeg har haft: * Een passphrase til en password manager. * Og så et password til hvert password som jeg aldrig selv skal huske.

Jeg mangler dog bare nogle gode passwords managers der gør det til at arbejde med, det skal jo helst fungere med firefox og chrome og både på linux og windows (og også gerne android) og så skal det være noget der bliver synkroniseret på tværs af alle mine enheder.

Jeg gætter på at der sikkert er nogle cloud-tjenester, men jeg er ikke så glad for at have den slags ting til at lægge et sted hvor jeg ikke har kontrol. Så det bedste er vel noget man kan installere på sin egen server - eller eventuelt noget man kan smide i dropbox (eller andet) i en krypteret form som så kan læses alle steder.

Forslag tak! :)

  • 2
  • 0
#2 Patrick Mylund Nielsen

Mit bud er LastPass, der kun "holder" en krypteret "blob" for dig, og automatisk synkroniserer sig til og virker på de fleste enheder, eller en KeePass/Password Safe-fil i f.eks. Dropbox -- men øg antallet af PBKDF2 eller AES-runder til det tager 1-2 sekunder at åbne filen/logge ind. (Jeg mener det er under Account Settings i LastPass og File -> Database settings i KeePass.) Så er du relativt sikker mod offline-angreb.

  • 1
  • 0
#3 Peter Stricker
  • 2
  • 0
#6 Rasmus Toftdahl Olesen

Tak for gode bud. Umiddelbart peger pilen mest på pwsafe (eller en af de mange kloner der er kompatible) da det både er open source, har aktiv udvikler community, flere implementationer og et klart defineret filformat. Og så skader det jo heller ikke at vores allesammens Bruce har været med inde over det :)

  • 1
  • 0
#7 Patrick Mylund Nielsen

Så længe min password "blob" er forsvarligt krypteret burde jeg være ligeglad om der er onde mennesker der får fingre i den.

Ja, men det er ret svært at lave en nøgle, der både kan huskes/er praktisk at taste ind, og samtidig er kryptografisk forsvarlig, f.eks. skal du op på ~40 helt tilfældige(!) ASCII-karakterer, eller en meget længere (og også tilfældig) passphrase, for en 256-bit-nøgle.

  • 2
  • 0
#8 Johan Brinch

Lav en ordentlig password-politik (minimum-længde, kompleksitet, fornyelsesinterval), og brug to-faktor-autenticering

Jeg har en delt holdning til den her. Yes, vi kan afvise passwords på 1 tegn, de er klart usikre. 2-6 tegn, nok også. Herefter kan man bruge ordbøger og afvise ord og lignende. Fint nok.

Men når jeg kommer med et auto-genereret password på 16 tegn og bliver afvist pga. mangel på store bogstaver giver det bare ikke mening længere. Der er risiko for, at brugeren for afvist et sikkert password, hvis heuristikken er for aggresiv, og dermed dropper det auto-genererede password til fordel for et der er mindre sikkert, men som passer ind i regelsættet.

Og så er der dem som har fået den galt i halsen, og afviser passwords der er "for lange" (typisk regel: maks 15 tegn), eller kræver at passwords kun indeholder tal.

  • 8
  • 0
#9 Johan Brinch

En simpel lav-niveau løsning er parameterised queries.

Hvis man quoter data til SQL-kode selv gør man noget galt. Hvis man klipper data og SQL-kode sammen gør man noget galt. Der findes parameterised queries og ORMs (abstraktionslag) til den slags.

Ved ikke lige hvad SDLC dækker over.

  • 1
  • 0
#10 Johan Brinch

PBKDF2-HMAC-SHA256-100000 er god. Brug den!

Og skru endelig op for iterationerne løbende, som hardwaren tillader det, måske en gang om året (kan gøres ved password skift, så nye passwords bliver gemt mere sikkert).

  • 1
  • 0
#11 Johan Brinch

Brug ikke det samme password to steder

Jeg kunne nok ikke være mere enig. Tænk over hvor mange sider der idag kræver en bruger. Hvor mange af de sider kræver en mailadresse? Pænt mange. Hvis den mailadresse er legit og bruger samme kode, som siden, og siden ikke beskytter passwordet ordentligt, er det bare et spørgsmål om tid før nogen har overtaget din gmail/hotmail/what-ever-mail.

God ide: Aktiver 2-faktor authentication på din GMail/what-ever-mail idag, hvis du ikke allerede har gjort det.

  • 1
  • 0
#12 Torben Mogensen Blogger

Det er rart at se, at der også fra officiel side gøres op med ideen om at kodeord skal indeholde både store og små bogstaver, tal og specieltegn, for (som nævnt) giver det ikke voldsomt større kompleksitet, da de fleste brugere blot laver standardsubstitutioner eller tilføjer et tegn eller to til slutningen af et almindeligt ord. Som nævnt giver det flere bit information at gøre minimumslængden større.

Et af KUs systemer (til ansættelsessager m.m.) kræver alle følgende ting af kodeordet:

  • Min. 8 tegn
  • Store og små bogstaver
  • Cifre
  • Specialtegn
  • Jævnligt skift af kodeord.

Det betyder, at jeg aldrig kan huske mit kodeord. Men det gør ikke så meget, for hver gang, der er en ny sag, jeg skal behandle, får jeg tilsendt en mail, hvor mit kodeord står -- i klartekst. Godt nok sammen med en påmindelse om, at det bør skiftes, men alligevel sætter den praksis de strenge regler for kodeordets opbygning i relief.

I øvrigt tror jeg ikke, at krav om jævnlige skift af kodeord hjælper ret meget. I de fleste tilfælde vil brugere enten skifte frem og tilbage mellem to-tre kodeord eller blot indsætte en tæller i kodeordet, f.eks. "Mit-kodeord00" efterfulgt af "Mit-kodeord01" osv. Selvfølgelig skal kodeord skiftes, hvis der er mistanke om hacking af kodeordsdatabasen, men periodiske skift giver ikke meget og er blot til besvær.

  • 5
  • 0
#13 Patrick Mylund Nielsen

Det betyder, at jeg aldrig kan huske mit kodeord. Men det gør ikke så meget, for hver gang, der er en ny sag, jeg skal behandle, får jeg tilsendt en mail, hvor mit kodeord står -- i klartekst. Godt nok sammen med en påmindelse om, at det bør skiftes, men alligevel sætter den praksis de strenge regler for kodeordets opbygning i relief.

Scary. http://plaintextoffenders.com/ :)

I øvrigt tror jeg ikke, at krav om jævnlige skift af kodeord hjælper ret meget. I de fleste tilfælde vil brugere enten skifte frem og tilbage mellem to-tre kodeord eller blot indsætte en tæller i kodeordet, f.eks. "Mit-kodeord00" efterfulgt af "Mit-kodeord01" osv. Selvfølgelig skal kodeord skiftes, hvis der er mistanke om hacking af kodeordsdatabasen, men periodiske skift giver ikke meget og er blot til besvær.

Men når jeg kommer med et auto-genereret password på 16 tegn og bliver afvist pga. mangel på store bogstaver giver det bare ikke mening længere. Der er risiko for, at brugeren for afvist et sikkert password, hvis heuristikken er for aggresiv, og dermed dropper det auto-genererede password til fordel for et der er mindre sikkert, men som passer ind i regelsættet.

Og så er der dem som har fået den galt i halsen, og afviser passwords der er "for lange" (typisk regel: maks 15 tegn), eller kræver at passwords kun indeholder tal.

Fuldstændig enig. Kompleksitets- og skiftekrav er noget, der i teorien virker, men som ingen gør "rigtigt." Det er bare bøvlet at ændre sit password hver måned når det eneste der ændres er en karakter i slutningen, og det er ikke rimeligt at forlange, at folk skal huske et nyt, fuldstændig tilfældigt password hver gang, med mindre de skriver det ned på et stykke papir--men det har sikkerhedsfolk i lang tid sagt er meget farligt.

At indskrænke input til en del af ASCII-karaktersættet virker for mig fuldstændig vanvittigt, og der er irriterende mange sider, der gør det. Måske er det et dårligt forsøg på at forhindre injection-angreb, eller fordi de lagrer passwords i klartekst...?

Grænsen på størrelsen er god, men kun så længe den ikke er tilfældig, eller så lav at du ikke faktisk kan lave et stærkt password. (Der er stadig banker i USA, der har en grænse på 10 eller 12 tegn, og afviser symboler!) For eksempel er der en grænse på 55 bytes/ASCII-karakterer i bcrypt, der ellers er en meget populær password-hashing-mekanisme. Det er bedre at sætte en (fornuftig) grænse i stedet for at trunkere inputtet, der kan være en simpel passphrase efterfulgt af et meget stærkt password. Ligeledes med andre algoritmer der har en fast output-størrelse--hvis input har mere end 128 bits entropi, og der bruges SHA-256, for eksempel--men det er måske mere på den teoretiske side (og svært at måle, selv for CSPRNG-output.)

  • 1
  • 0
#15 Johan Brinch

Du behøver ikke 256-bit til dit password. Det ville være rimelig sygt. Hvis du skal være sikker mod bruteforce, skal du bruge 128-bit. Men 80-bit (som svarer til en 1024-bit RSA nøgle, ish) er nok til de fleste brugere. Styrkes koden med en key-derivation funktion som PBKDF2 er det endnu bedre.

Det er dog stadig 16 tilfældigt valgte tegn fra et alfabet på 36 tegn (f.eks. tal + små bogstaver).

  • 0
  • 1
#16 Michael Rasmussen

Hej Rasmus,

Jeg anvender keepass safe (algoritmen) med nøglefilen krypteret i dropbox. Fordelen er, at keepass safe algoritmen og dropbox findes implementeret på alle platforme, således at jeg har adgang til mine passwords fra Linux, Windows, OSX, IOS(iPad) samt Android.

For at få dette til at virke, skal du sikre dig, at du gemmer password filen i keepass version 1, da der ikke findes klienter til alle ovenstående platforme, der understøtter version 1.

  • 0
  • 0
#17 Patrick Mylund Nielsen

Du behøver ikke 256-bit til dit password. Det ville være rimelig sygt. Hvis du skal være sikker mod bruteforce, skal du bruge 128-bit. Men 80-bit (som svarer til en 1024-bit RSA nøgle, ish) er nok til de fleste brugere. Styrkes koden med en key-derivation funktion som PBKDF2 er det endnu bedre.

Min pointe var netop, at det er rimelig sygt, og at man derfor ikke kan være helt ligeglad med, om nogen får fat på din password-blob og kan udføre offline-angreb.

Der er få, der mener at 128 bits sikkerhed er fremtidssikkert, specielt mht. RSA da den bygger på faktoriseringer af primtal, noget kvantecomputere vil være meget gode til.

En KDF hjælper, men du får aldrig en nøgle med 40 bits sikkerhed til at have 256, og alligevel vil din "best-case"-sikkerhed ikke være bedre/større end nøglens størrelse.

  • 1
  • 0
#21 Lars Magnusson

Se på Factorum, der var(er) Plan9 SSO. Når man er logged in til sin session, har man alla resourser uanset hvor disse er placeret i Plan9-molnet (for Plan9 er en molnarkitektur). Password er lokalt, al autentisering sker via ssh/pgp-liknenede certifikat og man kan certifiere t.o.m. processer, at de enkelte processer har access control. Factorum er vad vi burde haft, AD på steroider men uden mange af ADs ulemper.

Intressante er att i stort set alla bag Factorum (og Plan9) er på Google og arbejer med Go idag. Men de vil ikke svara på hvis Factorum kan dyke op i ny kostyme.

  • 1
  • 0
#23 Lars Magnusson

:-) Beklagligtvis er jeg ikke udvikler mere, infosec:er med et ben i molnet ;-). Som gammel sysadmin, man pröver at följe vad AT&T-teamet laver. Derfor lit kedligt at höre at vaerldens beste OS-konstruktörer lagt dette på hylden. Som mange, er meget ked af at Plan9 ikke blev til noget, da det havde i stort set alt et modernt moln har. Et OS der var mer fremragende og modernt end dagens Unix-/VMS-kloner.

Da Factorum ikke er del av OS:et, uden operer på toppen, skulle det sagtens kunne implementeres oven både Windows som xNIX, net op så som Cryptzones Se46 whitelisting applikation virker. Se46 har fuld kontrol vilke processer der körer og hvem, ikke uligt Factorum.

  • 1
  • 0
#24 Peter Mogensen

Jeg er noget ambivalent ved ideen om at tvinge brugere til at skifte password ofte. Jeg har ikke set et eneste sted hvor det ikke ender med at brugerne omgår det ved at finde på simple systemer til at generere og huske nye passwords. (hemmeligt1,hemmeligt2,hemmeligt3 osv), skifte frem og tilbage mellem de samme 2 passwords - eller sætte post-it på skærmen. Det ender gerne med ikke at forbedre sikkerheden overhovedet.

Hvis jeg skulle slå skift-password-tvang til ville det være i direkte kombination med validering af "kvaliteten af password" - beløn brugeren direkte for at vælge et godt password: Samtidig med at password-dialogen viser et estimat af hvor godt et passwords man har valgt (som man ofte ser), så øg gyldighedsperioden i takt med kvaliteten og vis brugeren hvor lang tid han får lov til at bruge det password.

  • 3
  • 1
#25 Peter Mogensen

Det er meget fint med en email til brugeren med et link han kan følge - men hvad hvis den service man gerne vil logge ind i er ens webmail-program ??

Er det principielt ikke bare et special-tilfælde af sådan noget som OpenID? Man stoler på at brugeren er den han siger han er, hvis han kan demonstrere at han kan logge ind hos nogen man stoler på - i det her tilfælde en mail-konto.

  • 1
  • 0
#26 Morten Grouleff

-er ofte slet ikke ens password til de enkelte services, men de andre veje til at få adgang, i form af mere eller mindre automatiserede "password recovery" muligheder.

http://www.wired.com/gadgetlab/2012/08/apple-amazon-mat-honan-hacking/ er et skræmmende eksempel på at det ikke er nok at bruge et ordentligt password. Nok er Amazon og Apple her temmelig sløsede med deres brugeres privacy, men jeg har ingen grund til at tro at de skiller sig markant ud fra resten af flokken: De tjener næppe penge på at være besværlige, når kunderne ringer for at få hjælp. Derimod koster det dem løn-udbetalinger at gøre det bedre.

Bedste "beskyttelse" mod den slags er vel at være så usynlig og anonym som muligt? F.eks. at lade være med at skrive noget her. Hmm...

  • 0
  • 0
#27 Anders Prier Lindvig

"eller et langt, tilfældigt password, der er skrevet ned på papir"

Det er en rigtig dårlig ide at skrive passwords ned på papir. Så ryger hele ideen med at vælge et sikkert password. Et sikkert password skal aldrig skrives ned! Tænk bare på dumpster diving, og i tilfælde af indbrud :)

  • 1
  • 1
#28 Patrick Mylund Nielsen

Det er en rigtig dårlig ide at skrive passwords ned på papir. Så ryger hele ideen med at vælge et sikkert password. Et sikkert password skal aldrig skrives ned! Tænk bare på dumpster diving, og i tilfælde af indbrud :)

Der er langt større chance for, at nogen brute-forcer dit svage password, end at nogen får fat i et stærkt password der er skrevet ned på en lap, der ligger i din pung. Hvor mange tilfældige mennesker har set dine kreditkort i din pung?

Hvis du giver lappen væk eller smider den ud, skifter du selvfølgelig dit password.

Hvis du vil have et rigtigt stærkt (master) password, og ikke kan lide lange passphrases, er det næsten det eneste, du kan gøre.

  • 2
  • 1
#29 Patrick Mylund Nielsen

To-faktor-autenticering ville måske have hjulpet, som han sagde, men ja, der er ikke meget at gøre når firmaet selv hjælper hackeren! Både Amazon og Apple har da også spændt hjelmen nu:

http://arstechnica.com/security/2012/08/amazon-fixes-security-flaw-hacke...

http://www.wired.com/gadgetlab/2012/08/apple-icloud-password-freeze/

Forhåbentlig ikke kun midlertidigt...

  • 0
  • 0
#30 Andreas Krüger

Jeg læste på et tidspunkt en artikel omkring kryptografi, hvori det bl.a. blev nævnt at i stedet for at forsøge at vælge et kodeord med store og små bogstaver, tal, tegn osv. - så skulle man i stedet for vælge et kodeord der var en sætning. Deres "forskning" viste, at et langt kodeord det reelt var en lang sætning, havde samme effekt som et "kort" kodeord med tilfældige tal. Jeg kan desværre ikke huske link til artiklen.

  • 2
  • 0
#31 Anders Prier Lindvig

Det er selvfølgelig en mindre dårlig ide når papirlappen befinder sig i sin pung, eftersom man altid har den på sig. Dog er det lidt det samme som at have koden til sit dankort i pungen. Lommetyven vil hurtigt få dit navn + password, og på den måde få adgang til email eller lignende. I stedet kan man nøjes med at skrive passwordet ned i starten, og lære det lange password udenad, for derefter at rive den i stykker. Det fungerer rigtig godt for mig, og jeg har et passwords på 17 karakterer med store-små bogstaver, tal, symboler og specialtegn.

  • 0
  • 1
#32 Patrick Mylund Nielsen

Et helt normalt ord fra den engelske ordbog har ca. 11 bits entropi. En helt tilfældig ASCII-karakter har ca. 6. Dvs. corner classroom football bigger which chest er cirka lige så stærkt som w0"M_1kXlz, men kun hvis sætningen er tilfældig. (Selvfølgelig skal passwordet også være fuldstændig tilfældigt for at have samme styrke.)

Hvilket er lettere at huske? Hvis det ikke er helt tydeligt, prøv at gå udenfor, kom tilbage, og skriv én af dem ned.

Der er mange forskellige studier om estimering af entropi i engelsk tekst--det mest kendte er nok Claude Shannon's. Der er et rigtig godt kapitel i Cryptography Engineering af Bruce Schneier om passwords vs. passphrases -- et klip:

Humans are notoriously bad at memorizing passwords. If you choose very simple passwords, you don't get any security. There are simply not enough simple passwords for them to be really secret: the attacker can just try them all. Using your mother's maiden name doesn't work very well; her name is quite often public knowledge—and even if it isn't, there are probably only a few hundred thousand surnames that the attacker has to try to find the right one.

A good password must be unpredictable. In other words, it must contain a lot of entropy. Normal words, such as passwords, do not contain much entropy. There are about half a million English words—and that is counting all the very long and obscure words in an unabridged dictionary—so a single word as password provides at most 19 bits of entropy.

Estimates of the amount of entropy per character in English text vary a bit, but are in the neighborhood of 1.5–2 bits per letter. We've been using 256-bit secret keys throughout our systems to achieve 128 bits of security. In most places, using a 256-bit key has very little additional cost. However, in this situation the user has to memorize the password (or key), and the additional cost of larger keys is high. Trying to use passwords with 256 bits of entropy is too cumbersome; therefore, we will restrict ourselves to passwords with only 128 bits of entropy.

Using the optimistic estimate of 2 bits per character, we'd need a password of 64 characters to get 128 bits of entropy. That is unacceptable. Users will simply refuse to use such long passwords. What if we compromise and accept 64 bits of security? That is already very marginal. At 2 bits of entropy per character, we need the password to be at least 32 characters long. Even that is too long for users to deal with. Don't forget, most real-world passwords are only 6–8 letters long. You could try to use assigned passwords, but have you ever tried to use a system where you are told that your password is “7193275827429946905186”? Or how about “aoekjk3ncmakwe”? Humans simply can't remember such passwords, so this solution doesn't work. (In practice, users will write the password down, but we'll discuss that in the next section.)

A much better solution is to use a passphrase. This is similar to a password. In fact, they are so similar that we consider them equivalent. The difference is merely one of emphasis: a passphrase is much longer than a password. Perhaps Alice could use the passphrase, “Pink curtains meander across the ocean.” That is nonsensical, but fairly easy to remember. It is also 38 characters long, so it probably contains about 57–76 bits of entropy. If Alice expands it to “Pink dotty curtains meander over seas of Xmas wishes,” she gets 52 characters for a very reasonable key of 78–104 bits of entropy. Given a keyboard, Alice can type this passphrase in a few seconds, which is certainly much faster than she can type a string of random digits. We rely on the fact that a passphrase is much easier to memorize than random data.

Many mnemonic techniques are based on the idea of converting random data to things much closer to our passphrases. Some users don't like to do a lot of typing, so they choose their passphrases slightly differently. How about “Wtnitmtstsaaoof,ottaaasot,aboet”? This looks like total nonsense; that is, until you think of it as the first letters of the words of a sentence. In this case we used a sentence from Shakespeare: “Whether ’tis nobler in the mind to suffer the slings and arrows of outrageous fortune, or to take arms against a sea of troubles, and by opposing end them.” Of course, Alice should not use a sentence from literature; literary texts are too accessible for an attacker, and how many suitable sentences would there be in the books on Alice's bookshelf? Instead, she should invent her own sentence, one that nobody else could possibly think of. Compared to using a full passphrase, the initial-letters-from-each-word technique requires a longer sentence, but it requires less typing for good security.

  • 3
  • 0
#33 Andreas Krüger

Cryptography Engineering af Bruce Schneier

Der var det jo :)

Jeg vil stadig mene at den almene person der skal lave et "sikkert" kodeord har langt større gavn af at bruge en sætning som kodeord, fremfor et tilfældigt valgt kodeord. Dels fordi jeg vil påstå at personen har nemmere ved at huske det, personen har også en langt større tilbøjelighed til ikke at vælge et let huskeligt kodeord der bliver skrevet ned på en lap eller i en email og samtidigt sikre du dig mod "123" kodeord. Jeg vil mene, at en password policy i stedet bør fokusere på længden af kodeord fremfor hvad de skal indeholde. Jeg vil hellere have et kodeord som "jegskaludoghandleidagkl15" fremfor "8msjl2" - og så er jeg ret overbevist om, at det førstnævnte er mere sikkert. Bruteforcing af det første kodeord tager også længere tid?

Men når alt kommer til alt, så handler det jo også væsentlig om opdragelsen af brugeren.

  • 0
  • 0
#34 Patrick Mylund Nielsen

Det er selvfølgelig en mindre dårlig ide når papirlappen befinder sig i sin pung, eftersom man altid har den på sig. Dog er det lidt det samme som at have koden til sit dankort i pungen. Lommetyven vil hurtigt få dit navn + password, og på den måde få adgang til email eller lignende.

Ja, intuitivt virker det som en dårlig idé, men tænk på, at en ondsindet bruger, fra hvor som helst i verden, har al den tid han vil bruge til at gætte dit password. Hvis han har fået fat på nogle hash digests (eller krypterede filer), og udbyderen der er blevet kompromitteret ikke har lagret dem ordentlig, kan han lave over 6 milliarder gæt i sekundet med MD5, og over 50 milliarder med NTLM (MD4) med billig hardware.

Med bare ~5 milliarder forsøg i sekundet mod MD5 er det op til ca. 17 sekunder for at brute-force rNc8PTL, 3½ time for aUS4r^K, og 3,092,319 år for MiHo%rf5ps7g.

Hvis det er kortet eller passwordet i pungen, så ændrer du passwordet eller spærrer kortet hvis pungen bliver stjålet.

Jeg har citeret Bruce Schneier et par gange, så hvorfor ikke fortsætte. Her er hans tanker om at skrive passwords ned:

Microsoft's Jesper Johansson urged people to write down their passwords.

This is good advice, and I've been saying it for years.

Simply, people can no longer remember passwords good enough to reliably defend against dictionary attacks, and are much more secure if they choose a password too complicated to remember and then write it down. We're all good at securing small pieces of paper. I recommend that people write their passwords down on a small piece of paper, and keep it with their other valuable small pieces of paper: in their wallet.

  • 2
  • 0
#35 Anders Prier Lindvig

Enig! :)

Kan godt se at det generelt ikke kan forventes at folk kan huske de lange passwords, og man i længden vil være bedre tjent med papir-metoden. Min pointe var også blot at hvis man gider bruge krudt på det andet, så kan det i nogle tilfælde være en god ide.

  • sometimes on paper
  • 0
  • 0
#36 Patrick Mylund Nielsen

Jeg vil hellere have et kodeord som "jegskaludoghandleidagkl15" fremfor "8msjl2" - og så er jeg ret overbevist om, at det førstnævnte er mere sikkert. Bruteforcing af det første kodeord tager også længere tid?

Ja, meget, meget længere tid, men kun med primitiv brute-force. Fordi sætningen ikke er tilfældig er det betydeligt mindre sikkert end f.eks. "hat på løber tyve bed". Chancen er måske lille, og der er måske ingen der faktisk brute-forcer danske sætninger lige nu, men en ondsindet bruger ville have meget lettere ved at brute-force den første sætning end én, der ikke giver mening, fordi han eller hun skal prøve alle mulige kombinationer af ord.

En rigtig god ressurse: http://www.diceware.com

  • 1
  • 0
#37 Patrick Mylund Nielsen

Kan godt se at det generelt ikke kan forventes at folk kan huske de lange passwords, og man i længden vil være bedre tjent med papir-metoden. Min pointe var også blot at hvis man gider bruge krudt på det andet, så kan det i nogle tilfælde være en god ide.

Passphrases er min favorit, men en sådan skal stadig være ret lang for at være sikker, og jeg kan godt forstå hvis brugere ikke gider eller kan det, f.eks. hvis de ikke skriver særlig hurtigt. I det tilfælde, eller hvis man krypterer noget meget hemmeligt, så er det bedre at skrive det ned end at vælge noget, der er svagere, bare for at kunne huske det.

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