Slack erkänner att ha läckt hashade lösenord i tre månader

Det populära samarbetsverktyget Slack (inte att förväxla med smeknamnet på världens äldsta Linux-distro, Slackware) har just ägt upp till en cybersäkerhets-SNAFU.

Enligt en nyhetsbulletin med titeln Meddelande om återställningar av Slack-lösenord, erkände företaget att det oavsiktligt hade delat över personuppgifter "när användare skapade eller återkallade en delad inbjudningslänk för sin arbetsyta."

Från 2022-04-17 till 2022-07-17 (vi antar att båda datumen är inklusive), sa Slack att uppgifterna som skickades till mottagarna av sådana inbjudningar inkluderade...

…vänta på det…

…de avsändarens hashade lösenord.

Vad gick fel?

Slacks säkerhetsråd förklarar inte intrånget särskilt tydligt, utan säger bara det "[detta hashade lösenord] var inte synligt för några Slack-klienter; att upptäcka det krävde att aktivt övervaka krypterad nätverkstrafik som kom från Slacks servrar.”

Vi gissar att detta översätts som följer:

"De flesta mottagare skulle inte ha märkt att den information de fick innehöll någon hashad lösenordsinformation, eftersom den informationen, även om den ingick i nätverkspaketen som skickades, aldrig visades medvetet för dem. Och eftersom datan skickades över en TLS-anslutning, skulle avlyssnare inte ha kunnat nosa upp det längs vägen, eftersom det inte skulle dekrypteras förrän det nådde andra änden av anslutningen.”

Det är de goda nyheterna.

Men nätverkspaket innehåller ofta data som aldrig normalt används eller ses av mottagarna.

HTTP-rubriker är ett bra exempel på detta, med tanke på att de är avsedda att vara instruktioner till din webbläsare, inte data för visning på webbsidan du tittar på.

Och data som är irrelevant eller osynlig för användare hamnar ofta i loggar ändå, särskilt i brandväggsloggar, där de skulle kunna bevaras på obestämd tid.

Det är de dåliga nyheterna.

Salta, hash och stretch...

Enligt Slack var de läckta uppgifterna inte bara hashade, Men saltade också, vilket innebär att varje användares lösenord först blandades ihop med slumpmässiga data som var unika för den användaren innan hash-funktionen användes.

Hashes är i huvudsak "icke-reversibla" matematiska funktioner som är lätta att beräkna i en riktning, men inte i den andra.

Det är till exempel lätt att beräkna att:

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

Men det enda sättet att arbeta "bakåt" från 7FB376..DEAD4B3AF008 till DUCK är att arbeta framåt från alla möjliga ord i ordboken och se om något av dem kommer ut med värdet du försöker matcha:

  SHA256("AARDVARK") = 5A9394..467731D0526A [X] SHA256("AARON") = C4DDDE..12E4CFE7B4FD [X] SHA256("ABACUS") = BEDDD8..1FE4DE25AAD7 [X]. . . 3400 hoppade över SHA256("BABBLE") = 70E837..CEAD4B1FA777 [X] SHA256("BADGER") = 946D0D..7B3073C1C094 [X] SHA256("SÄCKPIPE") = 359DBE.CB193FC.CB111FC.CB. . . 3200 hoppade över SHA256("CABAL") = D78CF4..85BE02967565 [X] SHA256("CACHE") = C118F9..22F3269E7B32 [X] SHA256("CAGOULE") = 5EA530C ..5F . . 26 hoppade över SHA5("DAB") = BBCC56E..E5400B256CAB8 [X] SHA8("DAFODIL") = 98D..D5128AB256A75121 [X] SHA6401("FARA") = 24BD98..256X]BB0..727C4..86037C065. . . 3500 hoppade över SHA256("DUCK") =  7FB376..DEAD4B3AF008 [HITTAD!]

Och genom att inkludera ett salt per användare, som inte behöver vara hemligt, utan bara unikt för varje användare, säkerställer du att även om två användare väljer samma lösenord, kommer de inte att få samma lösenordshash.

Du kan se effekten av saltning här, när vi hash ordet DUCK med tre olika prefix:

  SHA256("RANDOM1-DUCK") = E355DB..349E669BB9A2 SHA256("RANDOM2-DUCK") = 13D538..FEA0DC6DBB5C <-- Om du bara ändrar en indatabyte produceras en helt annan hash SHA256("AR3ADXX52H-92H. .544208A19449

Detta innebär också att angripare inte kan skapa en förberäknad lista över troliga hash-värden, eller skapa en tabell med partiella hash-beräkningar, så kallad en regnbågens bord, som kan påskynda hashkontroll. (De skulle behöva en helt ny hashlista, eller en unik uppsättning regnbågsbord, för varje möjligt salt.)

Med andra ord, hashade-och-saltade lösenord kan inte trivialt knäckas för att återställa den ursprungliga inmatningen, särskilt om det ursprungliga lösenordet var komplext och slumpmässigt valt.

Vad Slack inte sa är om de gjorde det sträckt lösenordet hash också, och i så fall hur.

Stretching är en jargongterm som innebär att man upprepar hashprocessen för lösenord om och om igen, till exempel 100,000 XNUMX gånger, för att förlänga tiden som behövs för att prova ett gäng ordboksord mot kända lösenordshashar.

Om det skulle ta en sekund att lägga 100,000 6 ordboksord genom en vanlig salt-och-hash-process, så skulle angripare som känner till ditt lösenordshash kunna prova XNUMX miljoner olika ordboksord och derivator varje minut, eller ta mer än en miljard gissningar var tredje timme .

Å andra sidan, om salt-och-hash-beräkningarna sträcktes ut till att ta en sekund vardera, så skulle den extra fördröjningen på en sekund när du försökte logga in orsaka lite eller ingen irritation för dig...

…men skulle minska en angripare till bara 3600 försök i timmen, vilket gör det mycket mindre troligt att de skulle få tillräckligt med tid för att gissa allt annat än de mest uppenbara lösenorden.

Flera väl respekterade salt-hash-and-stretch-algoritmer är kända, särskilt PBKDF2, bcrypt, scrypt och Argon2, som alla kan justeras för att öka den tid som behövs för att testa individuella lösenordsgissningar för att minska livskraften av så kallade ordbok och brute force attacker.

A ordbok attack betyder att du bara försöker med troliga lösenord, till exempel varje ord du kan komma på aardvark till zymurgyoch sedan ge upp. A brutal kraftattack innebär att man försöker alla möjliga input, även konstiga och outtalbara sådana, från AAA..AAAA till ZZZ..ZZZZ (eller från 0000..000000 till FFFF..FFFFFF om du tänker i hexadecimala termer byte-för-byte).

Vad göra?

Slack säger det om 1 av 200 av dess användare (0.5 %, förmodligen baserat på uppgifter om hur många delade inbjudningslänkar som genererades under riskperioden), och att det kommer att tvinga dessa användare att återställa sina lösenord.

Några ytterligare råd:

• Om du är en Slack-användare kan du lika gärna återställa ditt lösenord även om du inte blivit meddelad av företaget att göra det. När ett företag erkänner att det har slarvat med sin lösenordsdatabas genom att läcka hash kan du lika gärna anta att ditt drabbades, även om företaget tror att det inte var det. Så fort du ändrar ditt lösenord gör du den gamla hashen värdelös för angripare.
• Om du inte använder en lösenordshanterare, överväg att skaffa en. En lösenordshanterare hjälper till välja rätt lösenord, vilket säkerställer att ditt lösenord hamnar väldigt, väldigt långt ner i listan över lösenord som kan knäckas i en incident som denna. Angripare kan vanligtvis inte göra en äkta brute force-attack, eftersom det finns alldeles för många möjliga lösenord att testa. Så de försöker de mest troliga lösenorden först, som ord eller uppenbara kombinationer av ord och siffror, som blir längre och mer komplexa när attacken fortskrider. En lösenordshanterare kan komma ihåg ett slumpmässigt lösenord på 20 tecken lika enkelt som du kan komma ihåg din katts namn.
• Slå på 2FA om du kan. 2FA, eller tvåfaktorsautentisering, betyder att du inte bara behöver ditt lösenord för att logga in, utan även en engångskod som ändras varje gång. Dessa koder skickas vanligtvis till (eller genereras av) din mobiltelefon och är endast giltiga i några minuter vardera. Det betyder att även om cyberskurkar knäcker ditt lösenord så räcker det inte på egen hand för att de ska ta över ditt konto.
• Välj en ansedd salt-hash-and-stretch-algoritm när du själv hanterar lösenord.. I den olyckliga händelse att din lösenordsdatabas blir intrång, kommer du att kunna ge dina kunder exakta uppgifter om algoritmen och säkerhetsinställningarna du använde. Detta kommer att hjälpa välinformerade användare att själva bedöma hur troligt det är att deras stulna hash kan ha knäckts under den tid som är tillgänglig för angripare hittills.

---