Hjemmeside » hvordan » Hvorfor skal du bekymre dig, når en serviceens adgangskode database er lækket

    Hvorfor skal du bekymre dig, når en serviceens adgangskode database er lækket

    "Vores adgangskode database blev stjålet i går. Men bekymre dig ikke: dine adgangskoder blev krypteret. "Vi ser regelmæssigt udsagn som denne online, herunder i går fra Yahoo. Men skal vi virkelig tage disse forsikringer til pålydende?

    Virkeligheden er, at passorddatabase kompromiser er en bekymring, uanset hvordan et firma kan forsøge at spinde det. Men der er et par ting, du kan gøre for at isolere dig selv, uanset hvor dårligt virksomhedens sikkerhedspraksis er.

    Hvordan adgangskoder skal gemmes

    Sådan redigerer virksomheder adgangskoder i en ideel verden: Du opretter en konto og giver en adgangskode. I stedet for at opbevare selve kodeordet genererer tjenesten en "hash" fra adgangskoden. Dette er et unikt fingeraftryk, der ikke kan vendes. For eksempel kan passwordet "password" blive til noget, der ligner mere "4jfh75to4sud7gh93247g ...". Når du indtaster dit kodeord for at logge ind, genererer tjenesten en hash fra den og kontrollerer, om hashværdien matcher den værdi, der er gemt i databasen. På ingen måde redder tjenesten nogensinde dit kodeord til disk.

    For at bestemme din egentlige adgangskode skal en angriber med adgang til databasen forud beregne hashene for almindelige adgangskoder og derefter kontrollere, om de findes i databasen. Attackere gør dette med opslagstabeller - store lister over hash, der matcher adgangskoder. Hackerne kan derefter sammenlignes med databasen. F.eks. Vil en hacker kende hash for "password1" og derefter se om nogen konti i databasen bruger den hash. Hvis de er, ved angriberen, at deres adgangskode er "password1".

    For at forhindre dette skal tjenester "salt" deres hash. I stedet for at oprette en hash fra selve kodeordet tilføjer de en tilfældig streng til forsiden eller slutningen af ​​adgangskoden, før de har hash det. Med andre ord vil en bruger indtaste adgangskoden "adgangskode", og tjenesten vil tilføje saltet og hash et kodeord, der ligner mere "password35s2dg." Hver brugerkonto skal have deres eget unikke salt, og dette ville sikre, at hver brugerkonto ville have en anden hashværdi for deres adgangskode i databasen. Selvom flere konti brugte adgangskoden "password1", ville de have forskellige hash på grund af de forskellige saltværdier. Dette ville besejre en angriber, der forsøgte at forudregne hashes for adgangskoder. I stedet for at kunne generere hashser, der anvendes til hver brugerkonto i hele databasen på en gang, skulle de have genereret unikke hash'er for hver brugerkonto og dens unikke salt. Dette ville tage meget mere beregningstid og hukommelse.

    Derfor siger tjenestegrene ofte ikke at bekymre sig. En tjeneste ved hjælp af ordentlige sikkerhedsprocedurer skal sige, at de bruger saltet adgangskode hashes. Hvis de blot siger, at adgangskoderne er "hashed", er det mere bekymrende. LinkedIn har f.eks. Deres adgangskoder, men de har ikke saltet dem - så det var en big deal, da LinkedIn mistede 6,5 millioner hashed-adgangskoder i 2012.

    Dårlige adgangskoder

    Dette er ikke det sværeste at implementere, men mange hjemmesider klarer stadig at ødelægge det på en række måder:

    • Lagring af adgangskoder i almindelig tekst: I stedet for at bryde med hashing, kan nogle af de værste lovovertrædere bare dumpe adgangskoderne i almindelig tekstformular til en database. Hvis en sådan database er kompromitteret, er dine adgangskoder naturligvis kompromitteret. Det ville ligegyldigt hvor stærkt de var.
    • Hashing adgangskoderne uden at saltede dem: Nogle tjenester kan hash adgangskoderne og give op der, vælger ikke at bruge salte. Sådanne adgangskode databaser ville være meget sårbare for opslagstabeller. En angriber kan generere hash for mange adgangskoder og derefter kontrollere, om de eksisterede i databasen - de kunne gøre det for hver konto på én gang, hvis der ikke blev brugt salt.
    • Genbrug af salte: Nogle tjenester kan bruge et salt, men de må muligvis genbruge det samme salt for hver adgangskode til brugerkonto. Dette er meningsløst - hvis det samme salt blev brugt til hver bruger, ville to brugere med samme adgangskode have samme hash.
    • Brug af korte salte: Hvis der anvendes salte af kun få cifre, ville det være muligt at generere opslagstabeller, der inkorporerede alt muligt salt. For eksempel, hvis et enkelt tal blev brugt som et salt, kunne angriberen nemt oprette lister over hash, der inkorporerede alt muligt salt.

    Virksomheder vil ikke altid fortælle dig hele historien, så selvom de siger, at et kodeord var hashed (eller hashed og saltet), kan de ikke bruge de bedste metoder. Forsvigt altid på forsigtighedssiden.

    Andre bekymringer

    Det er sandsynligt, at saltværdien også er til stede i adgangskodedatabasen. Dette er ikke så dårligt - hvis en unik saltværdi blev brugt til hver bruger, ville angriberne skulle bruge massive mængder af CPU-strøm, der bryder alle disse adgangskoder.

    I praksis bruger så mange personer indlysende adgangskoder, at det sandsynligvis vil være nemt at bestemme mange brugerkontos adgangskoder. Hvis en angriber f.eks. Kender din hash, og de kender dit salt, kan de let kontrollere, om du bruger nogle af de mest almindelige adgangskoder.

    Hvis en angriber har det for dig og ønsker at knække dit kodeord, kan de gøre det med brute force, så længe de kender saltværdien - som de sandsynligvis gør. Med lokal, offline adgang til adgangskode databaser, kan angriberne ansætte alle de brutale kraftangreb, de ønsker.

    Andre personoplysninger ligner også sandsynligvis, når en adgangskode database er stjålet: Brugernavne, email adresser og meget mere. I tilfælde af Yahoo's lækage blev også sikkerhedsspørgsmål og svar lækket - hvilket som vi alle ved, gør det nemmere at stjæle adgangen til en persons konto.

    Hjælp, hvad skal jeg gøre?

    Uanset hvad en tjeneste siger, når dens adgangskode er stjålet, er det bedst at antage, at hver tjeneste er fuldstændig inkompetent og handle i overensstemmelse hermed.

    For det første må du ikke genbruge adgangskoder på flere websteder. Brug en adgangskodeadministrator, der genererer unikke adgangskoder til hver hjemmeside. Hvis en hacker klarer at opdage, at din adgangskode til en tjeneste er "43 ^ tSd% 7uho2 # 3", og du kun bruger adgangskoden på den ene specifikke hjemmeside, har de ikke lært noget nyttigt. Hvis du bruger den samme adgangskode overalt, kunne de få adgang til dine andre konti. Dette er, hvor mange folks konti bliver "hacket".

    Hvis en tjeneste bliver kompromitteret, skal du sørge for at ændre den adgangskode, du bruger der. Du skal også ændre adgangskoden på andre websteder, hvis du genbruger den der - men du bør ikke gøre det i første omgang.

    Du bør også overveje at bruge to-faktor-autentificering, hvilket vil beskytte dig, selvom en angriber lærer dit kodeord.

    Det vigtigste er ikke at genbruge adgangskoder. Kompromitterede adgangskode databaser kan ikke skade dig, hvis du bruger en unik adgangskode overalt - medmindre de gemmer noget andet vigtigt i databasen, som dit kreditkortnummer.

    Billedkredit: Marc Falardeau på Flickr, Wikimedia Commons