Slack innrømmer å ha lekket hash-passord i tre måneder

Det populære samarbeidsverktøyet Slack (ikke å forveksle med kallenavnet til verdens lengste Linux-distro, Slackware) har nettopp eid opp til en cybersikkerhets-SNAFU.

I følge en nyhetsbulletin med tittelen Merknad om tilbakestilling av Slack-passord, innrømmet selskapet at det utilsiktet hadde overdelt personopplysninger "når brukere opprettet eller tilbakekalte en delt invitasjonskobling for arbeidsområdet sitt."

Fra 2022-04-17 til 2022-07-17 (vi antar at begge datoene er inkludert), sa Slack at dataene som ble sendt til mottakerne av slike invitasjoner inkluderte...

…vent på det…

…de avsenderens hashed passord.

Hva gikk galt?

Slacks sikkerhetsråd forklarer ikke bruddet veldig tydelig, og sier bare det «[d]ent hash-passord var ikke synlig for noen Slack-klienter; å oppdage det krevde aktiv overvåking av kryptert nettverkstrafikk som kom fra Slacks servere."

Vi tipper at dette oversettes som følger:

"De fleste mottakere ville ikke ha lagt merke til at dataene de mottok inkluderte hash passordinformasjon, fordi denne informasjonen, selv om den var inkludert i nettverkspakkene som ble sendt, aldri ble vist til dem med vilje. Og fordi dataene ble sendt over en TLS-tilkobling, ville avlyttere ikke ha vært i stand til å snuse dem opp underveis, fordi de ikke ville bli dekryptert før de nådde den andre enden av forbindelsen.»

Det er den gode nyheten.

Men nettverkspakker inkluderer ofte data som aldri normalt blir brukt eller sett av mottakere.

HTTP-hoder er et godt eksempel på dette, gitt at de er ment å være instruksjoner til nettleseren din, ikke data for visning på nettsiden du ser på.

Og data som er irrelevante eller usynlige for brukere, ender ofte opp i logger uansett, spesielt i brannmurlogger, hvor de kan bli bevart på ubestemt tid.

Det er de dårlige nyhetene.

Salt, hasj og stretch...

Ifølge Slack var de lekkede dataene ikke bare hashet, men saltet også, noe som betyr at hver brukers passord først ble blandet sammen med tilfeldige data unike for den brukeren før hash-funksjonen ble brukt.

Hashes er i hovedsak "ikke-reversible" matematiske funksjoner som er enkle å beregne i én retning, men ikke i den andre.

For eksempel er det enkelt å beregne at:

  SHA256("DUCK") = 7FB376..DEAD4B3AF008

Men den eneste måten å jobbe "bakover" fra 7FB376..DEAD4B3AF008 til DUCK er å jobbe forover fra alle mulige ord i ordboken og se om noen av dem kommer ut med verdien du prøver å matche:

  SHA256("AARDVARK") = 5A9394..467731D0526A [X]
  SHA256("AARON") = C4DDDE..12E4CFE7B4FD [X]
  SHA256("ABACUS") = BEDDD8..1FE4DE25AAD7 [X]
  . . . 3400 hoppet over
  SHA256("BABBLE") = 70E837..CEAD4B1FA777 [X]
  SHA256("BADGER") = 946D0D..7B3073C1C094 [X]
  SHA256("BAGPIPE") = 359DBE..BE193FCCB111 [X]
  . . . 3200 hoppet over
  SHA256("CABAL") = D78CF4..85BE02967565 [X]
  SHA256("CACHE") = C118F9..22F3269E7B32 [X]
  SHA256("CAGOULE") = 5EA530..5A26C5B56DCF [X]
  . . . 5400 hoppet over
  SHA256("DAB") = BBCC8E..E8B98CAB5128 [X]
  SHA256("DEFFODIL") = 75121D..D6401AB24A98 [X]
  SHA256("FARE") = 0BD727..4C86037BB065 [X]
  . . . 3500 hoppet over
  SHA256("DUCK") =  7FB376..DEAD4B3AF008 [FANT!]

Og ved å inkludere et per-bruker salt, som ikke trenger å være hemmelig, bare unikt for hver bruker, sikrer du at selv om to brukere velger det samme passordet, vil de ikke ende opp med samme passordhash.

Du kan se effekten av salting her, når vi hash ordet DUCK med tre forskjellige prefikser:

  SHA256("RANDOM1-DUCK") = E355DB..349E669BB9A2
  SHA256("RANDOM2-DUCK") = 13D538..FEA0DC6DBB5C <-- Endring av bare én inngangsbyte produserer en helt annen hash
  SHA256("ARXXQ3H-DUCK") = 52AD92..544208A19449

Dette betyr også at angripere ikke kan lage en forhåndsberegnet liste over sannsynlige hash, eller lage en tabell med delvise hash-beregninger, kjent som en regnbuebord, som kan fremskynde hasj-sjekking. (De trenger en helt ny hashliste, eller et unikt sett med regnbuebord, for hvert mulig salt.)

Med andre ord, hashed-og-saltede passord kan ikke knekkes trivielt for å gjenopprette den opprinnelige inngangen, spesielt hvis det opprinnelige passordet var komplekst og tilfeldig valgt.

Det Slack ikke sa er om de gjorde det strakte passordet hashes også, og i så fall hvordan.

Stretching er et sjargongbegrep som betyr å gjenta passordhashing-prosessen om og om igjen, for eksempel 100,000 XNUMX ganger, for å forlenge tiden som trengs for å prøve ut en haug med ordbokord mot kjente passordhasher.

Hvis det ville ta ett sekund å sette 100,000 6 ordbokord gjennom en vanlig salt-og-hash-prosess, kan angripere som kjenner passordhashen din prøve XNUMX millioner forskjellige ordbokord og avledninger hvert minutt, eller gjøre mer enn én milliard gjetninger hver tredje time .

På den annen side, hvis salt-og-hash-beregningene ble strukket til å ta ett sekund hver, så ville den ekstra forsinkelsen på ett sekund når du prøvde å logge på forårsake liten eller ingen irritasjon for deg...

...men vil redusere en angriper til bare 3600 forsøk i timen, noe som gjør det mye mindre sannsynlig at de får nok tid til å gjette alt annet enn de mest åpenbare passordene.

Flere velrespekterte salt-hash-and-stretch-algoritmer er kjent, spesielt PBKDF2, bcrypt, scrypt og Argon2, som alle kan justeres for å øke tiden som trengs for å prøve individuelle passordgjettinger for å redusere levedyktigheten av såkalte ordbok- og brute force-angrep.

A ordbok angrep betyr at du bare prøver sannsynlige passord, for eksempel hvert ord du kan tenke på aardvark til zymurgy, og så gi opp. EN brutalt styrkeangrep betyr å prøve alle mulige innspill, selv rare og uuttalelige, fra AAA..AAAA til ZZZ..ZZZZ (eller fra 0000..000000 til FFFF..FFFFFF hvis du tenker i heksadesimale termer byte-for-byte).

Hva gjør jeg?

Slack sier det om 1 av 200 av brukerne (0.5 %, antagelig basert på registreringer av hvor mange delte invitasjonslenker som ble generert i fareperioden), og at det vil tvinge disse brukerne til å tilbakestille passordene sine.

Noen flere råd:

• Hvis du er en Slack-bruker, kan du like godt tilbakestille passordet ditt selv om du ikke ble varslet av selskapet om å gjøre det. Når et selskap innrømmer at det har vært uforsiktig med passorddatabasen sin ved å lekke hasjer, kan du like gjerne anta at din ble berørt, selv om selskapet tror det ikke var det. Så snart du endrer passordet ditt, gjør du den gamle hashen ubrukelig for angripere.
• Hvis du ikke bruker en passordbehandling, bør du vurdere å skaffe deg en. En passordbehandler hjelper til velg riktige passord, og dermed sikre at passordet ditt havner veldig, veldig langt nede på listen over passord som kan bli knekt i en hendelse som dette. Angripere kan vanligvis ikke utføre et ekte brute force-angrep, fordi det er for mange mulige passord å prøve ut. Så de prøver de mest sannsynlige passordene først, for eksempel ord eller åpenbare ord-og-tall-kombinasjoner, og blir lengre og mer komplekse etter hvert som angrepet fortsetter. En passordbehandler kan huske et tilfeldig passord på 20 tegn like enkelt som du kan huske kattens navn.
• Slå på 2FA hvis du kan. 2FA, eller tofaktorautentisering, betyr at du ikke bare trenger passordet ditt for å logge inn, men også en engangskode som endres hver gang. Disse kodene sendes vanligvis til (eller genereres av) mobiltelefonen din, og er kun gyldige i noen få minutter hver. Dette betyr at selv om cybercrooks knekker passordet ditt, er det ikke nok alene for dem å ta over kontoen din.
• Velg en anerkjent salt-hash-and-stretch-algoritme når du håndterer passord selv.. I det uheldige tilfellet at passorddatabasen din blir brutt, vil du kunne gi kundene dine nøyaktige detaljer om algoritmen og sikkerhetsinnstillingene du brukte. Dette vil hjelpe velinformerte brukere til å vurdere selv hvor sannsynlig det er at deres stjålne hashen kan ha blitt knekt i løpet av tiden som er tilgjengelig for angripere så langt.

---