Câu hỏi Tôi nên tiếp cận về mặt đạo đức lưu trữ mật khẩu người dùng để truy xuất bản rõ bằng văn bản sau này như thế nào?


Khi tôi tiếp tục xây dựng ngày càng nhiều trang web và ứng dụng web, tôi thường được yêu cầu lưu trữ mật khẩu của người dùng theo cách họ có thể truy xuất nếu / khi người dùng gặp sự cố (hoặc gửi email tới liên kết mật khẩu đã quên, dẫn họ qua điện thoại, vv) Khi tôi có thể chiến đấu cay đắng chống lại thực hành này và tôi thực hiện rất nhiều chương trình 'bổ sung' để đặt lại mật khẩu và hỗ trợ quản trị có thể mà không lưu trữ mật khẩu thực của họ.

Khi tôi không thể chống lại nó (hoặc không thể thắng) thì tôi luôn mã hóa mật khẩu theo cách nào đó, ít nhất, không được lưu trữ dưới dạng văn bản thuần túy trong cơ sở dữ liệu - mặc dù tôi biết rằng nếu DB của tôi bị tấn công nó sẽ không mất nhiều thời gian cho thủ phạm để crack mật khẩu, vì vậy mà làm cho tôi khó chịu.

Trong một thế giới hoàn hảo, mọi người sẽ cập nhật mật khẩu thường xuyên và không sao chép chúng trên nhiều trang web khác nhau - thật không may tôi biết nhiều người có cùng mật khẩu công việc / nhà / email / ngân hàng và thậm chí còn tự do trao cho tôi khi họ cần trợ giúp. Tôi không muốn là người chịu trách nhiệm về sự sụp đổ tài chính của họ nếu các quy trình bảo mật DB của tôi không thành công vì một lý do nào đó.

Về mặt đạo đức và đạo đức, tôi cảm thấy có trách nhiệm bảo vệ những gì có thể, đối với một số người dùng, sinh kế của họ ngay cả khi họ đang đối xử với nó với sự tôn trọng ít hơn nhiều. Tôi chắc chắn rằng có nhiều con đường để tiếp cận và tranh luận được thực hiện cho việc băm muối và các tùy chọn mã hóa khác nhau, nhưng có một 'thực hành tốt nhất' duy nhất khi bạn phải lưu trữ chúng? Trong hầu hết các trường hợp, tôi đang sử dụng PHP và MySQL nếu điều đó tạo ra bất kỳ sự khác biệt nào trong cách tôi xử lý các chi tiết cụ thể.

Thông tin bổ sung cho Bounty

Tôi muốn làm rõ rằng tôi biết đây không phải là điều bạn muốn làm và rằng trong hầu hết các trường hợp, việc từ chối làm điều đó là tốt nhất. Tôi, tuy nhiên, không tìm kiếm một bài giảng về thành tích của việc tiếp cận này tôi đang tìm kiếm các bước tốt nhất để có nếu bạn làm theo cách tiếp cận này.

Trong một lưu ý dưới đây tôi đã chỉ ra rằng các trang web hướng về phía người cao tuổi, tinh thần thách thức, hoặc rất trẻ có thể trở nên khó hiểu cho mọi người khi họ được yêu cầu thực hiện một thói quen khôi phục mật khẩu an toàn. Mặc dù chúng ta có thể thấy nó đơn giản và trần tục trong những trường hợp đó, một số người dùng cần sự hỗ trợ thêm về việc có công nghệ dịch vụ giúp họ vào hệ thống hoặc gửi email / hiển thị trực tiếp cho họ.

Trong các hệ thống như vậy, tỷ lệ tiêu hao từ những nhân khẩu học này có thể làm cho ứng dụng trở nên khó khăn nếu người dùng không được cấp hỗ trợ truy cập này, vì vậy hãy trả lời với thiết lập như vậy.

Nhờ mọi người

Đây là một câu hỏi thú vị với rất nhiều cuộc tranh luận và tôi đã rất thích nó. Cuối cùng, tôi đã chọn một câu trả lời rằng cả hai vẫn giữ an toàn mật khẩu (tôi sẽ không phải giữ văn bản thuần hoặc mật khẩu có thể phục hồi được), mà còn làm cho cơ sở người dùng tôi chỉ định đăng nhập vào hệ thống mà không có những hạn chế lớn mà tôi đã tìm thấy khôi phục mật khẩu bình thường.

Như mọi khi, có khoảng 5 câu trả lời mà tôi muốn đánh dấu là đúng vì các lý do khác nhau, nhưng tôi phải chọn câu trả lời hay nhất - tất cả các câu hỏi còn lại đều có +1. Cảm ơn mọi người!

Ngoài ra, cảm ơn tất cả mọi người trong cộng đồng Stack đã bỏ phiếu cho câu hỏi này và / hoặc đánh dấu nó là mục yêu thích. Tôi nhận được 100 phiếu bầu như một lời khen và hy vọng rằng cuộc thảo luận này đã giúp một người khác với cùng một mối quan tâm mà tôi đã có.


1346
2018-02-17 19:54


gốc


Tôi nghĩ anh ấy biết rằng nó không tốt. Anh ấy vẫn đang tìm kiếm giải pháp tốt nhất theo các yêu cầu đã nêu. - stefanw
Vào cuối ngày tất cả các bạn sẽ làm là cẩn thận thực hiện một lỗ hổng có thể tránh được. - rook
@ Michael Brooks - Tôi muốn bạn biết rằng tôi hoàn toàn đồng ý với CWE-257 và rất thích chỉ trích dẫn nguyên văn mỗi lần tôi được yêu cầu làm cho mật khẩu có thể khôi phục được dưới dạng văn bản thuần túy. Tuy nhiên, trên thực tế, khách hàng và người dùng hiếm khi quan tâm đến các quy định của NIST và chỉ muốn tôi làm điều đó. 90% thời gian tôi có thể thuyết phục họ bằng cách khác nhưng trong 10% thời gian khi tôi không thể cố gắng xác định hành động tốt nhất - trong những trường hợp đó, CWE-257 là tro trong tay tôi (thật không may). - Shane
@AviD: "Giá trị thấp" của hệ thống hoàn toàn không mang về vấn đề này bởi vì mọi người sử dụng lại mật khẩu của họ. Tại sao mọi người không thể hiểu được sự thật đơn giản này? Nếu bạn bẻ khóa mật khẩu trên một số hệ thống "giá trị thấp", bạn có thể sẽ có một số mật khẩu hợp lệ cho các hệ thống "giá trị cao" khác. - Aaronaught
Một điểm khác cũng đã được làm sáng tỏ, mà tôi vừa đề cập trong dòng bình luận cho câu trả lời của tôi: Làm thế nào để bạn biết rằng người yêu cầu những yêu cầu này là đáng tin cậy? Điều gì sẽ xảy ra nếu lý do "khả năng sử dụng" chỉ là một mặt nạ che giấu một ý định thực sự để ăn cắp mật khẩu tại một thời điểm nào đó trong tương lai? Naiveté của bạn có thể chỉ có chi phí khách hàng và cổ đông hàng triệu. Các chuyên gia bảo mật phải lặp lại điều này bao nhiêu lần trước khi cuối cùng nó chìm vào: Các mối đe dọa bảo mật phổ biến nhất và nghiêm trọng nhất luôn là NỘI BỘ. - Aaronaught


Các câu trả lời:


Làm thế nào về cách tiếp cận khác hoặc góc tại vấn đề này? Hỏi tại sao mật khẩu được yêu cầu phải ở dạng văn bản thuần túy: nếu nó để người dùng có thể lấy lại mật khẩu, thì nghiêm túc nói rằng bạn không thực sự cần lấy lại mật khẩu mà họ đã đặt (họ không nhớ nó là gì), bạn cần có khả năng cung cấp cho họ mật khẩu co thể sử dụng.

Hãy suy nghĩ về nó: nếu người dùng cần lấy lại mật khẩu, đó là vì họ đã quên nó. Trong trường hợp đó, mật khẩu mới chỉ tốt bằng mật khẩu cũ. Tuy nhiên, một trong những hạn chế của các cơ chế đặt lại mật khẩu phổ biến được sử dụng ngày nay là mật khẩu được tạo ra trong một hoạt động đặt lại thường là một loạt các ký tự ngẫu nhiên, do đó người dùng khó có thể nhập chính xác trừ khi chúng sao chép-n- dán. Đó có thể là một vấn đề đối với người dùng máy tính ít hiểu biết hơn.

Một cách xung quanh vấn đề đó là cung cấp mật khẩu được tạo tự động có ít văn bản ngôn ngữ tự nhiên hơn. Mặc dù các chuỗi ngôn ngữ tự nhiên có thể không có entropy mà một chuỗi các ký tự ngẫu nhiên có cùng độ dài, nhưng không có gì nói mật khẩu được tạo tự động của bạn chỉ cần có 8 (hoặc 10 hoặc 12 ký tự). Nhận cụm từ mật khẩu được tạo tự động entropy cao bằng cách ghép các từ ngẫu nhiên lại với nhau (để lại khoảng trống giữa chúng, vì vậy chúng vẫn có thể nhận ra và có thể đánh máy được bởi bất kỳ ai có thể đọc). Sáu từ ngẫu nhiên có độ dài khác nhau có thể dễ dàng hơn để gõ chính xác và tin cậy hơn 10 ký tự ngẫu nhiên, và chúng có thể có entropy cao hơn. Ví dụ, entropy của mật khẩu 10 ký tự được vẽ ngẫu nhiên từ chữ hoa, chữ thường, chữ số và 10 dấu chấm câu (với tổng số 72 ký hiệu hợp lệ) sẽ có entropy là 61,7 bit. Sử dụng từ điển 7776 từ (như Diceware sử dụng) có thể được chọn ngẫu nhiên cho một cụm từ mật khẩu 6 từ, cụm từ mật khẩu sẽ có một entropy 77.4 bit. Xem Diceware FAQ để biết thêm thông tin.

  • một cụm từ mật khẩu với khoảng 77 bit entropy: "thừa nhận văn xuôi bùng phát sự tinh tế cấp tính"

  • mật khẩu với khoảng 74 bit entropy: "K: & $ R ^ tt ~ qkD"

Tôi biết tôi thích gõ cụm từ, và với copy-n-paste, cụm từ này cũng không kém dễ dàng khi sử dụng mật khẩu đó, vì vậy không mất mát ở đó. Tất nhiên nếu trang web của bạn (hoặc bất kỳ tài sản được bảo vệ nào) không cần 77 bit entropy cho cụm mật khẩu được tạo tự động, hãy tạo ít từ hơn (tôi chắc chắn rằng người dùng của bạn sẽ đánh giá cao).

Tôi hiểu các lập luận rằng có những tài sản được bảo vệ bằng mật khẩu thực sự không có giá trị cao, do đó việc vi phạm mật khẩu có thể không phải là kết thúc của thế giới. Ví dụ, tôi có lẽ sẽ không quan tâm nếu 80% mật khẩu tôi sử dụng trên các trang web khác nhau đã bị vi phạm: tất cả những gì có thể xảy ra là ai đó gửi spam hoặc đăng bài dưới tên của tôi trong một thời gian. Điều đó sẽ không tuyệt vời, nhưng không phải là họ sẽ đột nhập vào tài khoản ngân hàng của tôi. Tuy nhiên, với thực tế là nhiều người sử dụng cùng một mật khẩu cho trang web diễn đàn của họ như họ làm cho tài khoản ngân hàng của họ (và có lẽ là cơ sở dữ liệu an ninh quốc gia), tôi nghĩ tốt nhất là nên xử lý ngay cả những mật khẩu 'có giá trị thấp' - có thể phục hồi.


1039
2018-02-28 08:16



+1 cho cụm mật khẩu, hiện có vẻ như cung cấp sự cân bằng tốt nhất về sức mạnh mật khẩu và thu hồi người dùng. - Aaronaught
Ngoài ra, bạn có thể tạo một câu đầy đủ, ví dụ: <Adjective> <danh từ> là <verb> <adverb>. Con mèo xanh đang nhảy một cách dữ dội. có danh sách cho các danh mục. với 1024 lựa chọn cho mỗi bạn có 40 bit entropy. - Dominik Weber
+1 để xem xét sử dụng lại mật khẩu là một vấn đề quan trọng để tránh - lurscher
"Hãy suy nghĩ về nó - nếu người dùng cần lấy lại mật khẩu, đó là bởi vì họ đã quên nó" - không nhất thiết phải đúng! Tôi thường muốn lấy mật khẩu của mình vì tôi đang ở trên máy tính xách tay, và tôi BIẾT máy của tôi ở nhà có mật khẩu của tôi được lưu trữ, hoặc nó được viết ở đâu đó an toàn, và tôi không muốn phá vỡ nó bằng cách phát hành một cái mới . - joachim
Câu hỏi có điểm cao nhất trên trang web bảo mật CNTT SE mới đề cập đến tính hợp lệ của phép tính entropy này. (Vâng, về mặt kỹ thuật, nó đề cập đến xkcd mà @Pieter liên kết.) - Pops


Hãy tưởng tượng ai đó đã ủy nhiệm một tòa nhà lớn được xây dựng - một quán bar, giả sử - và cuộc trò chuyện sau đây diễn ra:

Kiến trúc sư:  Đối với một tòa nhà có kích thước và công suất này, bạn sẽ cần thoát hiểm ở đây, tại đây và tại đây.
Khách hàng:  Không, đó là quá phức tạp và tốn kém để duy trì, tôi không muốn bất kỳ cửa bên hoặc cửa sau.
Kiến trúc sư:  Thưa ông, các lối thoát hiểm không phải là tùy chọn, chúng được yêu cầu theo mã lửa của thành phố.
Khách hàng:  Tôi không trả tiền cho bạn để tranh cãi. Chỉ cần làm những gì tôi hỏi.

Liệu các kiến ​​trúc sư sau đó hỏi làm thế nào để xây dựng một cách đạo đức tòa nhà này mà không có lối thoát hiểm?

Trong ngành xây dựng và kỹ thuật, cuộc trò chuyện có nhiều khả năng kết thúc như sau:

Kiến trúc sư:  Tòa nhà này không thể được xây dựng mà không có lối thoát hiểm. Bạn có thể đi đến bất kỳ chuyên gia được cấp phép khác và anh ấy sẽ cho bạn biết điều tương tự. Tôi đi ngay bây giờ đây; gọi lại cho tôi khi bạn sẵn sàng hợp tác.

Lập trình máy tính có thể không phải là có giấy phép nghề nghiệp, nhưng mọi người thường có vẻ tự hỏi tại sao nghề nghiệp của chúng tôi không nhận được sự tôn trọng giống như một kỹ sư dân sự hoặc cơ khí - tốt, không nhìn xa hơn. Những nghề đó, khi yêu cầu rác thải (hoặc hết sức nguy hiểm), sẽ đơn giản từ chối. Họ biết nó không phải là một cái cớ để nói, "ừm, tôi đã làm hết sức mình, nhưng anh ấy khăng khăng, và tôi phải làm những gì anh ấy nói." Họ có thể mất giấy phép vì lý do đó.

Tôi không biết bạn hay khách hàng của bạn là một phần của bất kỳ công ty giao dịch công khai nào, nhưng lưu trữ mật khẩu trong bất kỳ biểu mẫu có thể khôi phục nào cũng sẽ khiến bạn thất bại trong một số loại kiểm tra bảo mật khác nhau. Vấn đề không phải là khó khăn đối với một số "hacker" có quyền truy cập vào cơ sở dữ liệu của bạn để khôi phục mật khẩu. Phần lớn các mối đe dọa bảo mật là nội bộ.  Những gì bạn cần để bảo vệ chống lại là một số nhân viên bất mãn đi bộ với tất cả các mật khẩu và bán chúng cho nhà thầu cao nhất. Sử dụng mã hóa không đối xứng và lưu trữ khóa riêng trong một cơ sở dữ liệu riêng biệt hoàn toàn không có gì để ngăn chặn kịch bản này; sẽ luôn có người nào với quyền truy cập vào cơ sở dữ liệu riêng tư và đó là một nguy cơ bảo mật nghiêm trọng.

Không có cách nào có đạo đức hoặc có trách nhiệm để lưu trữ mật khẩu dưới dạng có thể khôi phục được. Giai đoạn.


593
2018-02-18 16:05



@ Aaronaught - Tôi nghĩ đó là một điểm công bằng và hợp lệ, nhưng hãy để tôi xoay điều đó với bạn. Bạn đang làm việc trên một dự án cho một công ty như một nhân viên và ông chủ của bạn nói 'đây là một yêu cầu của hệ thống của chúng tôi' (vì lý do gì). Bạn có bỏ đi công việc đầy sự phẫn nộ ngay chính không? Tôi biết rằng có nghĩa vụ khi tôi hoàn toàn kiểm soát trách nhiệm - nhưng nếu một công ty chọn rủi ro thất bại của kiểm toán hoặc trách nhiệm thì tôi có phải hy sinh công việc của mình để chứng minh một điểm hay tôi tìm kiếm BEST và cách SAFEST để làm những gì họ nói? Chỉ cần chơi ủng hộ của quỷ .. - Shane
Tôi không phải là luật sư, nhưng hãy xem xét điều này. Nếu giám sát của bạn ra lệnh cho bạn làm điều gì đó chống lại lợi ích của công ty, chẳng hạn như bằng cách phơi bày chúng với trách nhiệm dễ dàng tránh né, đó có phải là công việc của bạn để vâng lời hoặc từ chối lịch sự không? Vâng, họ là sếp của bạn, nhưng họ có một ông chủ của riêng họ, ngay cả khi đó là các nhà đầu tư. nếu bạn không đi qua đầu của họ, người đứng đầu sẽ lăn khi lỗ hổng bảo mật của bạn được khai thác? Chỉ cần một cái gì đó để xem xét. - Steven Sudit
Các nhà phát triển luôn cố gắng nói rằng công việc của chúng tôi khó khăn như thế nào nhiều hơn những người khác bởi vì chúng tôi nhận được các yêu cầu về rác thải thay đổi mọi lúc. Vâng, đây là một ví dụ hoàn hảo về lý do tại sao; nghề nghiệp của chúng tôi rất cần một xương sống. Nghề nghiệp của chúng tôi rất cần có thể nói "không, đây không phải là yêu cầu có thể chấp nhận được, đây không phải là điều tôi có thể phát triển với đức tin tốt, bạn có thể là khách hàng / chủ nhân của tôi nhưng tôi có trách nhiệm nghề nghiệp đối với khách hàng và công chúng, và nếu bạn muốn làm điều này thì bạn sẽ phải tìm nơi khác. " - Aaronaught
@sfussenegger: Bạn không cần biết nền. Nó không thể chấp nhận được. Bạn đang giả định rằng khách hàng là 100% đáng tin cậy - điều gì sẽ xảy ra nếu anh ấy yêu cầu yêu cầu này một cách cụ thể để anh ta có thể tạo ra mật khẩu sau này? Bảo mật là một trong số ít các mục phát triển là khắc trên đá. Có một số điều bạn không làm và lưu trữ mật khẩu có thể phục hồi là mười trong số đó. - Aaronaught
OK, chúng ta hãy đánh giá rủi ro, ngay tại đây và ngay bây giờ. "Nếu bạn lưu trữ mật khẩu dưới dạng có thể phục hồi, bạn đang tạo ra một nguy cơ không đáng kể mật khẩu bị đánh cắp. Nó cũng có khả năng là ít nhất một số người dùng sẽ sử dụng cùng một mật khẩu cho tài khoản e-mail và tài khoản ngân hàng của họ. và tài khoản ngân hàng bị cạn kiệt, nó có thể sẽ làm tiêu đề, không ai có thể làm ăn với bạn một lần nữa, và bạn có thể sẽ bị kiện ra khỏi sự tồn tại. " Chúng ta có thể cắt crap ngay bây giờ không? Thực tế là bạn đã mang từ "Đức quốc xã" vào điều này cho thấy rõ ràng rằng bạn không có lý do. - Aaronaught


Bạn có thể mã hóa mật khẩu + muối bằng khóa công cộng. Đối với thông tin đăng nhập, hãy kiểm tra xem giá trị đã lưu có bằng giá trị được tính từ đầu vào của người dùng + muối hay không. Nếu có thời gian, khi mật khẩu cần được khôi phục trong bản rõ, bạn có thể giải mã thủ công hoặc bán tự động bằng khóa riêng. Khóa riêng có thể được lưu trữ ở nơi khác và có thể được mã hóa thêm một cách đối xứng (mà sẽ cần một tương tác của con người để giải mã mật khẩu sau đó).

Tôi nghĩ điều này thực sự tương tự như cách Đại lý khôi phục Windows công trinh.

  • Mật khẩu được lưu trữ được mã hóa
  • Mọi người có thể đăng nhập mà không cần giải mã thành văn bản thô
  • Mật khẩu có thể được phục hồi thành văn bản thuần túy, nhưng chỉ với một khóa riêng, có thể được lưu trữ bên ngoài hệ thống (trong một ngân hàng an toàn, nếu bạn muốn).

206
2018-02-17 20:07



-1 mật khẩu không bao giờ nên được "mã hóa" Nó là một vi phạm của CWE-257 cwe.mitre.org/data/definitions/257.html - rook
1. Câu hỏi đã nêu rằng mật khẩu có thể được phục hồi thành văn bản rõ ràng, vì vậy đây là một yêu cầu. 2. Tôi đang sử dụng mã hóa bất đối xứng ở đây và không mã hóa đối xứng. Chìa khóa để giải mã là không cần thiết cho các hoạt động hàng ngày và có thể được giữ trong một ngân hàng an toàn. Đối số trong liên kết là hợp lệ, nhưng không áp dụng cho trường hợp này. - stefanw
Đúng, nhưng bạn có thể đồng ý rằng đưa ra các yêu cầu này là cách có trách nhiệm nhất để làm điều đó? Bạn có thể đánh tôi cả ngày với CWE-257 của bạn, nó sẽ không thay đổi vấn đề thú vị của việc lưu trữ và làm việc an toàn với các thông tin và có thể khôi phục chúng về dạng ban đầu của chúng nếu cần. - stefanw
Windows Recovery Agent cũng là một ví dụ nghèo ở đây, vì nó đề cập đến mã hóa thực tế, không phải quản lý mật khẩu. Khóa mã hóa là không phải giống như mật khẩu; các quy tắc và thực hành xung quanh mỗi hoàn toàn khác nhau. Mã hóa và xác thực không giống nhau. Mã hóa dành cho riêng tư - chìa khóa được sử dụng để bảo vệ dữ liệu. Xác thực là dành cho danh tính, nơi chìa khóa là dữ liệu (nó là một hệ số trong quá trình xác thực). Tôi lặp lại, mã hóa và xác thực không giống nhau. Bạn không thể áp dụng một cách hợp lệ các nguyên tắc của cái này đến cái kia. - Aaronaught
+1 Đâu là điểm nhấn khăng khăng ám chỉ CWE-257? Đó là điểm yếu (CWE), không phải là lỗ hổng (CVE). So sánh các mật khẩu có thể phục hồi với tràn bộ đệm là so sánh táo và cam. Đơn giản chỉ cần chắc chắn rằng khách hàng hiểu được vấn đề (hãy để anh ta ký một cái gì đó mà nói như vậy - nếu không anh ta có thể không nhớ bất cứ điều gì nếu trong câu hỏi) và đi trước. Ngoài ra, các biện pháp an ninh bắt buộc phụ thuộc vào giá trị của hệ thống và nguy cơ tiềm tàng của một cuộc tấn công. Nếu kẻ tấn công thành công chỉ có thể hủy một số đăng ký bản tin, không có lý do gì để tranh luận về bất kỳ vấn đề nào. - sfussenegger


Đừng bỏ cuộc. Vũ khí bạn có thể sử dụng để thuyết phục khách hàng của mình là không thể chối bỏ. Nếu bạn có thể tái tạo mật khẩu người dùng thông qua bất kỳ cơ chế nào, bạn đã của chúng khách hàng là cơ chế không từ chối pháp lý và họ có thể từ chối bất kỳ giao dịch nào phụ thuộc vào mật khẩu đó, bởi vì không có cách nào nhà cung cấp chứng minh rằng họ không tạo lại mật khẩu và tự đặt giao dịch. Nếu mật khẩu được lưu trữ chính xác dưới dạng bản dịch chứ không phải là bản mã, điều này là không thể, do đó, hoặc ứng dụng khách cuối thực thi giao dịch hoặc vi phạm nghĩa vụ chăm sóc của anh ta.r.t. Mật khẩu. Trong cả hai trường hợp mà rời khỏi trách nhiệm với anh ta. Tôi đã làm việc trong những trường hợp mà số tiền đó sẽ lên đến hàng trăm triệu đô la. Không phải cái gì bạn muốn nhận được sai.


134
2018-02-18 09:59



Nhật ký máy chủ web không được tính trong một tòa án? Hoặc trong trường hợp này, chúng cũng được giả định là giả mạo? - Vinko Vrsalovic
@ Vinko Vrsalovic, nhật ký máy chủ web NÊN NÊN đếm ở tòa án, để làm như vậy bạn cần phải chứng minh không từ chối, bằng chứng về tính xác thực, chuỗi bằng chứng, v.v ... mà nhật ký máy chủ web rõ ràng là không. - AviD
Chính xác. Nhà cung cấp phải chứng minh rằng chỉ có khách hàng có thể đã thực hiện giao dịch đó. Nhật ký máy chủ web không làm điều đó. - user207421
Không phải tất cả mật khẩu đều thực sự cần thiết cho "giao dịch", vì vậy để nói. Giả sử trang web dành cho việc phát triển danh sách đánh dấu trang web. Trong trường hợp này, giới hạn trách nhiệm (thường được gọi trong T & C khi đăng ký vào trang web) bằng không, vì không có giao dịch tài chính. Nếu trang web không có hành động nào ảnh hưởng đến người khác thì tối đa, dữ liệu bị mất cho người dùng bị tấn công. Công ty được bảo vệ bởi T & C's. - Sablefoste
@Sablefoste Trên trang web đó. Nếu người dùng sử dụng cùng một mật khẩu ở nơi khác, bạn đang tạo ra một nguy cơ rò rỉ thông tin cá nhân của mình. Nếu bạn không bao giờ tham gia vào thực tế, bạn không thể gây ra vấn đề. - user207421


Bạn không thể lưu trữ mật khẩu một cách hợp pháp để truy xuất lại bản rõ. Nó đơn giản như vậy. Thậm chí Jon Skeet cũng không thể lưu trữ mật khẩu một cách hợp pháp để truy xuất lại bản rõ. Nếu người dùng của bạn có thể truy xuất mật khẩu bằng văn bản thuần túy hoặc bằng cách khác, thì có khả năng một hacker có thể tìm thấy lỗ hổng bảo mật trong mã của bạn. Và đó không chỉ là mật khẩu của một người dùng bị xâm phạm, nhưng Tất cả bọn họ.

Nếu khách hàng của bạn có vấn đề với điều đó, hãy nói với họ rằng lưu trữ mật khẩu có thể khôi phục được là trái luật. Ở Anh, ở bất kỳ mức nào, Đạo luật bảo vệ dữ liệu năm 1998 (cụ thể, Phụ lục 1, Phần II, Đoạn 9) yêu cầu các bộ điều khiển dữ liệu sử dụng các biện pháp kỹ thuật thích hợp để giữ an toàn cho dữ liệu cá nhân. tác hại có thể được gây ra nếu dữ liệu bị xâm phạm - điều này có thể đáng kể đối với những người dùng chia sẻ mật khẩu giữa các trang web. Nếu họ vẫn gặp khó khăn khi mò mẫm thực tế rằng đó là vấn đề, hãy chỉ cho họ một số ví dụ thực tế, chẳng hạn như cái này.

Cách đơn giản nhất để cho phép người dùng khôi phục thông tin đăng nhập là gửi email cho họ liên kết một lần tự động đăng nhập và đưa họ thẳng đến trang nơi họ có thể chọn mật khẩu mới. Tạo một mẫu thử nghiệm và hiển thị nó trong hành động cho họ.

Dưới đây là một số bài đăng trên blog mà tôi đã viết về chủ đề này:

Cập nhật: chúng tôi hiện đang bắt đầu thấy các vụ kiện và truy tố chống lại các công ty không bảo mật mật khẩu của người dùng của họ một cách chính xác. Thí dụ: LinkedIn tát với vụ kiện hành động hạng 5 triệu đô la; Sony bị phạt 250.000 bảng so với bản hack dữ liệu PlayStation. Nếu tôi nhớ chính xác, LinkedIn thực sự mã hóa mật khẩu của người dùng, nhưng mã hóa nó đang sử dụng quá yếu để có hiệu quả.


95
2018-02-23 15:20



@jimmycakes - Đây là một điều tốt để làm trên một hệ thống bảo mật thấp, nhưng nếu bạn đang lưu trữ bất kỳ dữ liệu có giá trị cao thì bạn phải giả định rằng email của người đó đã bị xâm phạm và gửi cho họ một liên kết đăng nhập trực tiếp làm tổn hại đến hệ thống của bạn. 1 để trả lời câu hỏi của tôi với một giải pháp khả thi, nhưng chỉ ra một lỗ hổng trong logic nói chung. Tôi không muốn Payppal gửi liên kết đăng nhập trực tiếp EVER. Nghe có vẻ hoang tưởng nhưng tôi luôn cho rằng tài khoản email của tôi bị hỏng - nó giúp tôi thành thật. ;) - Shane
Tuyệt đối - tôi hy vọng ngân hàng của mình ít nhất sẽ gọi điện cho tôi và xác minh danh tính của tôi trước khi cho phép tôi đặt lại (không phải khôi phục) mật khẩu của tôi. Những gì tôi đã nêu ở đây là tiêu chuẩn tối thiểu tuyệt đối về bảo mật mật khẩu mà tôi mong đợi từ bất kỳ trang web nào, ở bất kỳ đâu. - jammycakes
Bỏ qua các ngân hàng hoặc paypal những người sẽ không có những hạn chế bạn đặt anyway; Nếu bạn cho rằng email của họ bị xâm phạm, thì phương thức trực tuyến nào có thể? Nếu bạn gửi email một mật khẩu được tạo, thì mật khẩu đó sẽ an toàn hơn thế nào? - Peter Coulton
Tôi không nói về việc lấy mật khẩu của một cá nhân, tôi đang nói về việc lấy nhiều mật khẩu từ một cơ sở dữ liệu. Nếu một hệ thống lưu trữ mật khẩu có thể khôi phục về văn bản thuần túy, một hacker có khả năng viết một kịch bản để trích xuất tất cả các mật khẩu từ cơ sở dữ liệu của bạn. - jammycakes
Tôi đang tự hỏi về việc gửi liên kết / mật khẩu trong email, đi qua mạng ở dạng đơn giản thông qua các nút mạng không xác định ... - Jakub


Sau khi đọc phần này:

Trong một lưu ý dưới đây, tôi đã chỉ ra rằng   các trang web hướng về phía   người già, tinh thần thách thức, hoặc rất   trẻ có thể trở nên khó hiểu với mọi người   khi họ được yêu cầu thực hiện   thói quen khôi phục mật khẩu an toàn.   Mặc dù chúng ta có thể thấy nó đơn giản và   nhàm chán trong những trường hợp đó, một số người dùng cần   sự hỗ trợ thêm của một trong hai   một dịch vụ công nghệ giúp họ vào   hoặc gửi email / hiển thị   trực tiếp với họ.

Trong các hệ thống như vậy, tỷ lệ tiêu hao   từ những nhân khẩu học này có thể chơi   ứng dụng nếu người dùng không   với mức hỗ trợ truy cập này,   vì vậy hãy trả lời với thiết lập như vậy   lí trí.

Tôi đang tự hỏi liệu có bất kỳ yêu cầu nào trong số này yêu cầu một hệ thống mật khẩu có thể truy xuất được hay không. Ví dụ: Dì Mabel gọi điện và nói "Chương trình internet của bạn không hoạt động, tôi không biết mật khẩu của mình". "OK" nói rằng dịch vụ khách hàng bay không người lái "hãy để tôi kiểm tra một vài chi tiết và sau đó tôi sẽ cung cấp cho bạn mật khẩu mới. Khi bạn đăng nhập tiếp theo nó sẽ hỏi bạn có muốn giữ lại mật khẩu đó hoặc thay đổi nó thành một thứ bạn có thể nhớ dễ dàng hơn không. "

Sau đó, hệ thống được thiết lập để biết khi nào thiết lập lại mật khẩu đã xảy ra và hiển thị thông báo "bạn muốn giữ mật khẩu mới hoặc chọn mật khẩu mới".

Làm thế nào là tồi tệ hơn cho ít PC-biết chữ hơn là được nói với mật khẩu cũ của họ? Và trong khi người phục vụ khách hàng có thể bị lừa dối, bản thân cơ sở dữ liệu vẫn an toàn hơn nhiều trong trường hợp nó bị vi phạm.

Bình luận về những gì xấu về đề nghị của tôi và tôi sẽ đề xuất một giải pháp thực sự làm những gì bạn ban đầu muốn.


55
2018-02-25 11:27



@ john - Tôi nghĩ rằng đó là một giải pháp hoàn hảo khả thi. Chuẩn bị để có được flamed trên các mối đe dọa nội bộ mặc dù! Bạn biết đấy, nếu tôi làm điều này với một thiết lập lại mật khẩu trung gian (công nghệ đặt mật khẩu theo cách thủ công như một mesaure tạm thời và yêu cầu Mabel gõ 1234 làm mật khẩu của mình) thì nó có thể hoạt động tốt trên một hệ thống không chứa dữ liệu quan trọng. Nếu đó là một môi trường bảo mật cao, mặc dù chúng tôi có vấn đề khi dịch vụ lưu trữ có thể đặt mật khẩu của CEO thành 1234 và đăng nhập trực tiếp. Không có giải pháp hoàn hảo nhưng giải pháp này hoạt động trong rất nhiều trường hợp. (+1) - Shane
Tôi chỉ nhận thấy câu trả lời này. @ Shane, tôi không hiểu tại sao bạn dự đoán cháy về "các mối đe dọa nội bộ". Khả năng thay đổi mật khẩu không phải là điểm yếu đáng chú ý; vấn đề là khả năng khám phá mật khẩu có khả năng được sử dụng cho khác dịch vụ - e-mail của cô, ngân hàng của cô, các trang web mua sắm trực tuyến của cô đã lưu trữ thông tin CC của cô. Điểm yếu đó không được biểu lộ ở đây; nếu Bob đặt lại mật khẩu của Mabel và thông báo cho cô ấy qua điện thoại, mật khẩu đó không cấp cho anh ấy quyền truy cập vào bất kỳ tài khoản nào khác của cô ấy. Tôi sẽ, tuy nhiên, lực lượng thay vì "đề xuất" đặt lại mật khẩu khi đăng nhập. - Aaronaught
@Aaronaught - Tôi thấy quan điểm của bạn, nhưng những gì tôi nghĩ đến là ngay cả khi những người dịch vụ khách hàng bị khóa trong một số khu vực nhất định của hệ thống (chẳng hạn như bảng lương, kế toán, vv) và cho phép họ đặt mật khẩu trực tiếp một vấn đề an ninh trong và của chính nó. Tôi thấy quan điểm của bạn mặc dù loại hệ thống tôi hỏi câu hỏi này về phần lớn là từ một hệ thống kế toán nội bộ. Có lẽ chúng ta có thể có một cuộc thảo luận hoàn toàn khác về các hệ thống nội bộ độc quyền và bảo mật mật khẩu trong đó. - Shane
@ Shane: Sau đó, câu hỏi làm cho cảm giác ít hơn. Tôi cho rằng bạn muốn ai đó đọc mật khẩu qua điện thoại. Nếu bạn muốn e-mail cho người dùng mật khẩu của họ thông qua một số hệ thống tự phục vụ tự động thì bạn cũng có thể phân phối hoàn toàn với mật khẩu vì nó được "bảo vệ" với thứ gì đó yếu hơn nhiều. Có thể bạn cần cụ thể hơn về chính xác loại kịch bản khả năng sử dụng mà bạn đang cố gắng hỗ trợ. Có lẽ phân tích đó sau đó sẽ cho bạn thấy rằng các mật khẩu có thể phục hồi thậm chí không cần thiết. - Aaronaught
Mã do người hỗ trợ cung cấp không phải là mật khẩu mới. Nó chỉ có thể là mã một lần mở khóa chức năng đặt lại mật khẩu. - kgilpin


Michael Brooks đã được khá vocal về CWE-257 - thực tế là bất cứ phương pháp bạn sử dụng, bạn (người quản trị) vẫn có thể khôi phục mật khẩu. Vì vậy, làm thế nào về các tùy chọn này:

  1. Mã hóa mật khẩu bằng của người khác khóa công khai - một số cơ quan bên ngoài. Bằng cách đó bạn không thể tái tạo nó một cách cá nhân, và người dùng sẽ phải đi đến cơ quan bên ngoài đó và yêu cầu khôi phục mật khẩu của họ.
  2. Mã hóa mật khẩu bằng khóa được tạo từ cụm mật khẩu thứ hai. Thực hiện việc mã hóa phía máy khách này và không bao giờ truyền nó vào máy chủ. Sau đó, để khôi phục, hãy thực hiện lại phía máy khách giải mã bằng cách tạo lại khóa từ đầu vào của chúng. Phải thừa nhận rằng, phương pháp này về cơ bản là sử dụng một mật khẩu thứ hai, nhưng bạn luôn có thể yêu cầu họ viết nó xuống, hoặc sử dụng cách tiếp cận câu hỏi bảo mật cũ.

Tôi nghĩ rằng 1. là sự lựa chọn tốt hơn, bởi vì nó cho phép bạn chỉ định một người nào đó trong công ty của khách hàng để giữ khóa riêng. Bạn có thể thêm bảo mật bằng cách chọn chỉ mã hóa và cung cấp các ký tự nhất định từ mật khẩu cho bên thứ ba bên trong để họ có thể crack mật khẩu để đoán nó. Cung cấp các ký tự này cho người dùng, họ có thể sẽ nhớ nó là gì!


42
2018-02-18 13:56



Và, tất nhiên, bạn có thể sử dụng bất kỳ kỹ thuật tách mật để yêu cầu nhiều người từ công ty của bạn để giải mã. Nhưng không ai trong số đó đáp ứng các yêu cầu ban đầu của việc có thể gửi thư cho người dùng mật khẩu của họ hoặc có một số người hỗ trợ điện thoại cấp một chạy bộ đi bộ qua họ đăng nhập. - Christopher Creutzig