S3 Ep95: Rò rỉ Slack, sự tấn công dữ dội của Github và tiền điện tử hậu lượng tử [Âm thanh + Văn bản] Trí tuệ dữ liệu PlatoBlockchain. Tìm kiếm dọc. Ái.

S3 Ep95: Rò rỉ, tấn công dữ dội trên Github và tiền điện tử hậu lượng tử [Âm thanh + Văn bản]

Dấu thời gian: 11:2022 sáng ngày 10 tháng 34 năm XNUMX

by
Paul Ducklin

Nhấp và kéo vào các sóng âm thanh bên dưới để chuyển đến bất kỳ điểm nào. Bạn cũng có thể nghe trực tiếp trên Soundcloud.

Với Doug Aamoth và Paul Ducklin.

Nhạc giới thiệu và kết thúc bởi Edith Mudge.

Con mèo của Schroedinger phác thảo trong hình ảnh nổi bật qua Dhatfield Dưới CC BY-SA 3.0.

Bạn có thể lắng nghe chúng tôi trên Soundcloud, Podcast của Apple, Google Podcasts, Spotify, người may quần áo và bất cứ nơi nào tìm thấy podcast tốt. Hoặc chỉ cần thả URL của nguồn cấp dữ liệu RSS của chúng tôi vào podcatcher yêu thích của bạn.

ĐỌC BẢNG BIỂU

CHÓ.  Rò rỉ Slack, mã GitHub nghịch ngợm và mật mã hậu lượng tử.

Tất cả những điều đó và hơn thế nữa, trên podcast Naked Security.

[CHẾ ĐỘ ÂM NHẠC]

Chào mừng mọi người đến với podcast.

Tôi là Doug Aamoth.

Với tôi, như mọi khi, là Paul Ducklin.

Paul, hôm nay bạn thế nào?

VỊT.  Super-duper, như thường lệ, Doug!

CHÓ.  Tôi rất vui mừng khi đến với tuần này Lịch sử công nghệ phân đoạn, bởi vì…

… Bạn đã ở đó, anh bạn!

Tuần này, vào ngày 11 tháng XNUMX…

VỊT.  Ôi không!

Tôi nghĩ đồng xu vừa rơi…

CHÓ.  Tôi thậm chí không cần phải nói năm!

Ngày 11 tháng 2003 năm 2000 - thế giới chú ý đến sâu Blaster, ảnh hưởng đến hệ thống Windows XNUMX và Windows XP.

Blaster, còn được gọi là Lovesan và MsBlast, đã khai thác lỗi tràn bộ đệm và có lẽ được biết đến nhiều nhất với thông báo, “Billy Gates, tại sao bạn có thể biến điều này thành hiện thực? Hãy ngừng kiếm tiền và sửa chữa phần mềm của bạn ”.

Chuyện gì đã xảy ra vậy, Paul?

VỊT.  Chà, có lẽ đó là thời đại trước đây, chúng ta rất coi trọng vấn đề an ninh.

Và, may mắn thay, loại lỗi đó ngày nay sẽ khó khai thác hơn rất nhiều: đó là lỗi tràn bộ đệm dựa trên ngăn xếp.

Và nếu tôi nhớ không nhầm, các phiên bản máy chủ của Windows đã được xây dựng với cái gọi là bảo vệ ngăn xếp.

Nói cách khác, nếu bạn làm tràn ngăn xếp bên trong một hàm, thì trước khi hàm trả về và gây thiệt hại với ngăn xếp bị hỏng, nó sẽ phát hiện ra rằng điều gì đó tồi tệ đã xảy ra.

Vì vậy, nó phải tắt chương trình vi phạm, nhưng phần mềm độc hại không thể chạy.

Nhưng sự bảo vệ đó không có trong các phiên bản máy khách của Windows vào thời điểm đó.

Và như tôi nhớ, đó là một trong những phần mềm độc hại ban đầu phải đoán bạn có phiên bản hệ điều hành nào.

Bạn sinh năm 2000? Bạn có trên NT không? Bạn đang sử dụng XP?

Và nếu nó sai, thì một phần quan trọng của hệ thống sẽ gặp sự cố và bạn sẽ nhận được cảnh báo "Hệ thống của bạn sắp ngừng hoạt động".

CHÓ.  Ha, tôi nhớ những điều đó!

VỊT.  Vì vậy, có những thiệt hại tài sản thế chấp, đối với nhiều người, là dấu hiệu cho thấy bạn đang bị nhiễm trùng…

… Có thể là từ bên ngoài, chẳng hạn như nếu bạn chỉ là một người dùng gia đình và bạn không có bộ định tuyến hoặc tường lửa ở nhà.

Nhưng nếu bạn đang ở trong một công ty, cuộc tấn công rất có thể sẽ đến từ người khác bên trong công ty, làm phát tán các gói tin trên mạng của bạn.

Vì vậy, rất giống như cuộc tấn công CodeRed mà chúng tôi đã nói, vài năm trước đó, trong một podcast gần đây, chính quy mô, âm lượng và tốc độ tuyệt đối của thứ này mới là vấn đề.

CHÓ.  Được rồi, đó là khoảng 20 năm trước.

Và nếu chúng ta quay ngược đồng hồ về XNUMX năm trước, đó là khi Slack bắt đầu bị rò rỉ mật khẩu băm. [CON GÁI]

VỊT.  Vâng, Slack, công cụ cộng tác phổ biến…

… Nó có một tính năng mà bạn có thể gửi một liên kết mời đến những người khác tham gia vào không gian làm việc của bạn.

Và, bạn hãy tưởng tượng: bạn nhấp vào một nút có nội dung “Tạo liên kết” và nó sẽ tạo ra một số loại gói mạng có thể có một số JSON bên trong nó.

Nếu bạn đã từng có lời mời họp Zoom, bạn sẽ biết rằng nó có ngày và giờ, người đang mời bạn và URL bạn có thể sử dụng cho cuộc họp, mật mã và tất cả những điều đó thứ - nó có khá nhiều dữ liệu trong đó.

Thông thường, bạn không đào sâu vào dữ liệu thô để xem có gì trong đó - khách hàng chỉ nói, “Này, đây là một cuộc họp, đây là chi tiết. Bạn có muốn Chấp nhận / Có thể / Từ chối không? ”

Hóa ra là khi bạn làm điều này với Slack, như bạn nói, trong hơn năm năm, được đóng gói trong lời mời đó là dữ liệu không liên quan không hoàn toàn liên quan đến chính lời mời.

Vì vậy, không phải URL, không phải tên, không phải ngày, không phải giờ…

… Nhưng * băm mật khẩu của người dùng mời * [LAUGHTER]

CHÓ.  Ừmmmmm.

VỊT.  Em không đùa!

CHÓ.  Nghe có vẻ tệ…

VỊT.  Vâng, nó thực sự có, phải không?

Tin xấu là, làm thế quái nào mà nó lại vào được đó?

Và, một khi nó đã ở trong đó, làm thế quái nào mà nó lại trốn tránh thông báo trong năm năm và ba tháng?

Trên thực tế, nếu bạn truy cập bài viết về Bảo mật khỏa thân và xem URL đầy đủ của bài báo, bạn sẽ nhận thấy nó nói ở cuối, blahblahblah-for-three-months.

Bởi vì, khi tôi lần đầu tiên đọc báo cáo, tâm trí của tôi không muốn xem nó là năm 2017! [CON GÁI]

Đó là ngày 17 tháng 17 đến ngày 17 tháng XNUMX, và vì vậy có rất nhiều "XNUMX" trong đó.

Và tâm trí tôi trống rỗng năm 2017 là năm bắt đầu - tôi đã đọc nhầm thành “tháng 2022 đến tháng XNUMX * của năm nay *” [XNUMX].

Tôi nghĩ, "Chà, * ba tháng * và họ không nhận thấy."

Và sau đó nhận xét đầu tiên về bài báo là, “E hèm [COUGH]. Đó thực sự là ngày 17 tháng 2017 * XNUMX *. ”

Wow!

Nhưng ai đó đã phát hiện ra nó vào ngày 17 tháng 2022 [XNUMX], và Slack, nhờ tín dụng của họ, đã sửa nó ngay trong ngày.

Giống như, "Ôi trời ơi, chúng ta đang nghĩ gì vậy ?!"

Vì vậy, đó là một tin xấu.

Tin tốt là, ít nhất đó là mật khẩu * băm *.

Và chúng không chỉ được băm, chúng còn được * ướp muối *, đó là nơi bạn kết hợp dữ liệu ngẫu nhiên được chọn duy nhất cho mỗi người dùng với mật khẩu.

Ý tưởng về điều này là gấp đôi.

Một, nếu hai người chọn cùng một mật khẩu, họ sẽ không nhận được cùng một hàm băm, vì vậy bạn không thể đưa ra bất kỳ suy luận nào bằng cách xem qua cơ sở dữ liệu băm.

Và hai, bạn không thể tính toán trước một từ điển gồm các hàm băm đã biết cho các đầu vào đã biết, vì bạn phải tạo một từ điển riêng cho từng mật khẩu * cho từng muối *.

Vì vậy, không phải là một bài tập tầm thường để bẻ khóa mật khẩu đã băm.

Phải nói rằng, toàn bộ ý tưởng là chúng không được coi là một vấn đề của hồ sơ công khai.

Chúng được băm và ướp muối * trong trường hợp * chúng bị rò rỉ, không phải * để chúng có thể * rò rỉ.

Vì vậy, hãy đánh trứng vào mặt Slack!

Slack nói rằng khoảng một trong số 200 người dùng, tương đương 0.5%, bị ảnh hưởng.

Nhưng nếu bạn là người dùng Slack, tôi sẽ cho rằng nếu họ không nhận ra mình đã bị rò rỉ mật khẩu băm trong XNUMX năm, có lẽ họ cũng không liệt kê đầy đủ danh sách những người bị ảnh hưởng.

Vì vậy, hãy tiếp tục và thay đổi mật khẩu của bạn… bạn cũng có thể.

CHÓ.  OK, chúng tôi cũng nói: nếu bạn không sử dụng trình quản lý mật khẩu, hãy cân nhắc việc sử dụng một trình quản lý mật khẩu; và bật 2FA nếu bạn có thể.

VỊT.  Tôi nghĩ bạn thích điều đó, Doug.

CHÓ.  Em đồng ý!

Và sau đó, nếu bạn là Slack hoặc công ty thích nó, hãy chọn 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.

VỊT.  Vâng.

Điều quan trọng trong phản hồi của Slack, và điều mà tôi nghĩ là thiếu sót, là họ chỉ nói, "Đừng lo lắng, chúng tôi không chỉ băm mật khẩu mà chúng tôi còn muối chúng nữa."

Lời khuyên của tôi là nếu bạn bị bắt gặp vi phạm như thế này, thì bạn nên sẵn sàng khai báo thuật toán hoặc quy trình bạn đã sử dụng để ướp muối và băm, và lý tưởng nhất là cái được gọi là kéo dài, đó là nơi bạn không chỉ băm mật khẩu muối một lần, mà có thể bạn băm nó 100,000 lần để làm chậm bất kỳ loại từ điển hoặc cuộc tấn công vũ phu nào.

Và nếu bạn cho biết bạn đang sử dụng thuật toán nào và với những thông số nào .. ví dụ: PBKDF2, bcrypt, scrypt, Argon2 - đó là những thuật toán "muối-băm" mật khẩu nổi tiếng nhất hiện có.

Nếu bạn thực sự nói rõ bạn đang sử dụng thuật toán nào, thì: [A] bạn đang cởi mở hơn và [B] bạn đang cho các nạn nhân tiềm năng của vấn đề cơ hội tự đánh giá mức độ nguy hiểm của họ. .

Và sự cởi mở đó thực sự có thể giúp ích rất nhiều.

Slack đã không làm điều đó.

Họ chỉ nói, "Ồ, chúng đã được ướp muối và băm nhỏ."

Nhưng những gì chúng ta không biết là, họ đã cho vào hai byte muối và sau đó băm chúng một lần bằng SHA-1…

… Hay họ có thứ gì đó có khả năng chống nứt tốt hơn một chút?

CHÓ.  Bám sát vào chủ đề của những điều tồi tệ, chúng tôi nhận thấy một xu hướng đang phát triển trong đó mọi người đưa nội dung xấu vào GitHub, chỉ để xem điều gì sẽ xảy ra, có rủi ro…

… Chúng tôi có một câu chuyện khác trong số những câu chuyện đó.

VỊT.  Vâng, một người nào đó đã xuất hiện trên Twitter và nói, “Đừng lo lắng, không có hại gì cả. Nó chỉ dành cho nghiên cứu. Tôi sẽ viết một báo cáo, nổi bật từ Blue Alert. ”

Họ đã tạo ra hàng nghìn dự án GitHub không có thật, dựa trên việc sao chép mã hợp pháp hiện có, cố tình chèn một số lệnh phần mềm độc hại vào đó, chẳng hạn như "gọi điện về nhà để được hướng dẫn thêm" và "diễn giải phần thân của thư trả lời là mã cửa hậu để thực thi", và Sớm.

Vì vậy, những thứ thực sự có thể gây hại nếu bạn cài đặt một trong những gói này.

Đặt cho họ những cái tên hợp pháp…

… Mượn, rõ ràng, lịch sử cam kết của một dự án chính hãng để thứ trông hợp pháp hơn nhiều so với những gì bạn có thể mong đợi nếu nó chỉ hiển thị với, “Này, hãy tải xuống tệp này. Bạn biết bạn muốn! ”

Có thật không?! Nghiên cứu?? Chúng tôi đã không biết điều này rồi? !!?

Bây giờ, bạn có thể tranh luận, "Chà, Microsoft, công ty sở hữu GitHub, họ đang làm gì để mọi người tải lên loại nội dung này dễ dàng như vậy?"

Và có một số sự thật cho điều đó.

Có lẽ họ có thể làm tốt hơn việc ngăn chặn phần mềm độc hại ngay từ đầu.

Tuy nhiên, bạn sẽ nói: “Ồ, tất cả đều là lỗi của Microsoft”.

Theo quan điểm của tôi, còn tệ hơn khi nói, “Đúng, đây là nghiên cứu chân chính; điều này thực sự quan trọng; chúng tôi phải nhắc mọi người rằng điều này có thể xảy ra. "

Chà, [A] chúng tôi đã biết điều đó, cảm ơn bạn rất nhiều, vì rất nhiều người đã làm việc này trước đây; chúng tôi nhận được thông điệp to và rõ ràng.

Và [B] đây * không phải là * nghiên cứu.

Điều này cố tình lừa mọi người tải xuống mã cung cấp cho kẻ tấn công tiềm năng điều khiển từ xa, đổi lại khả năng viết báo cáo.

Đối với tôi, điều đó nghe giống như một “cái cớ to béo” hơn là một động lực chính đáng để nghiên cứu.

Và vì vậy khuyến nghị của tôi là, nếu bạn nghĩ đây * là * nghiên cứu, và nếu bạn quyết tâm làm điều gì đó như thế này một lần nữa, * đừng mong nhận được nhiều sự thông cảm * nếu bạn bị bắt.

CHÓ.  Được rồi - chúng tôi sẽ quay lại vấn đề này và người đọc nhận xét ở cuối chương trình, vì vậy hãy chú ý theo dõi.

Nhưng trước tiên, chúng ta hãy nói về đèn giao thôngvà họ phải làm gì với an ninh mạng.

VỊT.  Ahhh, vâng! [CƯỜI]

Chà, có một thứ gọi là TLP, Giao thức đèn giao thông.

Và TLP là cái mà bạn có thể gọi là “giao thức nghiên cứu an ninh mạng của con người” giúp bạn gắn nhãn các tài liệu mà bạn gửi cho người khác, để cung cấp cho họ gợi ý về những gì bạn hy vọng họ sẽ làm (và quan trọng hơn, bạn hy vọng họ sẽ làm gì * không *) làm với dữ liệu.

Đặc biệt, họ phải phân phối lại nó rộng rãi đến mức nào?

Đây có phải là điều quan trọng đến mức bạn có thể tuyên bố nó với thế giới?

Hay điều này tiềm ẩn nguy hiểm, hoặc nó có khả năng bao gồm một số nội dung mà chúng tôi chưa muốn công khai… vì vậy hãy giữ nó cho riêng mình?

Và nó bắt đầu với: TLP:RED, có nghĩa là, "Hãy giữ nó cho riêng mình"; TLP:AMBER, có nghĩa là “Bạn có thể lưu hành nó bên trong công ty của bạn hoặc cho những khách hàng của bạn mà bạn nghĩ rằng có thể cần biết điều này khẩn cấp”; TLP:GREEN, có nghĩa là, "OK, bạn có thể để điều này lan truyền rộng rãi trong cộng đồng an ninh mạng."

và TLP:WHITE, có nghĩa là, "Bạn có thể nói với bất kỳ ai."

Rất hữu ích, rất đơn giản: RED, AMBER, GREEN… một phép ẩn dụ hoạt động trên toàn cầu, mà không cần lo lắng về sự khác biệt giữa “bí mật” và “bí mật” và sự khác biệt giữa “bí mật” và “mật”, tất cả những thứ phức tạp đó cần rất nhiều luật xung quanh nó.

Chà, TLP vừa có một số sửa đổi.

Vì vậy, nếu bạn đang nghiên cứu về an ninh mạng, hãy đảm bảo rằng bạn biết về những điều đó.

TLP:WHITE đã được thay đổi thành những gì tôi coi là một thuật ngữ tốt hơn nhiều thực sự, bởi vì trắng có tất cả những dư âm văn hóa không cần thiết này mà chúng ta có thể làm mà không có trong kỷ nguyên hiện đại.

Vì vậy, TLP:WHITE vừa trở thành TLP:CLEAR, đối với tôi, đó là một từ tốt hơn nhiều bởi vì nó nói, "Bạn rõ ràng khi sử dụng dữ liệu này," và ý định đó được nêu ra, ahem, rất rõ ràng. (Xin lỗi, tôi không thể cưỡng lại cách chơi chữ.)

Và có một lớp bổ sung (vì vậy nó đã làm hỏng phép ẩn dụ một chút - bây giờ nó là đèn giao thông màu * năm * màu!).

Có một cấp độ đặc biệt được gọi là TLP:AMBER+STRICTvà điều đó có nghĩa là, "Bạn có thể chia sẻ điều này trong công ty của bạn."

Vì vậy, bạn có thể được mời tham dự một cuộc họp, có thể bạn làm việc cho một công ty an ninh mạng và khá rõ ràng rằng bạn sẽ cần phải thể hiện điều này với các lập trình viên, có thể với nhóm CNTT của bạn, có thể với những người đảm bảo chất lượng của bạn, vì vậy bạn có thể thực hiện nghiên cứu vấn đề hoặc đối phó với việc sửa chữa nó.

Nhưng TLP:AMBER+STRICT có nghĩa là mặc dù bạn có thể lưu hành nó trong tổ chức của mình, * vui lòng không nói với khách hàng của bạn hoặc khách hàng của bạn * hoặc thậm chí những người bên ngoài công ty rằng bạn có thể cần biết.

Giữ nó trong cộng đồng chặt chẽ hơn để bắt đầu.

TLP:AMBER, giống như trước đây, có nghĩa là, "Được, nếu bạn cảm thấy cần phải nói với khách hàng của mình, bạn có thể."

Và điều đó có thể quan trọng, bởi vì đôi khi bạn có thể muốn thông báo cho khách hàng của mình rằng “Này, chúng tôi sắp có bản sửa lỗi. Bạn sẽ cần thực hiện một số bước phòng ngừa trước khi có bản sửa lỗi. Nhưng bởi vì nó thuộc loại nhạy cảm, chúng tôi có thể yêu cầu bạn chưa nói cho cả thế giới biết được không? "

Đôi khi, việc nói cho thế giới biết quá sớm thực sự rơi vào tay những kẻ lừa đảo nhiều hơn là vào tay của những hậu vệ.

Vì vậy, nếu bạn là người phản hồi an ninh mạng, tôi khuyên bạn nên: https://www.first.org/tlp

CHÓ.  Và bạn có thể đọc thêm về điều đó trên trang web của chúng tôi, khỏa thân.sophos.com.

Và nếu bạn đang tìm kiếm một số cách đọc ánh sáng khác, hãy quên mật mã lượng tử ... chúng tôi đang chuyển sang mật mã hậu lượng tử, Phaolô!

VỊT.  Vâng, chúng tôi đã nói về điều này một vài lần trước đây trên podcast, phải không?

Ý tưởng về một máy tính lượng tử, giả sử là một máy tính đủ mạnh và đáng tin cậy có thể được xây dựng, là một số loại thuật toán nhất định có thể được tăng tốc theo trình độ kỹ thuật ngày nay, hoặc theo giai điệu của căn bậc hai… hoặc thậm chí tệ hơn, * logarit * của tỷ lệ của bài toán ngày hôm nay.

Nói cách khác, thay vì lấy 2256 cố gắng tìm một tệp với một hàm băm cụ thể, bạn có thể làm điều đó chỉ trong (“just”!) 2128 cố gắng, là căn bậc hai.

Rõ ràng là nhanh hơn rất nhiều.

Nhưng có cả một lớp vấn đề liên quan đến tích thừa của các số nguyên tố mà lý thuyết nói rằng có thể bị bẻ khóa theo * logarit * của thời gian mà chúng diễn ra ngày nay, nói một cách lỏng lẻo.

Vì vậy, thay vì lấy, hãy nói, 2128 số ngày để crack [FAR HƠN TUỔI HIỆN NAY CỦA VŨ TRỤ], có thể chỉ mất 128 ngày để crack.

Hoặc bạn có thể thay thế "ngày" bằng "phút", hoặc bất cứ điều gì.

Và thật không may, thuật toán thời gian logarit đó (được gọi là Thuật toán phân tích nhân tố lượng tử của Shor)… Về lý thuyết, có thể được áp dụng cho một số kỹ thuật mật mã ngày nay, đặc biệt là những kỹ thuật được sử dụng cho mật mã khóa công khai.

Và, trong trường hợp các thiết bị tính toán lượng tử này trở nên khả thi trong vài năm tới, có lẽ chúng ta nên bắt đầu chuẩn bị ngay từ bây giờ cho các thuật toán mã hóa không dễ bị tấn công bởi hai loại tấn công cụ thể này?

Đặc biệt là phương pháp logarit, bởi vì nó tăng tốc các cuộc tấn công tiềm ẩn đến mức các khóa mật mã mà chúng ta hiện đang nghĩ, “Chà, không ai có thể tìm ra điều đó”, có thể bị tiết lộ ở một số giai đoạn sau.

Dù sao, NIST, Viện Tiêu chuẩn và Công nghệ ở Hoa Kỳ, trong vài năm đã tiến hành một cuộc thi để thử và tiêu chuẩn hóa một số thuật toán công khai, chưa được cấp phép, được xem xét kỹ lưỡng sẽ có khả năng chống lại các máy tính lượng tử ma thuật này, nếu chúng xuất hiện.

Và gần đây, họ đã chọn bốn thuật toán mà họ đã chuẩn bị để chuẩn hóa ngay bây giờ.

Họ có những cái tên tuyệt vời, Doug, vì vậy tôi phải đọc chúng: CRYSTALS-KYBER, CRYSTALS-DILITHIUM, FALCONvà SPHINCS+. [CON GÁI]

Vì vậy, họ có những cái tên thú vị, nếu không có gì khác.

Nhưng đồng thời, NIST cũng nhận ra rằng “Chà, đó chỉ là bốn thuật toán. Những gì chúng tôi sẽ làm là chúng tôi sẽ chọn thêm bốn ứng cử viên phụ tiềm năng và chúng tôi sẽ xem liệu có ai trong số họ cũng nên vượt qua không. ”

Vì vậy, hiện có bốn thuật toán được tiêu chuẩn hóa và bốn thuật toán có thể được tiêu chuẩn hóa trong tương lai.

Hoặc có * đã có * bốn vào ngày 5 tháng 2022 năm XNUMX và một trong số đó là SIKE, viết tắt của đóng gói khóa isogeny siêu đẳng.

(Chúng tôi sẽ cần một số podcast để giải thích các đồng đẳng siêu thường, vì vậy chúng tôi sẽ không bận tâm. [LAUGHTER])

Nhưng, thật không may, cái này, được treo trong đó với một cơ hội chiến đấu được tiêu chuẩn hóa, có vẻ như nó đã bị hỏng không thể khắc phục được, mặc dù ít nhất năm năm đã được mở cửa cho sự giám sát của công chúng.

Vì vậy, may mắn thay, ngay trước khi nó được chuẩn hóa hoặc có thể được tiêu chuẩn hóa, hai nhà mật mã học người Bỉ đã tìm ra, “Bạn biết không? Chúng tôi nghĩ rằng chúng tôi đã có cách giải quyết vấn đề này bằng cách sử dụng các phép tính mất khoảng một giờ, trên một CPU trung bình khá, chỉ sử dụng một lõi. "

CHÓ.  Tôi đoán tốt hơn là nên tìm ra điều đó ngay bây giờ hơn là sau khi chuẩn hóa nó và đưa nó ra ngoài tự nhiên?

VỊT.  Thật!

Tôi đoán nếu đó là một trong những thuật toán đã được tiêu chuẩn hóa, họ sẽ phải hủy bỏ tiêu chuẩn và đưa ra một thuật toán mới?

Có vẻ kỳ lạ là điều này đã không được chú ý trong năm năm.

Nhưng tôi đoán đó là toàn bộ ý tưởng về sự giám sát của công chúng: bạn không bao giờ biết khi nào ai đó có thể chạm vào vết nứt cần thiết, hoặc cái nêm nhỏ mà họ có thể sử dụng để đột nhập và chứng minh rằng thuật toán không mạnh như người ta nghĩ ban đầu.

Một lời nhắc nhở tốt rằng nếu bạn * đã từng * nghĩ đến việc đan mật mã của riêng mình…

CHÓ.  [LAUGHS] Tôi chưa!

VỊT.  .. mặc dù chúng tôi đã nói với bạn trên podcast Naked Security N lần, "Đừng làm vậy!"

Đây phải là lời nhắc nhở cuối cùng rằng, ngay cả khi các chuyên gia thực sự đưa ra một thuật toán chịu sự giám sát của công chúng trong một cuộc cạnh tranh toàn cầu trong XNUMX năm, điều này vẫn không nhất thiết cung cấp đủ thời gian để phơi bày những sai sót trở nên khá tệ.

Vì vậy, nó chắc chắn không tốt cho điều này SIKE thuật toán.

Và ai biết được, có thể nó sẽ bị rút lại?

CHÓ.  Chúng tôi sẽ để mắt đến điều đó.

Và khi mặt trời dần lặn trong chương trình của chúng tôi trong tuần này, đã đến lúc nghe từ một trong những độc giả của chúng tôi về câu chuyện GitHub mà chúng tôi đã thảo luận trước đó.

cướp viết:

“Có một số phấn và pho mát trong các bình luận, và tôi ghét phải nói điều đó, nhưng tôi thực sự có thể thấy cả hai mặt của lập luận. Nó có nguy hiểm, rắc rối, lãng phí thời gian và tài nguyên không? Vâng, tất nhiên nó được. Nó có phải là những loại tội phạm có đầu óc sẽ làm? Vâng vâng nó là. Đó có phải là một lời nhắc nhở cho bất kỳ ai sử dụng GitHub, hoặc bất kỳ hệ thống lưu trữ mã nào khác về vấn đề đó, rằng việc di chuyển trên Internet một cách an toàn đòi hỏi mức độ hoài nghi và hoang tưởng lành mạnh không? Đúng. Với tư cách là một sysadmin, một phần trong tôi muốn hoan nghênh mức độ rủi ro trong tầm tay. Với tư cách là một sysadmin cho một loạt các nhà phát triển, tôi bây giờ cần đảm bảo rằng mọi người gần đây đã tìm kiếm mọi thứ để tìm các mục nhập có vấn đề. "

VỊT.  Vâng, cảm ơn bạn, RobB, vì nhận xét đó, vì tôi nghĩ điều quan trọng là phải nhìn thấy cả hai mặt của lập luận.

Có những người bình luận chỉ nói, "Vấn đề là cái quái gì với cái này? Điều đó thật tuyệt!"

Một người nói, “Không, thực ra, thử nghiệm bút này rất hay và hữu ích. Hãy vui mừng vì những thứ này đang được phơi bày ngay bây giờ thay vì nuôi cái đầu xấu xí của chúng khỏi một kẻ tấn công thực sự. "

Và phản ứng của tôi cho điều đó là, "Chà, đây * là * một cuộc tấn công, thực sự."

Chỉ là bây giờ ai đó đã bước ra sau đó, nói “Ồ, không, không. Không có hại gì được thực hiện! Thành thật mà nói, tôi không hề hư. "

Tôi không nghĩ rằng bạn có nghĩa vụ phải mua cái cớ đó!

Nhưng dù sao, đây không phải là thử nghiệm thâm nhập.

Câu trả lời của tôi là nói, rất đơn giản: “Người kiểm tra thâm nhập có trách nhiệm chỉ hành động [A] sau khi nhận được sự cho phép rõ ràng và [B] trong giới hạn hành vi đã được thỏa thuận rõ ràng trước.”

Bạn không chỉ tạo ra các quy tắc của riêng mình, và chúng tôi đã thảo luận về điều này trước đây.

Vì vậy, như một người bình luận khác đã nói, đó là, theo tôi, nhận xét yêu thích của tôi… Ngoại ô cho biết, “Tôi nghĩ ai đó nên đi bộ từ nhà này sang nhà khác và đập vỡ cửa sổ để cho thấy khóa cửa thực sự không hiệu quả như thế nào. Điều này đã quá hạn. Ai đó nhảy vào cái này, làm ơn. ”

Và sau đó, đề phòng bạn không nhận ra đó là sự châm biếm, các bạn, anh ấy nói, "Không phải!"

VỊT.  Tôi hiểu rằng đó là một lời nhắc nhở tốt và tôi có ý kiến ​​rằng nếu bạn là người dùng GitHub, cả với tư cách là nhà sản xuất và người tiêu dùng, thì có những điều bạn có thể làm.

Chúng tôi liệt kê chúng trong các bình luận và trong bài báo.

Ví dụ: đặt chữ ký điện tử vào tất cả các cam kết của bạn để rõ ràng rằng những thay đổi đến từ bạn và có một số loại truy xuất nguồn gốc.

Và đừng chỉ sử dụng những thứ một cách mù quáng bởi vì bạn đã thực hiện một cuộc tìm kiếm và nó “có vẻ như” đó có thể là dự án phù hợp.

Vâng, tất cả chúng ta đều có thể học hỏi từ điều này, nhưng điều này thực sự được coi là dạy chúng ta, hay đó chỉ là điều chúng ta nên học?

Tôi nghĩ đây là * không * dạy.

Nó chỉ * không đạt tiêu chuẩn đủ cao * để được coi là nghiên cứu.

CHÓ.  Cuộc thảo luận tuyệt vời xung quanh bài viết này, và cảm ơn vì đã gửi điều đó, Rob.

Nếu bạn có một câu chuyện, nhận xét hoặc câu hỏi thú vị mà bạn muốn gửi, chúng tôi rất muốn đọc nó trên podcast.

Bạn có thể gửi email tips@sophos.com; bạn có thể bình luận về bất kỳ bài báo nào của chúng tôi; hoặc bạn có thể đánh chúng tôi trên mạng xã hội: @NakedSecurity.

Đó là chương trình của chúng tôi cho ngày hôm nay - cảm ơn rất nhiều vì đã lắng nghe.

Đối với Paul Ducklin, tôi là Doug Aamoth sẽ nhắc bạn, cho đến lần sau, hãy…

CẢ HAI.  Giữ an toàn!

[CHẾ ĐỘ ÂM NHẠC]

Dấu thời gian:

Thêm từ An ninh trần trụi