Hvorfor du burde bekymre når en tjenestens passorddatabase er lekket

Innholdsfortegnelse:

Hvorfor du burde bekymre når en tjenestens passorddatabase er lekket
Hvorfor du burde bekymre når en tjenestens passorddatabase er lekket

Video: Hvorfor du burde bekymre når en tjenestens passorddatabase er lekket

Video: Hvorfor du burde bekymre når en tjenestens passorddatabase er lekket
Video: How to Sync your Google Chrome Bookmarks - YouTube 2024, Mars
Anonim
"Vår passorddatabase ble stjålet i går. Men ikke bekymre deg: passordene dine ble kryptert. "Vi ser regelmessig uttalelser som denne online, inkludert i går, fra Yahoo. Men bør vi virkelig ta disse forsikringene til pålydende?
"Vår passorddatabase ble stjålet i går. Men ikke bekymre deg: passordene dine ble kryptert. "Vi ser regelmessig uttalelser som denne online, inkludert i går, fra Yahoo. Men bør vi virkelig ta disse forsikringene til pålydende?

Virkeligheten er at passorddatabase-kompromisser er en bekymring, uansett hvordan et selskap kan prøve å spinne det. Men det er noen ting du kan gjøre for å isolere deg selv, uansett hvor ille et selskaps sikkerhetspraksis er.

Hvordan passord skal lagres

Slik lager bedrifter passord i en ideell verden: Du oppretter en konto og gir et passord. I stedet for å lagre passordet selv, genererer tjenesten en "hash" fra passordet. Dette er et unikt fingeravtrykk som ikke kan reverseres. For eksempel kan passordet "passord" bli til noe som ser mer ut som "4jfh75to4sud7gh93247g …". Når du skriver inn passordet ditt for å logge på, genererer tjenesten en hash fra den og kontrollerer om hashverdien samsvarer med verdien som er lagret i databasen. På noe tidspunkt lagrer tjenesten aldri passordet ditt selv på disken.

For å bestemme ditt egentlige passord, må en angriper med tilgang til databasen forhåndskomprimere hashene for vanlige passord og deretter sjekke om de eksisterer i databasen. Attackers gjør dette med oppslagstabeller - store lister over hashes som samsvarer med passord. Hasjene kan da sammenlignes med databasen. For eksempel vil en angriper vite hash for "password1" og deretter se om noen kontoer i databasen bruker den hashen. Hvis de er, vet angriperen at passordet er "passord1".
For å bestemme ditt egentlige passord, må en angriper med tilgang til databasen forhåndskomprimere hashene for vanlige passord og deretter sjekke om de eksisterer i databasen. Attackers gjør dette med oppslagstabeller - store lister over hashes som samsvarer med passord. Hasjene kan da sammenlignes med databasen. For eksempel vil en angriper vite hash for "password1" og deretter se om noen kontoer i databasen bruker den hashen. Hvis de er, vet angriperen at passordet er "passord1".

For å forhindre dette, bør tjenestene "salt" deres hashes. I stedet for å lage en hash fra selve passordet, legger de til en tilfeldig streng til forsiden eller slutten av passordet før de har hash det. Med andre ord, vil en bruker legge inn passordet "passord" og tjenesten vil legge til salt og hash et passord som ser mer ut som "password35s2dg." Hver brukerkonto skal ha sitt eget unike salt, og dette vil sikre at hver brukerkonto ville ha en annen hashverdi for deres passord i databasen. Selv om flere kontoer brukte passordet "passord1", ville de ha forskjellige hash på grunn av de forskjellige saltverdiene. Dette ville beseire en angriper som prøvde å forhåndsberegne hashes for passord. I stedet for å kunne generere hashes som brukes på hver brukerkonto i hele databasen samtidig, må de generere unike hashes for hver brukerkonto og dens unike salt. Dette ville ta mye mer beregningstid og minne.

Derfor sier tjenestene ofte ikke å bekymre seg. En tjeneste som bruker riktige sikkerhetsprosedyrer, bør si at de bruker saltet passord hashes. Hvis de bare sier passordene er "hashed", er det mer bekymringsfullt. LinkedIn hashed sine passord, for eksempel, men de har ikke saltet dem - så det var en stor avtale da LinkedIn mistet 6,5 millioner hashed passord i 2012.

Dårlig passord praksis

Dette er ikke det vanskeligste å implementere, men mange nettsteder klarer fortsatt å ødelegge det på en rekke måter:
Dette er ikke det vanskeligste å implementere, men mange nettsteder klarer fortsatt å ødelegge det på en rekke måter:
  • Lagre passord i vanlig tekst: I stedet for å plage med hashing, kan noen av de verste lovbryterne bare dumpe passordene i vanlig tekstform til en database. Hvis en slik database er kompromittert, er passordene dine åpenbart skadet. Det ville ikke ha betydning hvor sterk de var.
  • Hashing passordene uten å saltet dem: Noen tjenester kan hash passordene og gi opp der, velger ikke å bruke salter. Slike passorddatabaser vil være svært sårbare for oppslagstabeller. En angriper kan generere hashene for mange passord og deretter sjekke om de eksisterte i databasen - de kunne gjøre dette for hver konto på en gang hvis ikke noe salt ble brukt.
  • Gjenbruk av salter: Noen tjenester kan bruke et salt, men de kan bruke det samme saltet for hvert brukerkontopassord. Dette er meningsløst - hvis det samme saltet ble brukt for hver bruker, ville to brukere med samme passord ha samme hash.
  • Bruk av korte salter: Hvis det brukes salter av bare noen få siffer, ville det være mulig å generere oppslagstabeller som innlemmet alt mulig salt. For eksempel, hvis et enkelt siffer ble brukt som et salt, kunne angriperen enkelt generere lister over hashes som innlemmet alt mulig salt.

Bedrifter vil ikke alltid fortelle deg hele historien, så selv om de sier at et passord ble hashed (eller hashed og saltet), kan de ikke bruke de beste metodene. Ta alltid feil på forsiktighetssiden.

Andre bekymringer

Det er sannsynlig at saltverdien også er til stede i passorddatabasen. Dette er ikke så ille - hvis en unik saltverdi ble brukt for hver bruker, ville angriperne måtte bruke massive mengder CPU-strømbrudd på alle disse passordene.

I praksis bruker så mange personer åpenbare passord at det sannsynligvis vil være lett å fastslå mange brukerkontoeres passord. Hvis en angriper for eksempel kjenner hash og de vet ditt salt, kan de lett sjekke for å se om du bruker noen av de vanligste passordene.

Hvis en angriper har det ut for deg og ønsker å knekke passordet ditt, kan de gjøre det med brute force så lenge de vet saltverdien, som de sannsynligvis gjør.Med lokal, offline tilgang til passorddatabaser, kan angriperne bruke alle de brute force-angrepene de vil ha.

Andre personopplysninger lekker også sannsynligvis når en passorddatabase er stjålet: Brukernavn, e-postadresser og mer. I tilfelle av Yahoo-lekkasjen ble sikkerhetsspørsmål og svar også lekket - som, som vi alle vet, gjør det lettere å stjele tilgangen til noen konto.

Hjelp, hva skal jeg gjøre?

Uansett hva en tjeneste sier når passorddatabasen er stjålet, er det best å anta at hver tjeneste er helt inkompetent og handle i samsvar med dette.

Først må du ikke bruke passord på flere nettsteder. Bruk en passordbehandling som genererer unike passord for hvert nettsted. Hvis en angriper klarer å oppdage at passordet ditt for en tjeneste er "43 ^ tSd% 7uho2 # 3", og du bare bruker passordet på det ene bestemte nettstedet, har de ikke lært noe nyttig. Hvis du bruker det samme passordet overalt, kan de få tilgang til de andre kontoene dine. Dette er hvor mange menneskers kontoer blir "hacket".

Hvis en tjeneste blir kompromittert, må du passe på å endre passordet du bruker der. Du bør også endre passordet på andre nettsteder hvis du bruker det der igjen - men du bør ikke gjøre det i utgangspunktet.
Hvis en tjeneste blir kompromittert, må du passe på å endre passordet du bruker der. Du bør også endre passordet på andre nettsteder hvis du bruker det der igjen - men du bør ikke gjøre det i utgangspunktet.

Du bør også vurdere å bruke tofaktorautentisering, som vil beskytte deg selv om en angriper lærer passordet ditt.

Det viktigste er ikke å gjenbruke passord. Kompromitterte passorddatabaser kan ikke skade deg hvis du bruker et unikt passord overalt - med mindre de lagrer noe annet viktig i databasen, som ditt kredittkortnummer.

Anbefalt: