Slack indrømmer at have lækket hashed kodeord i tre måneder

Det populære samarbejdsværktøj Slack (ikke at forveksle med kaldenavnet på verdens længst kørende Linux-distro, Slackware) har netop ejet op til en cybersikkerheds-SNAFU.

Ifølge en nyhedsbulletin med titlen Meddelelse om Slack-nulstilling af adgangskode, indrømmede virksomheden, at den utilsigtet havde overdelt personlige data "når brugere oprettede eller tilbagekaldte et delt invitationslink til deres arbejdsområde."

Fra 2022-04-17 til 2022-07-17 (vi antager, at begge datoer er inklusive), sagde Slack, at de data, der blev sendt til modtagerne af sådanne invitationer, omfattede...

…vente på det…

…det afsenderens hash-kodede kode.

Hvad gik galt?

Slacks sikkerhedsrådgivning forklarer ikke bruddet særlig tydeligt og siger blot det "[d]ent hashkodede kodeord var ikke synligt for nogen Slack-klienter; at opdage det krævede aktiv overvågning af krypteret netværkstrafik, der kom fra Slacks servere."

Vi gætter på, at dette oversættes som følger:

"De fleste modtagere ville ikke have bemærket, at de data, de modtog, indeholdt hash-kodeordsoplysninger, fordi disse oplysninger, selv om de var inkluderet i de sendte netværkspakker, aldrig bevidst blev vist til dem. Og fordi dataene blev sendt over en TLS-forbindelse, ville aflyttere ikke have været i stand til at opsnuse det undervejs, fordi det ikke ville blive dekrypteret, før det nåede den anden ende af forbindelsen."

Det er den gode nyhed.

Men netværkspakker indeholder ofte data, der aldrig normalt bruges eller ses af modtagere.

HTTP-headere er et godt eksempel på dette, da de er beregnet til at være instruktioner til din browser, ikke data til visning på den webside, du kigger på.

Og data, der er irrelevante eller usynlige for brugere, ender ofte alligevel i logfiler, især i firewall-logfiler, hvor de kunne bevares på ubestemt tid.

Det er de dårlige nyheder.

Salt, hash og stretch...

Ifølge Slack var de lækkede data ikke blot hash'et, men saltet også, hvilket betyder, at hver brugers adgangskode først blev blandet sammen med tilfældige data, der var unikke for den pågældende bruger, før hash-funktionen blev anvendt.

Hashes er i det væsentlige "ikke-reversible" matematiske funktioner, som er nemme at beregne i den ene retning, men ikke i den anden.

For eksempel er det nemt at beregne, at:

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

Men den eneste måde at arbejde "baglæns" fra 7FB376..DEAD4B3AF008 til DUCK er at arbejde fremad fra alle mulige ord i ordbogen og se, om nogen af ​​dem kommer ud med den værdi, du prøver at matche:

  SHA256("AARDVARK") = 5A9394..467731D0526A [X] SHA256("AARON") = C4DDDE..12E4CFE7B4FD [X] SHA256("ABACUS") = BEDDD8..1FE4DE25AAD7 [X] . . 3400 sprunget over SHA256("BABBLE") = 70E837..CEAD4B1FA777 [X] SHA256("BADGER") = 946D0D..7B3073C1C094 [X] SHA256("BAGPIPE") = 359DBE.CB193FC.CB111FC.X. . . 3200 sprunget over SHA256("CABAL") = D78CF4..85BE02967565 [X] SHA256("CACHE") = C118F9..22F3269E7B32 [X] SHA256("CAGOULE") = 5EA530C ..5F . . 26 sprunget over SHA5("DAB") = BBCC56E..E5400B256CAB8 [X] SHA8("PASILJE") = 98D..D5128AB256A75121 [X] SHA6401("FARE") = 24BD98..256XBB0..727X4BB86037. . . 065 sprunget over SHA3500("AND") =  7FB376..DEAD4B3AF008 [FUNDET!]

Og ved at inkludere et per-bruger salt, som ikke behøver at være hemmeligt, blot unikt for hver bruger, sikrer du, at selvom to brugere vælger den samme adgangskode, ender de ikke med den samme adgangskode-hash.

Du kan se effekten af ​​saltning her, når vi hash ordet DUCK med tre forskellige præfikser:

  SHA256("RANDOM1-DUCK") = E355DB..349E669BB9A2 SHA256("RANDOM2-DUCK") = 13D538..FEA0DC6DBB5C <-- Ændring af kun én inputbyte producerer en helt anden hash SHA256("AR3AD52H-92H). .544208A19449

Dette betyder også, at angribere ikke kan oprette en forudberegnet liste over sandsynlige hashes eller oprette en tabel med delvise hash-beregninger, kendt som en regnbue bord, der kan fremskynde hash-tjek. (De har brug for en helt ny hashliste eller et unikt sæt regnbueborde for hvert muligt salt.)

Med andre ord kan hashed-og-saltede adgangskoder ikke trivielt knækkes for at gendanne det originale input, især hvis det originale kodeord var komplekst og tilfældigt valgt.

Hvad Slack ikke sagde er, om de ville strakt kodeordet hashes også, og hvis ja, hvordan.

Stretching er et jargonbegreb, der betyder at gentage adgangskode-hash-processen igen og igen, for eksempel 100,000 gange, for at forlænge den tid, der er nødvendig for at prøve en masse ordbogsord mod kendte password-hashes.

Hvis det ville tage et sekund at sætte 100,000 ordbogsord igennem en almindelig salt-og-hash-proces, så kunne angribere, der kender din adgangskode-hash, prøve 6 millioner forskellige ordbogsord og afledninger hvert minut eller tage mere end en milliard gæt hver tredje time .

På den anden side, hvis salt-og-hash-beregningerne blev strakt til at tage et sekund hver, så ville den ekstra forsinkelse på et sekund, når du forsøgte at logge ind, forårsage ringe eller ingen irritation for dig...

…men ville reducere en angriber til kun 3600 forsøg i timen, hvilket gør det meget mindre sandsynligt, at de ville få tid nok til at gætte andet end de mest åbenlyse adgangskoder.

Adskillige velrespekterede salt-hash-and-stretch-algoritmer er kendt, især PBKDF2, bcrypt, scrypt , Argon2, som alle kan justeres for at øge den tid, der er nødvendig for at prøve individuelle adgangskoder for at reducere levedygtigheden af såkaldte ordbog og brute force angreb.

A ordbog angreb betyder, at du kun prøver sandsynlige adgangskoder, såsom hvert eneste ord, du kan tænke på aardvark til zymurgy, og så give op. EN brute-force angreb betyder at prøve alle mulige input, selv underlige og uudtalelige, fra AAA..AAAA til ZZZ..ZZZZ (eller fra 0000..000000 til FFFF..FFFFFF hvis du tænker i hexadecimale byte-for-byte termer).

Hvad skal jeg gøre?

Slack siger det om 1 ud af 200 af sine brugere (0.5 %, formentlig baseret på registreringer af, hvor mange delte invitationslinks, der blev genereret i fareperioden), og at det vil tvinge disse brugere til at nulstille deres adgangskoder.

Nogle yderligere råd:

• Hvis du er Slack-bruger, kan du lige så godt nulstille din adgangskode, selvom du ikke har fået besked fra virksomheden om at gøre det. Når en virksomhed indrømmer, at den har været skødesløs med sin adgangskodedatabase ved at lække hashes, kan du lige så godt antage, at din var berørt, selvom virksomheden mener, den ikke var det. Så snart du ændrer din adgangskode, gør du den gamle hash ubrugelig for angribere.
• Hvis du ikke bruger en adgangskodeadministrator, kan du overveje at få en. En password manager hjælper til vælge de rigtige adgangskoder, hvilket sikrer, at din adgangskode ender meget, meget langt nede på listen over adgangskoder, der kan blive knækket i en hændelse som denne. Angribere kan typisk ikke udføre et ægte brute force-angreb, fordi der bare er for mange mulige adgangskoder til at prøve. Så de prøver de mest sandsynlige adgangskoder først, såsom ord eller åbenlyse ord-og-tal kombinationer, bliver længere og mere komplekse, efterhånden som angrebet skrider frem. En adgangskodeadministrator kan huske en tilfældig adgangskode på 20 tegn lige så let, som du kan huske din kats navn.
• Slå 2FA til, hvis du kan. 2FA, eller to-faktor autentificering, betyder, at du ikke kun skal bruge din adgangskode for at logge ind, men også en engangskode, der ændres hver gang. Disse koder sendes typisk til (eller genereres af) din mobiltelefon og er kun gyldige i et par minutter hver. Det betyder, at selvom cyberskurke knækker din adgangskode, er det ikke nok alene for dem at overtage din konto.
• Vælg en velrenommeret salt-hash-and-stretch-algoritme, når du selv håndterer adgangskoder.. I det uheldige tilfælde, at din adgangskodedatabase bliver brudt, vil du være i stand til at give dine kunder præcise detaljer om algoritmen og de sikkerhedsindstillinger, du har brugt. Dette vil hjælpe velinformerede brugere til selv at vurdere, hvor sandsynligt det er, at deres stjålne hash kan være blevet knækket i den tid, der er til rådighed for angriberne indtil videre.

---