Slack admite haber filtrado contraseñas hash durante tres meses

La popular herramienta de colaboración Slack (que no debe confundirse con el apodo de la distribución de Linux más antigua del mundo, Slackware) acaba de reconocer un SNAFU de ciberseguridad.

Según un boletín de noticias titulado Aviso sobre restablecimientos de contraseña de Slack, la empresa admitió que inadvertidamente había estado compartiendo datos personales en exceso “cuando los usuarios crearon o revocaron un enlace de invitación compartido para su espacio de trabajo”.

Desde el 2022 de abril de 04 hasta el 17 de julio de 2022 (asumimos que ambas fechas son inclusive), Slack dijo que los datos enviados a los destinatarios de tales invitaciones incluían...

…espéralo…

…la contraseña hash del remitente.

¿Qué salió mal?

El aviso de seguridad de Slack no explica la brecha con mucha claridad, solo dice que “[e]sta contraseña cifrada no era visible para ningún cliente de Slack; descubrirlo requirió monitorear activamente el tráfico de red encriptado proveniente de los servidores de Slack”.

Suponemos que esto se traduce de la siguiente manera:

“La mayoría de los destinatarios no se habrían dado cuenta de que los datos que recibieron incluían información de contraseña codificada, porque esa información, aunque incluida en los paquetes de red enviados, nunca se les mostró deliberadamente. Y debido a que los datos se enviaron a través de una conexión TLS, los intrusos no habrían podido detectarlos en el camino, porque no se descifrarían hasta que llegaran al otro extremo de la conexión”.

Esa es la buena noticia.

Pero los paquetes de red a menudo incluyen datos que normalmente los destinatarios nunca usan o ven.

Los encabezados HTTP son un buen ejemplo de esto, dado que están destinados a ser instrucciones para su navegador, no datos para mostrar en la página web que está viendo.

Y los datos que son irrelevantes o invisibles para los usuarios a menudo terminan en los registros de todos modos, especialmente en los registros del firewall, donde podrían conservarse indefinidamente.

Esa es la mala noticia.

Sal, hachís y stretch…

Según Slack, los datos filtrados no eran simplemente hash, pero salado también, lo que significa que la contraseña de cada usuario se mezcló primero con datos aleatorios exclusivos de ese usuario antes de que se aplicara la función hash.

Los hashes son esencialmente funciones matemáticas "no reversibles" que son fáciles de calcular en una dirección, pero no en la otra.

Por ejemplo, es fácil calcular que:

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

Pero la única manera de trabajar "hacia atrás" desde 7FB376..DEAD4B3AF008 a DUCK es trabajar hacia adelante de cada palabra posible en el diccionario y vea si alguna de ellas sale con el valor que está tratando de hacer coincidir:

  SHA256("AARDVARK") = 5A9394..467731D0526A [X] SHA256("AARON") = C4DDDE..12E4CFE7B4FD [X] SHA256("ABACUS") = BEDDD8..1FE4DE25AAD7 [X] . . . 3400 omitido SHA256("BABBLE") = 70E837..CEAD4B1FA777 [X] SHA256("TEJÓN") = 946D0D..7B3073C1C094 [X] SHA256("GAITA") = 359DBE..BE193FCCB111 [X] . . . 3200 omitido SHA256("CABAL") = D78CF4..85BE02967565 [X] SHA256("CACHE") = C118F9..22F3269E7B32 [X] SHA256("CAGOULE") = 5EA530..5A26C5B56DCF [X] . . . 5400 omitido SHA256("DAB") = BBCC8E..E8B98CAB5128 [X] SHA256("narciso") = 75121D..D6401AB24A98 [X] SHA256("PELIGRO") = 0BD727..4C86037BB065 [X] . . . 3500 omitido SHA256("PATO") =  7FB376..DEAD4B3AF008 [¡ENCONTRADO!]

Y al incluir un salt por usuario, que no necesita ser secreto, simplemente único para cada usuario, se asegura de que incluso si dos usuarios eligen la misma contraseña, no terminarán con el mismo hash de contraseña.

Puedes ver el efecto de la salazón aquí, cuando mezclamos la palabra DUCK con tres prefijos diferentes:

  SHA256("RANDOM1-DUCK") = E355DB..349E669BB9A2 SHA256("RANDOM2-DUCK") = 13D538..FEA0DC6DBB5C <-- Cambiar solo un byte de entrada produce un hash muy diferente SHA256("ARXXQ3H-DUCK") = 52AD92. .544208A19449

Esto también significa que los atacantes no pueden crear una lista precalculada de hash probables, o crear una tabla de cálculos de hash parciales, conocida como mesa arcoiris, que puede acelerar la comprobación de hash. (Necesitarían una nueva lista hash, o un conjunto único de tablas de arcoíris, para cada sal posible).

En otras palabras, las contraseñas procesadas y saladas no se pueden descifrar de manera trivial para recuperar la entrada original, especialmente si la contraseña original era compleja y se eligió al azar.

Lo que Slack no dijo es si estirado la contraseña también se codifica, y si es así, cómo.

Estiramiento es un término de la jerga que significa repetir el proceso de hash de contraseñas una y otra vez, por ejemplo, 100,000 XNUMX veces, para extender el tiempo necesario para probar un montón de palabras del diccionario contra hashes de contraseñas conocidas.

Si tomara un segundo pasar 100,000 palabras de diccionario a través de un proceso simple de sal y hash, entonces los atacantes que saben el hash de su contraseña podrían probar 6 millones de palabras de diccionario diferentes y derivados cada minuto, o realizar más de mil millones de intentos cada tres horas. .

Por otro lado, si los cálculos de salt-and-hash se estiraran para tomar un segundo cada uno, entonces la demora adicional de un segundo cuando intentara iniciar sesión le causaría poca o ninguna molestia...

…pero reduciría a un atacante a solo 3600 intentos por hora, lo que hace que sea mucho menos probable que tenga suficiente tiempo para adivinar cualquier cosa que no sean las contraseñas más obvias.

Se conocen varios algoritmos salt-hash-and-stretch muy respetados, en particular PBKDF2, bcrypt, scrypt y Argon2, todo lo cual se puede ajustar para aumentar el tiempo necesario para intentar adivinar contraseñas individuales con el fin de reducir la viabilidad de los llamados ataques de diccionario y de fuerza bruta.

A Ataque de diccionario significa que solo está probando contraseñas probables, como cada palabra que pueda pensar de aardvark a zymurgy, y luego darse por vencido. A ataque de fuerza bruta significa probar todas las entradas posibles, incluso las extrañas e impronunciables, desde AAA..AAAA a ZZZ..ZZZZ (o de 0000..000000 a FFFF..FFFFFF si piensa en términos hexadecimales byte por byte).

¿Qué hacer?

Slack dice eso sobre 1 de cada 200 de sus usuarios (0.5%, presumiblemente basado en registros de cuántos enlaces de invitación compartidos se generaron en el período de peligro), y obligará a esos usuarios a restablecer sus contraseñas.

Algunos consejos adicionales:

• Si es un usuario de Slack, también puede restablecer su contraseña incluso si la empresa no le notificó que lo hiciera. Cuando una empresa admite que ha sido descuidada con su base de datos de contraseñas al filtrar hashes, también podría asumir que la suya se vio afectada, incluso si la empresa piensa que no. Tan pronto como cambia su contraseña, el hash anterior es inútil para los atacantes.
• Si no está utilizando un administrador de contraseñas, considere obtener uno. Un administrador de contraseñas ayuda a elegir contraseñas adecuadas, asegurando así que su contraseña termine muy, muy abajo en la lista de contraseñas que podrían ser descifradas en un incidente como este. Los atacantes normalmente no pueden realizar un verdadero ataque de fuerza bruta, porque hay demasiadas contraseñas posibles para probar. Por lo tanto, primero prueban las contraseñas más probables, como palabras o combinaciones obvias de palabras y números, y se vuelven más largas y complejas a medida que avanza el ataque. Un administrador de contraseñas puede recordar una contraseña aleatoria de 20 caracteres tan fácilmente como usted puede recordar el nombre de su gato.
• Activa 2FA si puedes. 2FA, o autenticación de dos factores, significa que no solo necesita su contraseña para iniciar sesión, sino también un código único que cambia cada vez. Estos códigos generalmente se envían a (o son generados por) su teléfono móvil y son válidos solo por unos minutos cada uno. Esto significa que incluso si los ciberdelincuentes descifran su contraseña, no es suficiente para que se apoderen de su cuenta.
• Elija un algoritmo salt-hash-and-stretch confiable cuando maneje las contraseñas usted mismo.. En el desafortunado caso de que su base de datos de contraseñas sea violada, podrá brindar a sus clientes detalles precisos del algoritmo y la configuración de seguridad que utilizó. Esto ayudará a los usuarios bien informados a juzgar por sí mismos qué tan probable es que sus hashes robados hayan sido descifrados en el tiempo disponible para los atacantes hasta el momento.

---