Bạn sẽ làm gì nếu bạn nhận ra nhà cung cấp dịch vụ lưu trữ email có thể thấy mật khẩu của mình?

Chúng tôi đã nhận được một email vào năm ngoái từ nhà cung cấp dịch vụ lưu trữ của chúng tôi về một trong những tài khoản của chúng tôi - nó đã bị xâm phạm và được sử dụng để cung cấp một sự trợ giúp khá tốt về thư rác.

Rõ ràng, người dùng đã đặt lại mật khẩu của mình thành một biến thể của tên cô ấy (tên cuối cùng là thứ mà bạn có thể đoán được lần đầu tiên.) Cô ấy đã nhanh chóng bị hack trong vòng một tuần - tài khoản của cô ấy đã gửi đi 270.000 email spam - và rất nhanh chóng bị chặn.

Cho đến nay, không có gì đặc biệt khác thường. Điều đó xảy ra. Bạn thay đổi mật khẩu của mình thành một cái gì đó an toàn hơn, giáo dục người dùng và tiếp tục.

Tuy nhiên, điều gì đó liên quan đến tôi thậm chí còn hơn cả một trong những tài khoản của chúng tôi đã bị xâm phạm.

Nhà cung cấp dịch vụ lưu trữ của chúng tôi, trong nỗ lực hữu ích, thực sự đã trích dẫn mật khẩu cho chúng tôi trong email sau:

Tôi ngạc nhiên. Chúng tôi sẽ sớm gia hạn hợp đồng của chúng tôi - và điều này cảm thấy giống như một người giải quyết.

Làm thế nào phổ biến cho một nhà cung cấp dịch vụ lưu trữ để có thể tìm ra mật khẩu thực tế được sử dụng trên một tài khoản?

Có phải hầu hết các nhà cung cấp dịch vụ lưu trữ đều có bộ phận lạm dụng tài khoản có quyền truy cập nhiều hơn đại diện trực tuyến (và có thể tra cứu mật khẩu nếu cần thiết) hoặc những người này không tuân theo cách thực hành tốt nhất để bất kỳ nhân viên nào của họ có thể truy cập người dùng mật khẩu? Tôi nghĩ mật khẩu được cho là bị băm và không thể truy xuất được? Điều này có nghĩa là họ lưu trữ mật khẩu của mọi người trong văn bản thuần túy?

Thậm chí là hợp pháp cho một nhà cung cấp dịch vụ lưu trữ để có thể khám phá mật khẩu tài khoản theo cách này? Nó chỉ có vẻ rất đáng kinh ngạc đối với tôi.

Trước khi chúng tôi xem xét việc thay đổi nhà cung cấp, tôi muốn đảm bảo một chút rằng đây không phải là thông lệ và nhà cung cấp dịch vụ lưu trữ tiếp theo của chúng tôi cũng sẽ không có những thứ được thiết lập theo cùng một cách.

Mong muốn được nghe quan điểm của bạn về điều này.

Có, thông thường các ISP và nhà cung cấp dịch vụ email lưu trữ mật khẩu của bạn ở dạng văn bản thuần hoặc định dạng có thể dễ dàng phục hồi thành văn bản thuần túy.

Lý do cho điều này liên quan đến các giao thức xác thực được sử dụng với PPP (dialup và DSL), RADIUS (dialup, 802.1x, v.v.) và POP (email), trong số các giao thức khác.

Sự cân bằng ở đây là nếu mật khẩu được băm một chiều trong cơ sở dữ liệu của ISP, thì các giao thức xác thực duy nhất có thể được sử dụng là các giao thức truyền mật khẩu qua dây ở dạng văn bản thuần túy. Nhưng nếu ISP lưu trữ mật khẩu thực tế, thì các giao thức xác thực an toàn hơn có thể được sử dụng.

Ví dụ, xác thực PPP hoặc RADIUS có thể sử dụng CHAP, bảo mật dữ liệu xác thực trong quá trình, nhưng yêu cầu mật khẩu văn bản đơn giản được lưu trữ bởi ISP. Tương tự với phần mở rộng APOP thành POP3.

Ngoài ra, tất cả các dịch vụ khác nhau mà ISP cung cấp đều sử dụng các giao thức khác nhau và cách duy nhất để tất cả chúng xác thực với cùng một cơ sở dữ liệu là giữ mật khẩu ở dạng văn bản thuần túy.

Điều này không giải quyết vấn đề ai trong số các nhân viên của ISP có quyền truy cập vào cơ sở dữ liệu và mặc dù nó được bảo mật tốt như thế nào . Bạn vẫn nên hỏi những câu hỏi khó về những điều đó.

Tuy nhiên, như bây giờ bạn có thể đã học được, gần như chưa từng thấy cơ sở dữ liệu của ISP bị xâm phạm, trong khi tất cả đều quá phổ biến đối với người dùng cá nhân bị xâm phạm. Bạn có rủi ro một trong hai cách.

Xem thêm Tôi có sai khi tin rằng mật khẩu không bao giờ có thể khôi phục được (băm một chiều) không? trên trang web chị em của chúng tôi Bảo mật CNTT

Thật không may, điều này khá phổ biến với các máy chủ ngân sách và không phải là chưa từng thấy ngay cả với các máy chủ lớn hơn. Những thứ như cpanel thường xuyên cần mật khẩu văn bản đơn giản của bạn để có thể đăng nhập vào các dịch vụ khác nhau như bạn, v.v.

Điều duy nhất bạn có thể làm là hỏi trả trước nếu mật khẩu được băm.

Họ có thể lưu trữ mật khẩu bằng văn bản thuần túy hoặc sử dụng một số loại mã hóa có thể đảo ngược.

Như bạn đã phỏng đoán, điều này rất tệ.

Do sự độc hại hoặc sơ suất của nhân viên hoặc do bên ngoài xâm phạm hệ thống của họ, mật khẩu văn bản đơn giản bị sử dụng sai sẽ gây ra rủi ro nghiêm trọng - không chỉ cho hệ thống của họ, mà đối với các hệ thống khác, mọi người có thể đã sử dụng cùng một mật khẩu.

Lưu trữ mật khẩu có trách nhiệm có nghĩa là sử dụng các hàm băm một chiều thay vì mã hóa đảo ngược, với một muối (dữ liệu ngẫu nhiên) được thêm vào đầu vào của người dùng để ngăn việc sử dụng bảng cầu vồng .

Nếu tôi ở trong đôi giày của bạn, tôi sẽ hỏi nhà cung cấp một số câu hỏi khó về cách chính xác, họ lưu trữ mật khẩu và cách chính xác, đại diện hỗ trợ của họ có thể lấy lại mật khẩu. Điều này có thể không có nghĩa là họ lưu trữ mật khẩu ở dạng văn bản đơn giản, nhưng có thể họ đang đăng nhập chúng ở đâu đó khi thay đổi - cũng là một rủi ro rất lớn.

Tất cả các câu trả lời khác là tuyệt vời và có điểm lịch sử rất tốt.

Tuy nhiên, chúng ta đang sống trong thời đại lưu trữ mật khẩu bằng văn bản đơn giản gây ra các vấn đề tài chính lớn và có thể phá hủy hoàn toàn các doanh nghiệp. Gửi mật khẩu bằng văn bản đơn giản qua email không an toàn cũng nghe có vẻ vô lý trong thời đại NSA hút tất cả dữ liệu truyền qua.

Bạn không phải chấp nhận thực tế là một số giao thức cũ yêu cầu mật khẩu bằng văn bản thuần túy. Nếu tất cả chúng ta ngừng chấp nhận các dịch vụ như vậy, có lẽ các nhà cung cấp dịch vụ sẽ làm gì đó với nó và cuối cùng không tán thành công nghệ cổ đại.

Một số người có thể nhớ rằng một lần khi bạn muốn lên máy bay để bay đến một quốc gia khác, bạn thực sự sẽ chỉ cần bước vào máy bay từ bãi đậu xe trên đường. Không có bảo mật gì bao giờ. Ngày nay, mọi người nhận ra rằng các biện pháp an ninh phù hợp là bắt buộc và tất cả các sân bay đã áp dụng chúng.

Tôi sẽ chuyển sang một nhà cung cấp email khác. Tìm kiếm trên "nhà cung cấp email an toàn" mang lại nhiều kết quả.

Có một số điểm tốt trong các ý kiến. Có lẽ tìm kiếm "nhà cung cấp email an toàn" sẽ có ý nghĩa vì tất cả các nhà cung cấp email sẽ tự hào rằng họ an toàn. Tuy nhiên, tôi không thể đề xuất một công ty cụ thể và có lẽ đó cũng không phải là một ý tưởng hay. Nếu bạn xác định một công ty cụ thể đặt câu hỏi khó về bảo mật trước tiên sẽ là một việc nên làm.

Đề nghị của tôi là rời đi, và hỏi những người tiếp theo chính sách của họ là gì trước tiên!
Nếu bạn cảm thấy tốt, bạn có thể nói với các nhà cung cấp cũ tại sao bạn lại rời đi.

Ngoài ra để giải quyết câu trả lời khác, ngày của các bảng cầu vồng đã trôi qua. Chúng đã được thay thế bởi các GPU mạnh mẽ và chiếm quá nhiều dung lượng lưu trữ (băm nhị phân rõ ràng là không nén tốt; và dù sao bạn cũng sẽ không lưu trữ chúng trong ASCII). Nó nhanh hơn (tính lại) tính toán hàm băm trên GPU hơn là đọc nó ra khỏi đĩa.

Tùy thuộc vào thuật toán băm được sử dụng và GPU, một máy tính bẻ khóa mật khẩu hiện đại có thể được dự kiến ​​sẽ vượt qua khoảng 100 triệu đến một tỷ băm mỗi giây. Theo đó , (một chút ngày tháng về những gì nó nghĩ rằng máy tính / siêu máy tính có thể làm được), điều đó có nghĩa là bất kỳ mật khẩu 6 char nào cũng có thể bị bẻ khóa trong vài giây. Các bảng cho băm 7 & 8 char trong tất cả các thuật toán khác nhau (MD5, SHA-1, SHA-256, SHA-512, Blowfish, v.v.) sẽ tiêu tốn dung lượng ổ đĩa không phù hợp (nhận ra rằng bạn cần lưu trữ chúng trên ổ SSD , không phải là một đĩa từ tính, cho tốc độ truy cập) và bạn có thể thấy tại sao các cuộc tấn công dựa trên từ điển sử dụng GPU sẽ mang lại mật khẩu nhanh hơn.

Một bài viết hay cho những người đến hiện trường là Làm thế nào tôi trở thành một kẻ bẻ khóa mật khẩu tại Ars Technica.

Điều này đã xảy ra với tôi!

Vài năm trước, danh tính của tôi đã bị xâm phạm khi nhà cung cấp dịch vụ lưu trữ của tôi (cũng là nhà cung cấp email của tôi vào thời điểm đó) bị vi phạm an ninh. Tôi thức dậy vì không thể kiểm tra email vì mật khẩu của tôi đã được đặt lại. Với sự kiểm soát email của tôi, họ đã cố gắng đặt lại mật khẩu của tôi tại Amazon và PayPal. Bạn có thể đoán những gì đến tiếp theo, phải không? Phí thẻ tín dụng gian lận!

May mắn thay, tôi đã có thể tìm ra những gì đang xảy ra tương đối nhanh chóng, gọi cho nhà cung cấp dịch vụ lưu trữ của tôi qua điện thoại và xác thực danh tính của tôi mặc dù thông tin tài khoản và các câu hỏi bảo mật đã bị thay đổi (tất cả chỉ trong vài giờ). Trong cuộc trò chuyện này, đại diện dịch vụ khách hàng đã có thể cho tôi biết lịch sử mật khẩu của tôi, khi nào nó đã được thay đổi và để làm gì. Đó là tất cả những gì tôi cần nghe để biết rằng tôi hoàn toàn cần thiết để thay đổi nhà cung cấp.

Không có lý do gì nó sẽ xảy ra với bạn, công ty của bạn!

Tôi đã nghi ngờ về tính kỹ lưỡng của công ty này khi nói đến vấn đề bảo mật, những điều tôi nhận thấy ở đây và ở đó trong nhiều năm làm việc với họ. Nhưng tôi luôn tự thuyết phục bản thân rằng đó không phải là vấn đề lớn hoặc có thể tôi đã nhầm. Tôi đã không nhầm, và bạn cũng vậy!

Nếu tôi đã hành động khi lần đầu tiên tôi nghi ngờ họ không coi trọng an ninh thì toàn bộ cơn ác mộng nhỏ sẽ không bao giờ xảy ra. Để nghĩ những gì có thể xảy ra trong trường hợp một tài khoản công ty có giá trị bị xâm phạm? Bạn sẽ dễ dàng thoát ra nếu họ chỉ gửi SPAM. Công ty tôi đang làm việc lúc đó cũng đang sử dụng nhà cung cấp này và chúng tôi ưu tiên chuyển ra càng nhanh càng tốt.

Tin vào bản năng của bạn! Đừng bỏ qua việc di chuyển ra khỏi sự lười biếng hoặc vì thiết lập hiện tại của bạn "hoạt động tốt". Phần đáng sợ nhất của các giám sát bảo mật treo thấp như lưu trữ mật khẩu trong văn bản rõ ràng, cấu hình máy chủ không đúng cách, v.v. là chúng nói lên sự bất tài và / hoặc lười biếng trong văn hóa kỹ thuật của họ, và đó là văn hóa mà tôi không muốn nhiệm vụ của công ty tôi quan trọng hợp đồng dịch vụ bất cứ nơi nào gần.

Tôi có thể thấy một lời giải thích khác, trong đó mật khẩu của bạn thực sự được băm trên các máy chủ của nhà cung cấp của bạn.

Khi nhà cung cấp liên lạc với Bạn chỉ một ngày sau đó, anh ta có lẽ (và đây là một phỏng đoán) đã lấy nó từ nhật ký máy chủ vì tập lệnh thay đổi mật khẩu của anh ta đang gửi dữ liệu thông qua phương thức GET.

Nghe có vẻ đơn giản hơn Nhà cung cấp của bạn có cơ sở dữ liệu đầy đủ các hồ sơ về thời gian, ai và cách thay đổi mật khẩu của anh ấy. Bạn biết dao cạo của Occam ...;)