VI PHẠM, BẢN VÁ, RÒ RỈ VÀ CHỈNH SỬA
Tập mới nhất – nghe ngay bây giờ.
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.
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Ó. Vi phạm, vi phạm, bản vá và typios.
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; anh ấy là Daul Pucklin…
…Tôi xin lỗi, Paul!
VỊT. Tôi nghĩ tôi đã giải quyết xong, Doug.
“Typios” là một lỗi đánh máy âm thanh.
CHÓ. Chính xác!
VỊT. Vâng… làm tốt lắm, người đàn ông đó!
CHÓ. Vì vậy, lỗi chính tả có liên quan gì đến an ninh mạng?
Chúng ta sẽ đi sâu vào vấn đề đó…
Nhưng trước tiên – chúng tôi muốn bắt đầu với Tuần này trong Lịch sử Công nghệ phân khúc.
Tuần này, ngày 23 tháng 1996 năm 1.0, phiên bản XNUMX của Bộ công cụ phát triển Java cho biết, “Hello, world."
Câu thần chú của nó, “Viết một lần, chạy mọi nơi”, và việc phát hành nó ngay khi mức độ phổ biến của web đang thực sự đạt đến một cơn sốt, đã khiến nó trở thành một nền tảng tuyệt vời cho các ứng dụng dựa trên web.
Chuyển nhanh đến ngày hôm nay và chúng ta đang ở phiên bản 19, Paul.
VỊT. Chúng tôi là!
Java hả?
Hoặc "Sồi".
Tôi tin rằng đó là tên ban đầu của nó, bởi vì người đã phát minh ra ngôn ngữ này có một cây sồi mọc bên ngoài văn phòng của ông ta.
Chúng ta hãy nhân cơ hội này, Doug, để làm sáng tỏ, một lần và mãi mãi, nhầm lẫn mà nhiều người có giữa Java và JavaScript.
CHÓ. Ố ồ ồ…
VỊT. Nhiều người cho rằng họ có quan hệ họ hàng với nhau.
Họ không liên quan, Doug.
Chúng *hoàn toàn giống nhau* – một cái chỉ là dạng rút gọn… KHÔNG, TÔI HOÀN TOÀN ĐANG ĐÁNH BẠI BẠN!
CHÓ. Tôi giống như, "Chuyện này sẽ đi đến đâu vậy?" [CƯỜI]
VỊT. Về cơ bản, JavaScript có cái tên đó vì từ Java rất hay…
…và các lập trình viên chạy bằng cà phê, cho dù họ đang lập trình bằng Java hay JavaScript.
CHÓ. Được rồi, rất tốt.
Cảm ơn bạn đã giải thích rõ ràng.
Và về vấn đề giải quyết mọi thứ, GoTo, công ty đứng sau các sản phẩm như GoToMyPC, GoToWebinar, LogMeIn và (ho, ho) những sản phẩm khác Điều đó nói họ đã “phát hiện hoạt động bất thường trong môi trường phát triển của chúng tôi và dịch vụ lưu trữ đám mây của bên thứ ba”.
Paul, chúng ta biết gì?
GoTo thừa nhận: Bản sao lưu đám mây của khách hàng bị đánh cắp cùng với khóa giải mã
VỊT. Đó là vào ngày cuối cùng của tháng 2022 năm XNUMX.
Và (ho, khụ) mà bạn đã đề cập trước đó, tất nhiên, là chi nhánh/công ty con của GoTo hoặc công ty là một phần của nhóm của họ, LastPass.
Tất nhiên, câu chuyện lớn trong dịp Giáng sinh là Vi phạm của LastPass.
Bây giờ, vi phạm này dường như là một vi phạm khác, với những gì Goto đã đưa ra và nói bây giờ.
Họ thừa nhận rằng dịch vụ đám mây cuối cùng đã bị vi phạm chính là dịch vụ được chia sẻ với LastPass.
Nhưng những thứ đã bị vi phạm, ít nhất là từ cách họ viết nó, nghe có vẻ đã bị vi phạm theo cách khác.
Và phải đến tuần này – gần hai tháng sau – GoTo mới quay lại đánh giá về những gì họ tìm thấy.
Và tin không tốt chút nào, Doug.
Bởi vì có rất nhiều sản phẩm… Tôi sẽ đọc to chúng: Central, Pro, join.me, Hamachi và RemotelyAnywhere.
Đối với tất cả các sản phẩm đó, các bản sao lưu được mã hóa của nội dung khách hàng, bao gồm cả dữ liệu tài khoản, đã bị đánh cắp.
Và thật không may, khóa giải mã của ít nhất một số bản sao lưu đó đã bị đánh cắp cùng với chúng.
Vì vậy, điều đó có nghĩa là về cơ bản chúng *không* được mã hóa khi chúng nằm trong tay kẻ gian.
Và có hai sản phẩm khác là Rescue và GoToMyPC, trong đó cái gọi là “cài đặt MFA” đã bị đánh cắp, nhưng thậm chí không được mã hóa.
Vì vậy, trong cả hai trường hợp, rõ ràng chúng ta đều có: thiếu mật khẩu băm và muối và chúng ta có “cài đặt MFA (xác thực đa yếu tố)” bí ẩn này.
Cho rằng đây có vẻ là dữ liệu liên quan đến tài khoản, không rõ “cài đặt MFA” đó là gì và thật đáng tiếc là GoTo đã không rõ ràng hơn một chút.
Và câu hỏi hóc búa của tôi là…
..các cài đặt đó có bao gồm những thứ như số điện thoại mà mã SMS 2FA có thể được gửi tới không?
Hạt giống khởi đầu cho mã 2FA dựa trên ứng dụng?
Và/hoặc những mã dự phòng mà nhiều dịch vụ cho phép bạn tạo một vài trong số đó, đề phòng trường hợp bạn bị mất điện thoại hoặc SIM bị tráo đổi?
Người trao đổi SIM bị tống vào tù vì ăn cắp tiền điện tử 2FA hơn 20 triệu đô la
CHÓ. Ồ, vâng - điểm tốt!
VỊT. Hoặc chương trình xác thực của bạn bị lỗi.
CHÓ. Vâng.
VỊT. Vì vậy, nếu họ là bất kỳ ai trong số đó, thì đó có thể là rắc rối lớn.
Hãy hy vọng đó không phải là “cài đặt MFA”…
…nhưng việc bỏ sót các chi tiết ở đó có nghĩa là có thể đáng để giả định rằng chúng đã hoặc có thể đã nằm trong số dữ liệu bị đánh cắp.
CHÓ. Và, nói về những thiếu sót có thể xảy ra, chúng tôi có điều kiện cần, “Mật khẩu của bạn đã bị rò rỉ. Nhưng đừng lo, chúng đã được ướp muối và băm nhỏ rồi.”
Nhưng không phải tất cả ướp muối và băm và kéo dài là như nhau, phải không?
Bảo mật nghiêm túc: Cách lưu trữ mật khẩu của người dùng của bạn một cách an toàn
VỊT. Chà, họ đã không đề cập đến phần kéo dài!
Đó là nơi bạn không chỉ băm mật khẩu một lần.
Bạn băm nó, tôi không biết… 100,100 lần, hay 5000 lần, hay 50 lần, hay một triệu lần, chỉ để làm cho kẻ lừa đảo khó khăn hơn một chút.
Và như bạn nói… vâng., không phải tất cả quá trình muối và băm đều được thực hiện như nhau.
Tôi nghĩ rằng bạn đã nói khá gần đây trên podcast về một vi phạm trong đó có một số mật khẩu muối và băm bị đánh cắp, và hóa ra, tôi nghĩ, muối đó là một mã gồm hai chữ số, “00” đến “99”!
Vì vậy, 100 bảng cầu vồng khác nhau là tất cả những gì bạn cần…
…một yêu cầu lớn, nhưng nó có thể làm được.
Và nơi băm là *một vòng* MD5, bạn có thể thực hiện với hàng tỷ lần băm mỗi giây, ngay cả trên thiết bị khiêm tốn.
Vì vậy, bên cạnh đó, nếu bạn không may bị vi phạm loại này, khiến bạn mất mật khẩu băm của khách hàng, tôi khuyên bạn nên cố gắng xác định rõ ràng về thuật toán và thông số cài đặt của mình. đang sử dụng.
Bởi vì nó mang lại một chút thoải mái cho người dùng của bạn về việc kẻ gian có thể mất bao lâu để thực hiện việc bẻ khóa và do đó, bạn cần phải điên cuồng thay đổi tất cả mật khẩu của mình như thế nào!
CHÓ. Ổn thỏa.
Tất nhiên, chúng tôi có một số lời khuyên, bắt đầu bằng: Thay đổi tất cả mật khẩu liên quan đến các dịch vụ mà chúng ta đã nói trước đó.
VỊT. Vâng, đó là điều mà bạn nên làm.
Đó là những gì chúng tôi thường khuyến nghị khi mật khẩu băm bị đánh cắp, ngay cả khi chúng được băm siêu mạnh.
CHÓ. OK.
Và chúng tôi đã có: Đặt lại mọi chuỗi mã 2FA dựa trên ứng dụng mà bạn đang sử dụng trên tài khoản của mình.
VỊT. Vâng, tôi nghĩ bạn cũng có thể làm điều đó.
CHÓ. OK.
Và chúng tôi đã có: Tái tạo mã dự phòng mới.
VỊT. Khi bạn làm điều đó với hầu hết các dịch vụ, nếu mã dự phòng là một tính năng, thì những mã cũ sẽ tự động bị loại bỏ và những mã mới sẽ thay thế chúng hoàn toàn.
CHÓ. Và cuối cùng, nhưng chắc chắn không kém: Cân nhắc chuyển sang mã 2FA dựa trên ứng dụng nếu có thể.
VỊT. Mã SMS có lợi thế là không có bí mật chung; không có hạt giống.
Đó chỉ là một số thực sự ngẫu nhiên mà đầu bên kia tạo ra mỗi lần.
Đó là điều tốt về nội dung dựa trên SMS.
Như chúng tôi đã nói, điều tồi tệ là hoán đổi SIM.
Và nếu bạn cần thay đổi trình tự mã dựa trên ứng dụng hoặc vị trí mã SMS của bạn…
…việc bắt đầu một chuỗi ứng dụng 2FA mới dễ dàng hơn nhiều so với việc thay đổi số điện thoại di động của bạn! [CƯỜI]
CHÓ. OK.
Và, như tôi đã nói nhiều lần (tôi có thể xăm cái này lên ngực ở đâu đó), chúng tôi sẽ để mắt đến điều này.
Tuy nhiên, hiện tại, chúng tôi có một API T-Mobile bị rò rỉ chịu trách nhiệm về hành vi trộm cắp…
(Để tôi kiểm tra các ghi chú của mình ở đây: [LOUD BELLLOW OFF-MIC] BA MƯƠI BẢY TRIỆU!?!?!?!)
...37 triệu hồ sơ khách hàng:
T-Mobile thừa nhận 37,000,000 hồ sơ khách hàng bị “kẻ xấu” đánh cắp
VỊT. Vâng.
Đó là một chút khó chịu, phải không? [CƯỜI]
Bởi vì 37 triệu là một con số cực kỳ lớn… và trớ trêu thay, lại đến sau năm 2022, năm mà T-Mobile thanh toán $ 500 triệu để giải quyết các vấn đề liên quan đến vi phạm dữ liệu mà T-Mobile đã gặp phải vào năm 2021.
Bây giờ, tin tốt, nếu bạn có thể gọi như vậy, là: lần trước, dữ liệu bị xâm phạm bao gồm những thứ như Số An sinh Xã hội [SSN] và chi tiết giấy phép lái xe.
Vì vậy, đó thực sự là những gì bạn có thể gọi là công cụ đánh cắp danh tính “cao cấp”.
Lần này, vi phạm là lớn, nhưng tôi hiểu rằng đó là chi tiết liên lạc điện tử cơ bản, bao gồm số điện thoại của bạn, cùng với ngày sinh.
Điều đó giúp ích cho kẻ gian trong việc đánh cắp danh tính, nhưng không xa bằng thứ gì đó như SSN hoặc ảnh quét giấy phép lái xe của bạn.
CHÓ. Được rồi, chúng tôi có một số mẹo nếu bạn bị ảnh hưởng bởi vấn đề này, bắt đầu bằng: Đừng nhấp vào các liên kết “hữu ích” trong email hoặc các tin nhắn khác.
Tôi phải giả định rằng rất nhiều thư rác và email lừa đảo sẽ được tạo ra từ sự cố này.
VỊT. Nếu bạn tránh các liên kết, như chúng tôi luôn nói, và bạn tự tìm đường đến đó, thì dù đó có phải là một email hợp pháp hay không, với một liên kết chính hãng hay một liên kết không có thật…
…nếu bạn không nhấp vào các liên kết tốt, thì bạn cũng sẽ không nhấp vào các liên kết xấu!
CHÓ. Và điều đó phù hợp với mẹo thứ hai của chúng tôi: Hãy suy nghĩ trước khi bạn nhấp vào.
Và sau đó, tất nhiên, mẹo cuối cùng của chúng tôi: Báo cáo những email đáng ngờ đó cho nhóm CNTT làm việc của bạn.
VỊT. Khi kẻ gian bắt đầu tấn công lừa đảo, kẻ gian thường không gửi nó cho một người trong công ty.
Vì vậy, nếu người đầu tiên nhìn thấy hành vi lừa đảo trong công ty của bạn tình cờ đưa ra cảnh báo, thì ít nhất bạn cũng có cơ hội cảnh báo cho 49 người khác!
CHÓ. Xuất sắc.
Chà, đối với bạn, những người dùng iOS 12 ngoài kia… nếu bạn cảm thấy bị bỏ rơi khỏi tất cả các bản vá zero-day gần đây, hãy chúng tôi có một câu chuyện cho bạn ngày hôm nay!
Các bản vá lỗi của Apple đã hết - iPhone cũ cuối cùng cũng nhận được bản sửa lỗi zero-day cũ!
VỊT. Chúng ta có, Doug!
Tôi khá vui vì mọi người đều biết tôi yêu thích chiếc điện thoại iOS 12 cũ của mình.
Chúng tôi đã trải qua một số khoảng thời gian tuyệt vời, và trên một số chuyến đi xe đạp dài và siêu thú vị cùng nhau cho đến khi… [CƯỜI]
…sự cố định mệnh khiến tôi bị thương đủ nặng để hồi phục, và chiếc điện thoại bị thương nặng đến mức bạn gần như không thể nhìn xuyên qua các vết nứt trên màn hình nữa, nhưng nó vẫn hoạt động!
Tôi thích nó khi nó được cập nhật!
CHÓ. Tôi nghĩ rằng đây là khi tôi học từ trang.
VỊT. [TẠM DỪNG] Cái gì?!
Đó là không phải là một từ đối với bạn?
CHÓ. Không!
VỊT. Tôi nghĩ nó xuất phát từ Lực lượng Không quân Hoàng gia trong Chiến tranh thế giới thứ hai… đó là, “chuẩn bị máy bay”.
Vì vậy, có một kêu vang, và sau đó, trên một ding, đến một trang, mặc dù cả hai đều có âm thanh giống nhau.
CHÓ. OK, hiểu rồi.
VỊT. Bất ngờ, bất ngờ – sau một thời gian dài không có bản cập nhật iOS 12, chiếc điện thoại sắp ra mắt đã nhận được bản cập nhật…
…đối với một lỗi zero-day, một lỗi bí ẩn đã được sửa cách đây một thời gian chỉ trong iOS 16… [WHISPER] rất bí mật của Apple, nếu bạn còn nhớ điều đó.
CHÓ. Ồ, tôi nhớ ra rồi!
Apple tung ra bản cập nhật bảo mật iOS kín tiếng hơn bao giờ hết
VỊT. Đã có bản cập nhật iOS 16 này và sau đó một thời gian các bản cập nhật đã xuất hiện cho tất cả những thứ khác Các nền tảng của Apple, bao gồm cả iOS 15.
Và Apple nói, “Ồ, vâng, thực ra, bây giờ chúng tôi nghĩ về nó, đó là một ngày không. Bây giờ chúng tôi đã xem xét nó, mặc dù chúng tôi đã gấp rút tung ra bản cập nhật cho iOS 16 và không làm bất cứ điều gì cho iOS 15, nhưng hóa ra lỗi này chỉ áp dụng cho iOS 15 trở về trước.” [CƯỜI]
Vì vậy, wow, thật là một bí ẩn kỳ lạ!
Nhưng ít nhất họ đã vá mọi thứ cuối cùng.
Giờ đây, hóa ra lỗi zero-day cũ đó hiện đã được vá trong iOS 12.
Và đây là một trong những ngày không hoạt động của WebKit nghe có vẻ như cách nó được sử dụng ngoài thực tế là để cấy ghép phần mềm độc hại.
Và điều đó, như mọi khi, có mùi giống như phần mềm gián điệp.
Nhân tiện, đó là lỗi duy nhất được sửa trong iOS 12 được liệt kê – chỉ trong một ngày 0 đó.
Các nền tảng khác có vô số bản sửa lỗi.
May mắn thay, tất cả những điều đó dường như là chủ động; không ai trong số họ được Apple liệt kê là “đang bị khai thác tích cực”.
[TẠM NGỪNG]
Được rồi, hãy chuyển sang một thứ gì đó cực kỳ thú vị, Doug!
Tôi nghĩ chúng ta đang ở trong “typios”, phải không?
CHÓ. Có!
Sản phẩm câu hỏi Tôi đã tự hỏi bản thân mình… [Mỉa mai] Tôi không thể nhớ đã bao lâu và tôi chắc chắn rằng những người khác đang hỏi, “Làm cách nào để cố ý sửa lỗi chính tả có thể cải thiện bảo mật DNS?”
Bảo mật nghiêm trọng: Làm thế nào các tYpO dEliBeRaTe có thể cải thiện bảo mật DNS
VỊT. [LỪA DỐI]
Thật thú vị, đây là một ý tưởng xuất hiện lần đầu tiên vào năm 2008, vào khoảng thời gian cuối Dan Kaminsky, một nhà nghiên cứu bảo mật nổi tiếng vào thời điểm đó, đã phát hiện ra rằng có một số rủi ro đáng kể khi "đoán câu trả lời" đối với các máy chủ DNS có lẽ dễ khai thác hơn nhiều so với mọi người nghĩ.
Nơi bạn chỉ cần đưa ra các câu trả lời tại các máy chủ DNS, hy vọng rằng chúng tình cờ khớp với một yêu cầu gửi đi chưa có câu trả lời chính thức.
Bạn chỉ cần nghĩ, “Chà, tôi chắc rằng ai đó trong mạng lưới của bạn phải quan tâm đến việc truy cập miền naksec.test chỉ là về bây giờ. Vì vậy, hãy để tôi gửi lại cả đống câu trả lời nói rằng, 'Này, bạn đã hỏi về naksec.test; đây rồi,” và gửi cho bạn một số máy chủ hoàn toàn hư cấu.
Điều đó có nghĩa là bạn đến máy chủ của tôi thay vì đến giao dịch thực sự…
…vì vậy về cơ bản tôi đã hack máy chủ của bạn mà không cần đến gần máy chủ của bạn!
Và bạn nghĩ, “Chà, làm thế nào bạn có thể gửi *bất kỳ* trả lời nào? Chắc chắn có một số loại cookie mật mã ma thuật trong yêu cầu DNS gửi đi?”
Điều đó có nghĩa là máy chủ có thể nhận thấy rằng câu trả lời tiếp theo chỉ là do ai đó bịa ra.
Chà, bạn sẽ nghĩ vậy… nhưng hãy nhớ rằng DNS lần đầu tiên xuất hiện trong 1987Doug.
Và không chỉ bảo mật không phải là một vấn đề lớn như vậy, mà còn không có chỗ, với băng thông mạng trong ngày, cho các cookie mật mã đủ dài.
Vì vậy, các yêu cầu DNS, nếu bạn truy cập RFC 1035, được bảo vệ (nói nôm na là Doug) bằng một số nhận dạng duy nhất, hy vọng được tạo ngẫu nhiên bởi người gửi yêu cầu.
Đoán xem chúng dài bao nhiêu, Doug…
CHÓ. Không đủ dài?
VỊT. 16 bit.
CHÓ. Ohhhhhhh.
VỊT. Điều đó khá ngắn… nó khá ngắn, kể cả vào năm 1987!
Nhưng 16 bit là *hai byte*.
Điển hình là lượng entropy, như biệt ngữ có nó, mà bạn sẽ có trong một yêu cầu DNS (không có dữ liệu cookie nào khác được thêm vào – một yêu cầu DNS cơ bản, kiểu nguyên bản, trường học cũ)…
…bạn có số cổng nguồn UDP 16 bit (mặc dù bạn không thể sử dụng tất cả 16 bit, vì vậy hãy gọi nó là 15 bit).
Và bạn có số ID 16-bit, được chọn ngẫu nhiên… hy vọng máy chủ của bạn chọn ngẫu nhiên và không sử dụng trình tự có thể đoán được.
Vì vậy, bạn có 31 bit ngẫu nhiên.
Và mặc dù 231 [chỉ hơn 2 tỷ] là rất nhiều yêu cầu khác nhau mà bạn phải gửi, điều đó không có gì lạ trong những ngày này.
Ngay cả trên chiếc máy tính xách tay cổ xưa của tôi, Doug, gửi 216 [65,536] các yêu cầu UDP khác nhau tới máy chủ DNS mất một khoảng thời gian gần như vô cùng ngắn.
Vì vậy, 16 bit gần như tức thời và 31 bit là có thể thực hiện được.
Vì vậy, ý tưởng, quay trở lại năm 2008 là…
Điều gì sẽ xảy ra nếu chúng tôi lấy tên miền mà bạn đang tra cứu, chẳng hạn như naksec.test, và thay vì làm điều mà hầu hết các trình phân giải DNS làm và nói, “Tôi muốn tra cứu n-a-k-s-e-c dot t-e-s-t,” tất cả đều ở dạng chữ thường vì chữ thường trông đẹp mắt (hoặc, nếu bạn muốn kiểu cũ, tất cả đều ở dạng HOA, vì DNS không phân biệt chữ hoa chữ thường, hãy nhớ)?
Điều gì sẽ xảy ra nếu chúng ta nhìn lên nAKseC.tESt, với một chuỗi được chọn ngẫu nhiên gồm chữ thường, HOA, HOA, viết thường, v.v. và chúng tôi nhớ trình tự mình đã sử dụng và chúng tôi đợi câu trả lời quay lại?
Bởi vì các phản hồi DNS bắt buộc phải có một bản sao của yêu cầu ban đầu trong đó.
Điều gì sẽ xảy ra nếu chúng ta có thể sử dụng một số dữ liệu trong yêu cầu đó như một loại “tín hiệu bí mật”?
Bằng cách kết hợp trường hợp này, kẻ gian sẽ phải đoán cổng nguồn UDP đó; họ sẽ phải đoán số nhận dạng 16 bit đó trong câu trả lời; *và* họ sẽ phải đoán cách chúng tôi chọn miS-sPEll nAKsEc.TeST.
Và nếu họ làm sai bất kỳ điều nào trong ba điều đó, cuộc tấn công sẽ thất bại.
CHÓ. Oh, tốt!
VỊT. Và Google đã quyết định, “Này, hãy thử cái này.”
Vấn đề duy nhất là trong các tên miền thực sự ngắn (để chúng bắt mắt, dễ viết và dễ nhớ), như của Twitter t.co, bạn chỉ nhận được ba ký tự có thể thay đổi trường hợp của chúng.
Nó không phải lúc nào cũng hữu ích, nhưng nói một cách dễ hiểu, tên miền của bạn càng dài thì bạn càng an toàn! [CƯỜI]
Và tôi chỉ nghĩ đó là một câu chuyện nhỏ hay ho…
CHÓ. Khi mặt trời bắt đầu lặn trong chương trình của chúng tôi hôm nay, chúng tôi có một bình luận của độc giả.
Bây giờ, nhận xét này xuất hiện ngay sau podcast tuần trước, S3 Ep118.
Độc giả Stephen viết… về cơ bản anh ấy nói:
Gần đây tôi đã nghe các bạn nói rất nhiều về trình quản lý mật khẩu – tôi quyết định giới thiệu ứng dụng của riêng mình.
Tôi tạo những mật khẩu an toàn này; Tôi có thể lưu trữ chúng trên thẻ nhớ hoặc thẻ nhớ, chỉ kết nối thẻ nhớ khi tôi cần giải nén và sử dụng mật khẩu.
Phương pháp thanh sẽ có rủi ro hợp lý thấp?
Tôi cho rằng mình có thể làm quen với các kỹ thuật mã hóa để mã hóa và giải mã thông tin trên thanh ghi, nhưng tôi không khỏi cảm thấy điều đó có thể đưa tôi vượt ra ngoài cách tiếp cận đơn giản mà tôi đang tìm kiếm.
Vì vậy, những gì bạn nói, Paul?
VỊT. Chà, nếu nó đưa bạn vượt ra ngoài cách tiếp cận “đơn giản”, thì điều đó có nghĩa là nó sẽ trở nên phức tạp.
Và nếu nó phức tạp, thì đó là một bài tập học tập tuyệt vời…
…nhưng có lẽ mã hóa mật khẩu không phải là thứ mà bạn muốn thực hiện những thử nghiệm đó. [CƯỜI]
CHÓ. Tôi tin rằng tôi đã nghe bạn nói trước đây trong chính chương trình này nhiều lần: “Không cần phải cuộn mã hóa của riêng bạn; có một số thư viện mã hóa tốt mà bạn có thể tận dụng.”
VỊT. Có… đừng đan, móc, mũi kim hoặc khâu chéo mã hóa của riêng bạn nếu bạn có thể giúp được!
Vấn đề mà Stephen đang cố gắng giải quyết là: “Tôi muốn dành riêng một ổ USB di động để đặt mật khẩu trên đó – làm cách nào để mã hóa ổ đĩa một cách thuận tiện?”
Và khuyến nghị của tôi là bạn nên sử dụng thứ gì đó mã hóa toàn bộ thiết bị [FDE] *bên trong hệ điều hành*.
Bằng cách đó, bạn đã có một thanh USB chuyên dụng; bạn cắm nó vào, và hệ điều hành nói, '"Điều đó đã bị xáo trộn - Tôi cần mật khẩu."
Và hệ điều hành xử lý việc giải mã toàn bộ ổ đĩa.
Giờ đây, bạn có thể có *tệp* được mã hóa bên trong *thiết bị* được mã hóa, nhưng điều đó có nghĩa là nếu bạn mất thiết bị, thì toàn bộ ổ đĩa, trong khi nó không được đếm và rút phích cắm khỏi máy tính của bạn, sẽ bị cắt nhỏ.
Và thay vì cố gắng tạo trình điều khiển thiết bị của riêng bạn để làm điều đó, tại sao không sử dụng một trình điều khiển được tích hợp sẵn trong hệ điều hành?
Đó là khuyến nghị của tôi.
Và đây là lúc nó trở nên vừa dễ dàng vừa hơi phức tạp một chút.
Nếu bạn đang chạy Linux, thì bạn sử dụng sang trọng [Thiết lập khóa hợp nhất Linux].
Trên máy Mac, điều đó thực sự dễ dàng: bạn có một công nghệ gọi là FileVault được tích hợp trong Mac
Trên Windows, tương đương với FileVault hoặc LUKS được gọi BitLocker; bạn có thể đã nghe nói về nó.
Vấn đề là nếu bạn có một trong các phiên bản Home của Windows, bạn không thể thực hiện lớp mã hóa toàn bộ đĩa đó trên các ổ đĩa di động.
Bạn phải chi thêm tiền để có phiên bản Pro hoặc Windows loại dành cho doanh nghiệp để có thể sử dụng mã hóa toàn bộ đĩa BitLocker.
Tôi nghĩ đó là một điều đáng tiếc.
Tôi ước gì Microsoft chỉ nói: “Chúng tôi khuyến khích bạn sử dụng nó ở mọi nơi bạn có thể – trên tất cả các thiết bị của bạn nếu bạn muốn.”
Bởi vì ngay cả khi hầu hết mọi người không, ít nhất một số người sẽ làm.
Vì vậy, đó là lời khuyên của tôi.
Ngoại lệ là nếu bạn có Windows và bạn đã mua một máy tính xách tay, chẳng hạn như tại một cửa hàng tiêu dùng có phiên bản Home, bạn sẽ phải chi thêm một ít tiền.
Bởi vì, rõ ràng, mã hóa ổ đĩa di động, nếu bạn là khách hàng của Microsoft, không đủ quan trọng để tích hợp vào phiên bản Home của hệ điều hành.
CHÓ. Được rồi, rất tốt.
Cảm ơn, Stephen, vì đã gửi nó.
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 tới tips@sophos.com, bạn có thể nhận xét về bất kỳ bài viết nào của chúng tôi hoặc bạn có thể đánh giá 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]
- Phân phối nội dung và PR được hỗ trợ bởi SEO. Được khuếch đại ngay hôm nay.
- Platoblockchain. Web3 Metaverse Intelligence. Khuếch đại kiến thức. Truy cập Tại đây.
- nguồn: https://nakedsecurity.sophos.com/2023/01/26/s3-ep119-breaches-patches-leaks-and-tweaks-audio-text/
