Hug adgangskoderne midt over og undgå en LinkedIn-fadæse

16. oktober 2012 kl. 06:2918
Ved at kryptere en stump information på en sådan måde, at man kan dele den op i to dele og senere verificere den uden at samle de to igen, kan man gøre det svært at stjæle en database med kodeord.
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

LONDON: Sikkerhedsfirmaet RSA tager nu et kryptografisk kneb i brug, som har været kendt i lærebøgerne i årevis, men som først nu har vakt genklang hos kunderne. Skandaler som eksempelvis de lækkede kodeord fra LinkedIn har gjort det interessant at implementere metoden, fordi den gør det mindre kritisk, hvis én server med en password-fil bliver hacket.

»I Distributed Credentials Protection (navnet på RSA's produkt, red.) tager vi en hemmelig oplysning som for eksempel et password og deler den op i to, som ligger på to adskilte systemer,« forklarer teknisk chef Ari Juels fra RSA.

De to dele kan verificeres enkeltvis som del af en autentificering, men hvis man for eksempel har to fysisk adskilte servere med forskellige styresystemer, så er det vanskeligt for en hacker at sikre sig adgang til begge to på samme tid.

»Hvert af de to sæt bliver 're-randomized' med korte intervaller, så selv hvis man får fat i det ene, så er der stor sandsynlighed for, at det andet er blevet krypteret på ny, inden man får fat i det også,« forklarer Ari Juels.

Artiklen fortsætter efter annoncen

Det er et princip, som har været beskrevet inden for kryptografien i mange år, men hidtil har det ikke været brugt kommercielt i større omfang.

Fordelen ved systemet er, at hvert af de to sæt autentificeres enkeltvis, så hele den information, man vil beskytte, aldrig bliver samlet på systemet, når først den er krypteret.

I en virksomhed kan man også vælge at overlade den ene halvdel til en server hos en cloud-udbyder, eller en myndighed kan kræve, at en halvdel opbevares på en national server, hvis der er tale om særligt følsomme data.

Passwords beskyttes i dag typisk med hash-funktioner, som i stedet for selve adgangskoden gemmer en beregnet værdi ved at køre adgangskoden gennem en hash-funktion. Den metode er imidlertid sårbar, hvis en hacker får fat i filen med hashværdierne, fordi han kan køre en ordliste gennem den samme hash-funktion og sammenligne med de værdier, der står på listen.

Derfor tilføjer man ofte et 'salt', som er en ekstra streng, der bliver kørt gennem hash-funktionen sammen med kodeordet.

»Det hjælper mod ordbogsangreb, men det kan stadig knækkes med brute force. Det er specielt problematisk, hvis man bruger det til at lagre svar på sikkerhedsspørgsmål, hvor entropien ofte er lille. Jeg har set sikkerhedsspørgsmål som 'hvad er din skostørrelse?' og så er der ikke ret mange svarmuligheder,« fortæller Ari Juels.

Derfor kan metoden med distribueret kryptografi også bruges til at lagre denne type information, fordi den kan give bedre beskyttelse mod de angreb, en hacker kan lave, hvis han får fat i filen med hash-værdierne.

Den væsentligste udfordring er dog at finde frem til, hvor hyppigt man skal lave en rerandomisering af de to halvdele, fordi det koster regnekraft at beregne det hele én gang til, især hvis man har store datasæt.

Til gengæld kan man ved at dele informationen op i to sæt undgå at havne på forsiden af alverdens medier, som det skete for LinkedIn, selvom én halvdel skulle blive lækket.

»Hvis kun én halvdel er blevet lækket, så er der teknisk set ikke blevet lækket nogen brugbar information,« påpeger Ari Juels.

Det forudsætter dog, at man kan få vished om, at der kun er blevet lækket én halvdel, eller i tilfælde af, at begge to er lækket, at det er sket med tilstrækkeligt stort tidsrum til, at der er foretaget en rerandomisering mellem hackeren fik adgang til de to sæt.

Version2's rejse og deltagelse i RSA Conference Europe 2012 er betalt af RSA.

18 kommentarer.  Hop til debatten
Denne artikel er gratis...

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.

Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.

Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.

Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
18
16. oktober 2012 kl. 23:01

" Såkaldte Sikkerhedsspørgsmål er en hån mod rigtig sikkerhed. Som regel kan de ting der spørges om kan findes med lidt socialt kendskab til personen. Jeg anser automatisk tjenester som bruger det som en del af deres konto opsætning, som værende hamrende useriøs."

Mange steder bruges det jo også kun til at få tilsendt et nyt PW, til den mail konto som man brugte, da man oprettet sin konto. Det synes jeg er en rimelig seriøs og nem løsning til at få et nyt PW. For os som ikke bruger same password alle steder, og ikke skriver dem ned. Vi glemmer jo en gang i mellem, eller man kan ikke huske at der har været et PW skift siden sidst.
mvh

11
16. oktober 2012 kl. 13:19

Som jeg ser det, så sammenligner de 2 forskellige situationer. Den ene er at man hasher (mange x hash(salt kode)) sine kodeord, gemmer dem i en database og angriberen får adgang til denne database. Den anden er at man benytter RSA's system og angriberen IKKE har adgang til disse 2 databaser. Det er da ikke en fair sammenligning?

Generelt er det en rigtig dum idé at splitte et kodeord (se bare MS-CHAPv2). Det er meget nemmere at cracke to svage hashes, end ét stærkt. (Med mindre jeg har misforstået noget, og det faktisk ikke er kodeordet, men hashet, som bliver splittet?)

Det er smart nok at dele sin database med hashes ud over flere platforme (så en fejl i den ene platform ikke giver fuld adgang til databasen), men det hjælper intet at blindt købe RSA's system og så bare tro at man er sikker (så er det væstentligt bedre givet ud, at købe en ordentlig udvikler til at lave et simpelt, men relativt sikkert, "mange x hash(salt kode)"-system).

5
16. oktober 2012 kl. 11:24

Det lange svar: Den længere hash virker ikke -- det er ikke kollisioner, der er risikoen, men rainbow tables og/eller brute force genkendelse af passwords på tværs af sites/systemer ud fra passwordlister.

Så ja, forskellig salt per bruger bør vær normen, og langsommere hashes (SHA-x familien er jo bevidst hurtig, nyttig til behandling/verifikation, men ikke til modvirkning af brute force).

Det korte svar: bcrypt

Jeg kan anbefalehttp://codahale.com/how-to-safely-store-a-password/

4
16. oktober 2012 kl. 10:39

Det kan godt være jeg spørger naivt; men hvorfor ikke bare benytte en længere digest (SHA-256/386/512) samt en dynamisk salt? Det første sørger for at kollisioner er meget få og det sidste sørger for at entropien er meget høj.

Man skulle mene der skal en meget kompetent og viljestærk cracker til for at udlede anvendelig information fra disse data. Eller er der noget jeg overser?

10
16. oktober 2012 kl. 13:03

Det kan godt være jeg spørger naivt; men hvorfor ikke bare benytte en længere digest (SHA-256/386/512) samt en dynamisk salt? Det første sørger for at kollisioner er meget få og det sidste sørger for at entropien er meget høj.

Det er en rigtigt dårlig ide. Problemet med en hash-funktion i sig selv er at den er hurtig. Den er skabt til at være hurtig - og nogen af de nyeste kandidater til SHA3 er virkeligt forbløffende hurtige. Du kan brute force den mange gange per sekund. Formålet med kryptografiske hashes er at sikre to andre egenskaber: Inversion og second pre-image resistance. Hvis du vil gemme passwords, så skal du have gang i PBKDF2, bcrypt eller scrypt. Generelt, skal du have fat i såkaldte key-derivation-functions der lader dig aflede en nøgle men også gør det dyrt at bryde den. Nogen af disse benytter kryptografiske hash-functions internt, mens andre ikke gør. Scrypt er specielt interessant fordi den er konstrueret således at den tvinger dig til at bruge en masse RAM og dermed gør det sværere at bygge specialhardware til at bryde med. Det er iøvrigt ikke så dyrt for en angriber at få hardware at det kun er stater der kan gøre det nu om dage.

12
16. oktober 2012 kl. 13:51

Det er en rigtigt dårlig ide. Problemet med en hash-funktion i sig selv er at den er hurtig. Den er skabt til at være hurtig - og nogen af de nyeste kandidater til SHA3 er virkeligt forbløffende hurtige. Du kan brute force den mange gange per sekund. Formålet med kryptografiske hashes er at sikre to andre egenskaber: Inversion og second pre-image resistance. Hvis du vil gemme passwords, så skal du have gang i PBKDF2, bcrypt eller scrypt. Generelt, skal du have fat i såkaldte key-derivation-functions der lader dig aflede en nøgle men også gør det dyrt at bryde den. Nogen af disse benytter kryptografiske hash-functions internt, mens andre ikke gør. Scrypt er specielt interessant fordi den er konstrueret således at den tvinger dig til at bruge en masse RAM og dermed gør det sværere at bygge specialhardware til at bryde med. Det er iøvrigt ikke så dyrt for en angriber at få hardware at det kun er stater der kan gøre det nu om dage.

Dét argument kom også op i en anden nylig tråd, og jeg har ærlig talt lidt svært ved at følge det. Jeg er med på, at ved at gøre noget arbitrært dyrt (CPU/RAM) har man købt sig en vis fysisk garanti her-og-nu mod angreb.

Men key-stretching er jo en stakket frist (næste års hardware er 66% hurtigere, næste års igen er yderligere 66% osv.) så hvorfor ikke istedet sørge for, at dét state-space der skal afprøves er så vanvittig stort, at selv med faktorer på 100, 1000 og 10000 i hardware performance, svarer det kun til at barbere 7-13 bit af f.eks. en SHA-256?

16
16. oktober 2012 kl. 17:01

Når du bruger bcrypt hasher du med en work factor. Et tal der ændrer mængden af arbejde det tager, et hashe en streng. Det er meningen at du skal tune din hash funktion til at tage acceptabelt lang tid at hashe en streng, til at det gør det meningsløst at brute force. Det løser kun problemet her og nu, men det gør det let at øge workload; du skal blot forøge en paremeter i hash funktionen. Derfor betyder udfaldsrummet ikke så meget, for det tager for lang tid at afsøge det.

Det flytter problemet et andet sted hen, men gør det lettere at kontrollere IMO.

17
16. oktober 2012 kl. 18:00

Nu formoder jeg at når vi snakker SHA256, så taler vi i praksis om en PBKDF2-HMAC-SHA256 med et iteration count der er sat højt nok til at den er så compute intensiv som man nu synes man vil ofre CPU tid på. Denne algoritme er også nem at finde gennemtestede og troværdige implementationer af til de fleste sprog.

Det og så et static+dynamic salt, så mener jeg altså man er godt kørende til de fleste website behov - medmindre man arbejder med meget sensitiv data. Jeg kan forstå at "bcrypt" reelt har et problem da den kan implementeres utrolig hurtig i en hardware-løsning, hvorfor man har lavet "scrypt" - men dette er stadig en forholdvis ny og uprøvet algoritme, som først for en måned siden er submitted til IETF. Jeg synes måske lige den skal have lov at modne lidt før jeg tør stole på den er så sikker som den lyder til på papiret.

15
16. oktober 2012 kl. 16:58

Og det kan kun gøres på en måde, nemlig ved at brugeren vælger et længere password. Hvis en bruger har valgt et af de 1000000 mest brugte passwords så skal en intelligent angriber kun afprøve disse 1000000 muligheder for at finde det, det kan hash funktionen ikke ændre på.

Men dét forudsætter at du har adgang til hashing-algoritmen (og salt), for ellers er disse 1000000 mulighedder jo distribuereret i et state-space på 2^256. Det har man vel ikke typisk for en lækket auth liste?!

6
16. oktober 2012 kl. 11:30

Casper: Det er næsten korrekt. Enig i at man ikke bør bruge mindre end SHA256 (tilgengæld mener jeg den er compute intensive nok til de fleste websiteløsninger) og at man bør anvende et dynamisk salt (unikt random nummer pr. bruger typisk gemt i databasen - et Guid plejer at virke fornuftigt hertil), men det er vigtigt at man også anvender et statisk salt derudover (gemt på webserveren) - det tilføjer et ekstra lag af sikkerhed hvis databasen skulle blive kompromiteret.

Jeg tror mest dette skal ses som reklame for RSA, for til de fleste website løsninger lyder det som temmelig overkill - vi har ikke brug for NSA-level security, vi har bare brug for at overliggeren bliver hævet lidt over cleartekst og MD5 niveau som pt. er det mest udbredte.

3
16. oktober 2012 kl. 10:37
  1. Udviklerne er for dovne til at håndtere passwords korrekt, med salts, flere runder hashing, etc.[1]
  2. RSA har en meget avanceret thingy-dingy funktion der kræver flere servere, nyt uprøvet software, tung løbende genberegning.

Umiddelbart er 2 meget mere besværlig end 1, så det er tvivlsomt om dovne udviklere vil implementere det. Jeg tror derfor ikke at dette løser LinkedIn problemet, men at dette kun er en inkrementiel forbedring når man har meget ekstreme sikkerhedskrav (og stor fokus på sikkerhed). Sådanne institutioner lækker dog sjældent information i første omgang.

[1] Eksempelvis små firmaer med skod-kodere. Det er ikke lang tid siden jeg fik mail fra et mindre dansk firma om, at de havde sat deres ubeskyttede database med passwords i klartekst på Internettet. For lige at gøre det nemmere at teste...

8
16. oktober 2012 kl. 11:56

LinkedIn problemet er bestemt ikke løst, da problemet i virkeligheden er 2 problemer. Ja, det er et problem at mange passwords bliver kompromitteret p.g.a. dårligt design, men det er bestemt et selvstændigt problem at folk bruger samme passwords på tværs af services. Der er jo andre måder at angribe passwords på end ved at læse gemte hashes.

Løsningen er at have færre passwords som vi mennesker skal huske. OpenID er én måde at løse dette på, Lastpass m.v. en anden, og en browserbaseret per-site sikkerhedsløsning kunne være en tredje (det bør i den sidste ende være op til brugeren at vælge hvor de lægger deres tillid og risiko)

2
16. oktober 2012 kl. 10:09

Hvordan skal man gøre det?

Som jeg forstår det så skal hver server gemme en del af koden under en eller anden hash med en eller anden salt. Altså hash(salt + passwordPart[12]) Hvordan kan den genberegnes uden at man gemmer passwordPart[12]? Og selv hvis passwordPart[12] er krypteret så skal begge servere enten være enige om krypteringsnøgle eller kende clear password for alle brugere. Og hvis så det ene system er kromprimenteret, hvad er det så man vinder?

Tydeligt et eller andet jeg misforstår, håber jeg.

9
16. oktober 2012 kl. 12:45

Man kan vel nøjes med at re-hashe den hash, man allerede har:

  1. (part1_1, part2_1) = split(hash(password + secret_1 + salt))

Dernæst genberegner man sådan her:

  1. part1_2 = hash(part1_1 + secret_2)
  2.  
  3. part2_2 = hash(part2_1 + secret_2)

Misforståelsen ligger nok i ordet "genberegning".

7
16. oktober 2012 kl. 11:35

De to halvdele svarer til to halvdele af hashen. Derved er det ikke nødvendigt at beholde passwordet i klar tekst.

1
16. oktober 2012 kl. 09:58

Såkaldte Sikkerhedsspørgsmål er en hån mod rigtig sikkerhed. Som regel kan de ting der spørges om kan findes med lidt socialt kendskab til personen. Jeg anser automatisk tjenester som bruger det som en del af deres konto opsætning, som værende hamrende useriøs.