Slack thừa nhận đã làm rò rỉ mật khẩu băm trong ba tháng

Công cụ cộng tác phổ biến Slack (đừng nhầm với biệt danh của bản phân phối Linux chạy lâu nhất thế giới, Slackware) vừa sở hữu SNAFU an ninh mạng.

Theo một bản tin có tựa đề Thông báo về việc đặt lại mật khẩu Slack, công ty thừa nhận rằng họ đã vô tình chia sẻ quá nhiều dữ liệu cá nhân “Khi người dùng tạo hoặc thu hồi liên kết lời mời được chia sẻ cho không gian làm việc của họ.”

Từ năm 2022-04-17 đến 2022-07-17 (chúng tôi cho rằng cả hai ngày đều được bao gồm), Slack nói rằng dữ liệu được gửi đến người nhận của những lời mời như vậy bao gồm…

… Đợi nó…

…các mật khẩu băm của người gửi.

Có chuyện gì?

Cố vấn bảo mật của Slack không giải thích rõ ràng về vi phạm mà chỉ nói rằng “[T] mật khẩu băm của anh ấy không hiển thị với bất kỳ khách hàng Slack nào; việc phát hiện ra nó yêu cầu chủ động theo dõi lưu lượng mạng được mã hóa đến từ các máy chủ của Slack. ”

Chúng tôi đoán rằng điều này được dịch như sau:

“Hầu hết người nhận sẽ không nhận thấy rằng dữ liệu họ nhận được bao gồm bất kỳ thông tin mật khẩu đã băm nào, bởi vì thông tin đó, mặc dù được bao gồm trong các gói mạng được gửi, không bao giờ được cố tình hiển thị cho họ. Và bởi vì dữ liệu được gửi qua kết nối TLS, những kẻ nghe trộm sẽ không thể phát hiện ra nó trong suốt quá trình, bởi vì nó sẽ không được giải mã cho đến khi nó đến đầu kia của kết nối. "

Đó là tin tốt.

Nhưng các gói mạng thường bao gồm dữ liệu mà người nhận thường không bao giờ sử dụng hoặc nhìn thấy.

Tiêu đề HTTP là một ví dụ điển hình về điều này, vì chúng được coi là hướng dẫn cho trình duyệt của bạn, không phải dữ liệu để hiển thị trong trang web bạn đang xem.

Và dữ liệu không liên quan hoặc vô hình đối với người dùng thường kết thúc trong nhật ký, đặc biệt là trong nhật ký tường lửa, nơi nó có thể được lưu giữ vô thời hạn.

Đó là tin xấu.

Muối, băm và kéo dài…

Theo Slack, dữ liệu bị rò rỉ không chỉ đơn thuần là băm, Nhưng ướp muối quá, nghĩa là mật khẩu của mỗi người dùng lần đầu tiên được trộn cùng với dữ liệu ngẫu nhiên duy nhất cho người dùng đó trước khi hàm băm được áp dụng.

Hàm băm về cơ bản là các hàm toán học "không thể đảo ngược", dễ dàng tính toán theo một hướng, nhưng không theo hướng khác.

Ví dụ, thật dễ dàng để tính toán rằng:

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

Nhưng cách duy nhất để làm việc "ngược" từ 7FB376..DEAD4B3AF008 đến DUCK là để làm việc chuyển tiếp từ mọi từ có thể có trong từ điển và xem liệu có từ nào trong số đó xuất hiện với giá trị mà bạn đang cố gắng đối sánh hay không:

  SHA256 ("AARDVARK") = 5A9394..467731D0526A [X] SHA256 ("AARON") = C4DDDE..12E4CFE7B4FD [X] SHA256 ("ABACUS") = BEDDD8..1FE4DE25AAD7 [X]. . . 3400 đã bỏ qua SHA256 ("BABBLE") = 70E837..CEAD4B1FA777 [X] SHA256 ("BADGER") = 946D0D..7B3073C1C094 [X] SHA256 ("BAGPIPE") = 359DBE..BE193FCCB111 [X]. . . 3200 đã bỏ qua SHA256 ("CABAL") = D78CF4..85BE02967565 [X] SHA256 ("CACHE") = C118F9..22F3269E7B32 [X] SHA256 ("CAGOULE") = 5EA530..5A26C5B56DCF [X]. . . 5400 đã bỏ qua SHA256 ("DAB") = BBCC8E..E8B98CAB5128 [X] SHA256 ("DAFFODIL") = 75121D..D6401AB24A98 [X] SHA256 ("DANGER") = 0BD727..4C86037BB065 [X]. . . 3500 SHA256 bị bỏ qua ("DUCK") =  7FB376..DEAD4B3AF008 [TÌM HIỂU!]

Và bằng cách bao gồm một muối cho mỗi người dùng, không cần phải bí mật, chỉ đơn thuần là duy nhất cho mỗi người dùng, bạn đảm bảo rằng ngay cả khi hai người dùng chọn cùng một mật khẩu, họ sẽ không có cùng một hàm băm mật khẩu.

Bạn có thể thấy tác dụng của việc ướp muối tại đây, khi chúng ta băm từ DUCK với ba tiền tố khác nhau:

  SHA256 ("RANDOM1-DUCK") = E355DB..349E669BB9A2 SHA256 ("RANDOM2-DUCK") = 13D538..FEA0DC6DBB5C <- Chỉ thay đổi một byte đầu vào sẽ tạo ra một hàm băm rất khác SHA256 ("ARXXQ3H-DUCK") = 52. .92A544208

Điều này cũng có nghĩa là những kẻ tấn công không thể tạo danh sách được tính toán trước của các hàm băm có khả năng xảy ra hoặc tạo một bảng tính toán băm một phần, được gọi là bàn cầu vồng, điều đó có thể đẩy nhanh quá trình kiểm tra hàm băm. (Họ cần một danh sách băm hoàn toàn mới hoặc một bộ bảng cầu vồng độc đáo, cho mọi loại muối có thể.)

Nói cách khác, mật khẩu băm và muối không thể bị bẻ khóa để khôi phục dữ liệu đầu vào ban đầu, đặc biệt nếu mật khẩu ban đầu phức tạp và được chọn ngẫu nhiên.

Điều mà Slack không nói là liệu họ có kéo dài mật khẩu cũng băm, và nếu có thì làm như thế nào.

Trải dài là một thuật ngữ có nghĩa là lặp đi lặp lại quá trình băm mật khẩu, ví dụ: 100,000 lần, để kéo dài thời gian cần thiết để thử một loạt các từ trong từ điển so với các phép băm mật khẩu đã biết.

Nếu chỉ mất một giây để đặt 100,000 từ trong từ điển thông qua một quy trình muối và băm đơn giản, thì những kẻ tấn công biết hàm băm mật khẩu của bạn có thể thử 6 triệu từ điển và từ ngữ khác nhau mỗi phút hoặc mất hơn một tỷ lần đoán cứ sau ba giờ .

Mặt khác, nếu các phép tính muối và băm được kéo dài để mất một giây mỗi lần, thì độ trễ thêm một giây khi bạn cố gắng đăng nhập sẽ gây ra ít hoặc không gây khó chịu cho bạn…

… Nhưng sẽ giảm kẻ tấn công xuống chỉ còn 3600 lần thử một giờ, khiến khả năng họ có đủ thời gian để đoán bất cứ thứ gì trừ những mật khẩu rõ ràng nhất sẽ ít hơn nhiều.

Một số thuật toán muối băm và kéo giãn được đánh giá cao đã được biết đến, đáng chú ý là PBKDF2, bcrypt, scrypt và Argon2, tất cả đều có thể được điều chỉnh để tăng thời gian cần thiết để thử các lần đoán mật khẩu riêng lẻ để giảm khả năng tồn tại của cái gọi là từ điển và các cuộc tấn công vũ phu.

A tấn công từ điển có nghĩa là bạn chỉ đang thử các mật khẩu có khả năng xảy ra, chẳng hạn như mọi từ bạn có thể nghĩ ra aardvark đến zymurgy, và sau đó từ bỏ. Một cuộc tấn công vũ phu có nghĩa là thử mọi đầu vào có thể, ngay cả những đầu vào kỳ lạ và không thể phát âm, từ AAA..AAAA đến ZZZ..ZZZZ (hoặc từ 0000..000000 đến FFFF..FFFFFF nếu bạn nghĩ theo thuật ngữ byte-by-byte thập lục phân).

Phải làm gì?

Slack nói rằng về 1 trong 200 người dùng của nó (0.5%, có lẽ dựa trên hồ sơ về số lượng liên kết lời mời được chia sẻ đã được tạo trong thời kỳ nguy hiểm) và nó sẽ buộc những người dùng đó phải đặt lại mật khẩu của họ.

Một số lời khuyên thêm:

• Nếu bạn là người dùng Slack, bạn cũng có thể đặt lại mật khẩu của mình ngay cả khi bạn không được công ty thông báo để làm như vậy. Khi một công ty thừa nhận rằng họ đã bất cẩn với cơ sở dữ liệu mật khẩu của mình bằng cách làm rò rỉ hàm băm, bạn cũng có thể cho rằng cơ sở dữ liệu của mình bị ảnh hưởng, ngay cả khi công ty cho rằng không phải vậy. Ngay sau khi bạn thay đổi mật khẩu của mình, bạn sẽ khiến hàm băm cũ trở nên vô dụng đối với những kẻ tấn công.
• Nếu bạn không sử dụng trình quản lý mật khẩu, hãy cân nhắc sử dụng một trình quản lý mật khẩu. Trình quản lý mật khẩu giúp chọn mật khẩu thích hợp, do đó đảm bảo rằng mật khẩu của bạn kết thúc rất, rất xa trong danh sách các mật khẩu có thể bị bẻ khóa trong một sự cố như thế này. Những kẻ tấn công thường không thể thực hiện một cuộc tấn công vũ phu thực sự, bởi vì có quá nhiều mật khẩu có thể để thử. Vì vậy, chúng thử các mật khẩu có khả năng xảy ra nhất trước, chẳng hạn như các từ hoặc các tổ hợp từ và số rõ ràng, ngày càng dài hơn và phức tạp hơn khi cuộc tấn công tiến hành. Trình quản lý mật khẩu có thể nhớ một mật khẩu ngẫu nhiên, gồm 20 ký tự dễ dàng như bạn có thể nhớ tên con mèo của mình.
• Bật 2FA nếu bạn có thể. 2FA, hoặc xác thực hai yếu tố, có nghĩa là bạn không chỉ cần mật khẩu để đăng nhập mà còn phải có mã dùng một lần, thay đổi liên tục. Những mã này thường được gửi đến (hoặc được tạo bởi) điện thoại di động của bạn và chỉ có hiệu lực trong vài phút mỗi mã. Điều này có nghĩa là ngay cả khi cybercrook có bẻ khóa mật khẩu của bạn, nó không đủ để chúng chiếm đoạt tài khoản của bạn.
• Chọn một thuật toán muối băm và kéo dài có uy tín khi tự xử lý mật khẩu.. Trong trường hợp không may cơ sở dữ liệu mật khẩu của bạn bị vi phạm, bạn sẽ có thể cung cấp cho khách hàng chi tiết chính xác về thuật toán và cài đặt bảo mật mà bạn đã sử dụng. Điều này sẽ giúp những người dùng hiểu biết có thể tự đánh giá khả năng các mã băm bị đánh cắp của họ có thể đã bị bẻ khóa trong thời gian có sẵn cho những kẻ tấn công cho đến nay hay không.

---