Căn cứ vào nhận xét tôi đưa ra cho câu hỏi:
Một điểm quan trọng đã được hầu hết mọi người chú ý đến ... Phản ứng ban đầu của tôi rất giống với @Michael Brooks, cho đến khi tôi nhận ra, như @stefanw, rằng vấn đề ở đây là những yêu cầu bị phá vỡ , nhưng đây là những gì họ đang có.
Nhưng sau đó, nó đã xảy ra với tôi rằng đó thậm chí có thể không phải là trường hợp! Điểm còn thiếu ở đây, là giá trị bất thành văn của tài sản của ứng dụng. Nói một cách đơn giản, đối với một hệ thống giá trị thấp, một cơ chế xác thực hoàn toàn an toàn, với tất cả các quy trình liên quan, sẽ là quá mức cần thiết và lựa chọn bảo mật sai .
Rõ ràng, đối với một ngân hàng, "các thực tiễn tốt nhất" là điều bắt buộc và không có cách nào để vi phạm đạo đức CWE-257. Nhưng thật dễ dàng để nghĩ về các hệ thống giá trị thấp, nơi nó không đáng giá (nhưng vẫn cần một mật khẩu đơn giản).
Điều quan trọng cần nhớ là, chuyên môn bảo mật thực sự là trong việc tìm kiếm sự đánh đổi phù hợp, KHÔNG phải trong việc đưa ra những "Thực tiễn tốt nhất" một cách giáo điều mà bất cứ ai cũng có thể đọc trực tuyến.
Do đó, tôi đề xuất một giải pháp khác:
Tùy thuộc vào giá trị của hệ thống và CHỈ NẾU hệ thống có giá trị thấp một cách thích hợp mà không có tài sản "đắt tiền" (bao gồm chính danh tính), VÀ có các yêu cầu kinh doanh hợp lệ tạo ra quy trình phù hợp không thể (hoặc đủ khó / tốn kém), VÀ khách hàng nhận thức được tất cả các cảnh báo ...
Sau đó, có thể chỉ cần cho phép mã hóa đảo ngược, không có vòng quay đặc biệt nào có thể nhảy qua.
Tôi chỉ dừng lại ở việc nói rằng đừng bận tâm đến việc mã hóa, bởi vì nó rất đơn giản / rẻ tiền để thực hiện (thậm chí xem xét việc quản lý khóa thụ động) và nó KHÔNG cung cấp bảo vệ MỘT SỐ (hơn chi phí thực hiện). Ngoài ra, giá trị của nó là xem cách cung cấp cho người dùng mật khẩu gốc, cho dù qua email, hiển thị trên màn hình, v.v.
Vì giả định ở đây là giá trị của mật khẩu bị đánh cắp (ngay cả trong tổng hợp) là khá thấp, bất kỳ giải pháp nào trong số này đều có thể hợp lệ.
Vì có một cuộc thảo luận sôi nổi đang diễn ra, thực sự là các cuộc thảo luận sôi nổi, trong các bài đăng khác nhau và các luồng nhận xét riêng biệt, tôi sẽ thêm một số giải thích và trả lời một số điểm rất hay đã được nêu ra ở đây.
Để bắt đầu, tôi nghĩ mọi người ở đây rõ ràng cho phép lấy lại mật khẩu ban đầu của người dùng, đó là Thực tiễn xấu và nói chung Không phải là Ý tưởng hay. Điều đó hoàn toàn không phải là tranh chấp ...
Hơn nữa, tôi sẽ nhấn mạnh rằng trong nhiều tình huống, MOST này - nó thực sự sai, thậm chí hôi, khó chịu, và xấu xí .
Tuy nhiên, mấu chốt của câu hỏi xoay quanh nguyên tắc , IS có bất kỳ tình huống nào có thể không cần thiết để cấm điều này và nếu vậy, làm thế nào để làm điều đó theo cách đúng nhất phù hợp với tình huống .
Bây giờ, như @Thomas, @sfussalanger và một vài người khác đã đề cập, cách duy nhất để trả lời câu hỏi đó là phân tích rủi ro kỹ lưỡng về bất kỳ tình huống nào (hoặc giả định), để hiểu những gì đang bị đe dọa và những gì giảm nhẹ khác đang diễn ra để đủ khả năng bảo vệ.
Không, nó KHÔNG phải là một từ thông dụng, đây là một trong những công cụ cơ bản, quan trọng nhất đối với một chuyên gia bảo mật thực tế. Thực tiễn tốt nhất là tốt đến một điểm (thường là hướng dẫn cho người thiếu kinh nghiệm và hack), sau thời điểm đó phân tích rủi ro chu đáo.
Vâng, thật buồn cười - Tôi luôn coi mình là một trong những kẻ cuồng tín bảo mật, và bằng cách nào đó tôi ở phía đối diện với cái gọi là "Chuyên gia bảo mật" ... Chà, sự thật là - bởi vì tôi là một kẻ cuồng tín, và một chuyên gia bảo mật thực tế trong cuộc sống thực - Tôi không tin vào việc thúc đẩy giáo điều "Thực tiễn tốt nhất" (hoặc CWEs) mà KHÔNG phân tích rủi ro hết sức quan trọng .
"Hãy coi chừng người nhiệt tình bảo mật, người nhanh chóng áp dụng mọi thứ trong vành đai công cụ của họ mà không biết vấn đề thực sự họ đang bảo vệ là gì. Bảo mật hơn không nhất thiết phải tương đương với bảo mật tốt."
Phân tích rủi ro và những kẻ cuồng tín bảo mật thực sự sẽ chỉ ra một sự đánh đổi thông minh hơn, dựa trên giá trị / rủi ro, dựa trên rủi ro, tổn thất tiềm tàng, các mối đe dọa có thể, giảm thiểu bổ sung, v.v. Bất kỳ "Chuyên gia bảo mật" nào cũng không thể chỉ ra phân tích rủi ro như dựa trên các khuyến nghị của họ, hoặc hỗ trợ sự đánh đổi hợp lý, nhưng thay vào đó, họ thích thúc đẩy giáo điều và CWE mà không hiểu cách thực hiện phân tích rủi ro, nhưng không phải là Hacks, và Expertise của họ không xứng đáng với giấy vệ sinh mà họ đã in.
Thật vậy, đó là cách chúng tôi có được sự lố bịch đó là An ninh sân bay.
Nhưng trước khi chúng ta nói về sự đánh đổi thích hợp để thực hiện trong TÌNH HÌNH NÀY, chúng ta hãy xem xét các rủi ro rõ ràng (rõ ràng, bởi vì chúng ta không có tất cả thông tin cơ bản về tình huống này, tất cả chúng ta đều đưa ra giả thuyết - vì câu hỏi là giả thuyết nào tình hình có thể có ...)
Chúng ta hãy giả sử một hệ thống GIÁ TRỊ THẤP, nhưng không quá tầm thường đến mức truy cập công khai - chủ sở hữu hệ thống muốn ngăn chặn mạo danh thông thường, nhưng bảo mật "cao" không phải là điều tối quan trọng khi sử dụng. (Vâng, đó là một sự đánh đổi hợp pháp để CHẤP NHẬN rủi ro rằng bất kỳ người viết kịch bản thành thạo nào cũng có thể hack trang web ... Đợi đã, bây giờ không phải là APT thịnh hành ...?)
Ví dụ, giả sử tôi đang sắp xếp một trang web đơn giản cho một cuộc họp mặt gia đình lớn, cho phép mọi người động não về nơi chúng ta muốn đi trong chuyến cắm trại năm nay. Tôi ít lo lắng hơn về một số tin tặc ẩn danh, hoặc thậm chí là anh em họ Fred đang cố gắng lặp lại đề nghị quay trở lại hồ Wantanamanabikiliki, vì tôi nói về dì Erma không thể đăng nhập khi cô ấy cần. Bây giờ, dì Erma, là một nhà vật lý hạt nhân, không giỏi nhớ mật khẩu, hay thậm chí là sử dụng máy tính ... Vì vậy, tôi muốn loại bỏ mọi ma sát có thể cho cô ấy. Một lần nữa, tôi KHÔNG lo lắng về việc hack, tôi chỉ không muốn những sai lầm ngớ ngẩn khi đăng nhập sai - tôi muốn biết ai sẽ đến và họ muốn gì.
Dù sao.
Vì vậy, những rủi ro chính của chúng ta ở đây là gì, nếu chúng ta mã hóa đối xứng mật khẩu, thay vì sử dụng hàm băm một chiều?
- Mạo danh người dùng? Không, tôi đã chấp nhận rủi ro đó, không thú vị.
- Quản trị viên ác? Vâng, có lẽ ... Nhưng một lần nữa, tôi không quan tâm nếu ai đó có thể mạo danh người dùng khác, NỘI hay không ... và dù sao một quản trị viên độc hại là sẽ có được mật khẩu của bạn không có vấn đề gì - nếu xấu ra đi của admin của bạn, trò chơi của mình trên anyway.
- Một vấn đề khác được nêu ra, đó là danh tính thực sự được chia sẻ giữa một số hệ thống. Ah! Đây là một rủi ro rất thú vị, đòi hỏi phải xem xét kỹ hơn.
Hãy để tôi bắt đầu bằng cách khẳng định rằng đó không phải là danh tính thực sự được chia sẻ, mà là bằng chứng hoặc thông tin xác thực. Được rồi, vì mật khẩu được chia sẻ sẽ cho phép tôi truy cập vào một hệ thống khác một cách hiệu quả (giả sử, tài khoản ngân hàng của tôi hoặc gmail), đây thực sự là cùng một danh tính, vì vậy nó chỉ là ngữ nghĩa ... Ngoại trừ việc đó không phải là . Danh tính được quản lý riêng biệt bởi mỗi hệ thống, trong trường hợp này (mặc dù có thể có các hệ thống id bên thứ ba, chẳng hạn như OAuth - vẫn, tách biệt với danh tính trong hệ thống này - nhiều hơn về điều này sau).
Như vậy, điểm rủi ro cốt lõi ở đây là người dùng sẽ sẵn sàng nhập mật khẩu (giống) của mình vào một số hệ thống khác nhau - và bây giờ, tôi (quản trị viên) hoặc bất kỳ tin tặc nào khác trên trang web của tôi sẽ có quyền truy cập vào mật khẩu của dì Erma cho trang web tên lửa hạt nhân.
Hừm.
Có bất cứ điều gì ở đây dường như tắt cho bạn?
Nó nên.
Hãy bắt đầu với thực tế là bảo vệ hệ thống tên lửa hạt nhân không phải là trách nhiệm của tôi , tôi chỉ xây dựng một địa điểm đi chơi gia đình frakkin (cho gia đình MY). Vậy trách nhiệm thuộc về ai? Umm ... Thế còn hệ thống tên lửa hạt nhân? Tât nhiên.
Thứ hai, nếu tôi muốn đánh cắp mật khẩu của ai đó (một người được biết là liên tục sử dụng cùng một mật khẩu giữa các trang web bảo mật và không an toàn) - tại sao tôi lại bận tâm hack trang web của bạn? Hoặc đấu tranh với mã hóa đối xứng của bạn? Goshdarnitall, tôi chỉ có thể đưa lên trang web đơn giản của riêng mình , để người dùng đăng ký để nhận được RẤT NHIỀU TIN TỨC QUAN TRỌNG về bất cứ điều gì họ muốn ... Puffo Presto, tôi "đánh cắp" mật khẩu của họ.
Vâng, giáo dục người dùng luôn quay trở lại để cắn chúng tôi trong hienie, phải không?
Và bạn không thể làm gì về điều đó ... Ngay cả khi bạn phải băm mật khẩu của họ trên trang web của mình và làm mọi thứ khác mà TSA có thể nghĩ ra, bạn đã thêm bảo vệ vào mật khẩu của họ KHÔNG MỘT CÁI GÌ , nếu họ sẽ giữ bừa bãi dán mật khẩu của họ vào mọi trang web mà họ va vào. Đừng bận tâm cố gắng.
Nói cách khác, Bạn không sở hữu mật khẩu của họ , vì vậy hãy ngừng cố gắng hành động như bạn.
Vì vậy, các chuyên gia bảo mật thân mến của tôi, như một bà già thường hỏi Wendy, "Rủi ro ở đâu?"
Một vài điểm khác, để trả lời cho một số vấn đề nêu trên:
- CWE không phải là luật, hoặc quy định, hoặc thậm chí là một tiêu chuẩn. Nó là một tập hợp các điểm yếu phổ biến , tức là nghịch đảo của "Thực tiễn tốt nhất".
- Vấn đề về danh tính được chia sẻ là một vấn đề thực tế, nhưng bị hiểu lầm (hoặc hiểu sai) bởi những người không tán thành ở đây. Đây là vấn đề chia sẻ danh tính trong chính nó (!), KHÔNG phải về việc bẻ khóa mật khẩu trên các hệ thống giá trị thấp. Nếu bạn đang chia sẻ mật khẩu giữa hệ thống giá trị thấp và hệ thống giá trị cao, vấn đề đã có sẵn!
- Bởi, điểm trước đó thực sự sẽ chỉ ra LẠI bằng cách sử dụng OAuth và tương tự cho cả hai hệ thống giá trị thấp này và hệ thống ngân hàng giá trị cao.
- Tôi biết đó chỉ là một ví dụ, nhưng (đáng buồn thay) các hệ thống FBI không thực sự được bảo mật nhất xung quanh. Không hoàn toàn giống như máy chủ blog của con mèo của bạn, nhưng chúng cũng không vượt qua một số ngân hàng an toàn hơn.
- Kiến thức phân chia, hoặc kiểm soát kép, các khóa mã hóa KHÔNG xảy ra chỉ trong quân đội, trên thực tế, PCI-DSS hiện nay yêu cầu điều này từ tất cả các thương nhân, vì vậy nó không thực sự tồn tại ở đó nữa (NẾU giá trị biện minh cho nó).
- Đối với tất cả những người đang phàn nàn rằng những câu hỏi như thế này là những gì làm cho nghề phát triển trông rất tệ: đó là những câu trả lời giống như vậy, làm cho nghề bảo mật trông thậm chí còn tồi tệ hơn. Một lần nữa, phân tích rủi ro tập trung vào kinh doanh là những gì được yêu cầu, nếu không, bạn làm cho mình trở nên vô dụng. Ngoài việc bị sai.
- Tôi đoán đây là lý do tại sao không nên lấy một nhà phát triển thông thường và bỏ thêm trách nhiệm bảo mật cho anh ta, mà không cần đào tạo để suy nghĩ khác biệt và tìm kiếm sự đánh đổi chính xác. Không có ý xúc phạm, đối với những người ở đây, tôi là tất cả - nhưng đào tạo nhiều hơn theo thứ tự.
Phù Thật là một bài viết dài ...
Nhưng để trả lời câu hỏi ban đầu của bạn, @Shane:
- Giải thích cho khách hàng cách thích hợp để làm việc.
- Nếu anh ấy vẫn khăng khăng, giải thích thêm, nhấn mạnh, tranh luận. Ném một cơn giận dữ, nếu cần thiết.
- Giải thích RỦI RO KINH DOANH cho anh ta. Chi tiết là tốt, số liệu là tốt hơn, một bản demo trực tiếp thường là tốt nhất.
- NẾU BẠN VẪN khẳng định, VÀ trình bày lý do kinh doanh hợp lệ - đã đến lúc bạn thực hiện một cuộc gọi phán xét:
Trang web này có giá trị thấp không? Có thực sự là một trường hợp kinh doanh hợp lệ? Nó có đủ tốt cho bạn không? Không có rủi ro nào khác mà bạn có thể xem xét, điều đó sẽ vượt xa lý do kinh doanh hợp lệ? (Và tất nhiên, khách hàng KHÔNG phải là trang web độc hại, nhưng đó là duh).
Nếu vậy, chỉ cần đi thẳng về phía trước. Không đáng để bỏ công sức, ma sát và mất sử dụng (trong tình huống giả định này) để đưa quy trình cần thiết vào vị trí. Bất kỳ quyết định nào khác (một lần nữa, trong tình huống này) là một sự đánh đổi tồi tệ.
Vì vậy, điểm mấu chốt và câu trả lời thực tế - mã hóa nó bằng thuật toán đối xứng đơn giản, bảo vệ khóa mã hóa bằng ACL mạnh và tốt nhất là DPAPI hoặc tương tự, ghi lại và yêu cầu khách hàng (một người đủ cao cấp đưa ra quyết định đó) nó