Làm thế nào để từ chối cấp quyền truy cập vào mật khẩu cho khách hàng mà không thiếu chuyên nghiệp hay thô lỗ?


8

Giả sử bạn đang tạo một trang web cho khách hàng. Trang web này có đăng ký riêng (kết hợp với OpenID hoặc không). Khách hàng yêu cầu bạn có thể xem mật khẩu mà người dùng đang chọn, với điều kiện là người dùng có thể sẽ sử dụng cùng một mật khẩu trên mỗi trang web.

Nói chung, tôi nói:

  • hoặc là không thể truy xuất mật khẩu, vì chúng không được lưu trữ trong văn bản thuần túy, nhưng được băm,

  • hoặc rằng tôi không có quyền làm điều đó hoặc quản trị viên không thể xem mật khẩu của người dùng mà không cung cấp thêm bất kỳ chi tiết nào.

Cái đầu tiên là sai: ngay cả khi mật khẩu được băm, vẫn có thể bắt và lưu trữ chúng trên mỗi lần đăng nhập (ví dụ: thực hiện một loại kiểm toán kỳ lạ sẽ ghi nhớ không chỉ người dùng nào thành công hoặc thất bại khi đăng nhập, mà còn với mật khẩu nào). Người thứ hai là thô lỗ.

Làm thế nào để từ chối yêu cầu này, mà không phải là không chuyên nghiệp hoặc thô lỗ?


24
Tôi gặp khó khăn ở đây ... Họ đã yêu cầu quyền truy cập vào mật khẩu của người dùng và nêu lý do vì chúng tôi biết rằng họ có khả năng sử dụng mật khẩu trên nhiều trang web ? Tôi thậm chí sẽ không biết làm thế nào để trả lời ... Họ không chỉ là không chuyên nghiệp, chúng ta đang nói về sự gian lận / trộm cắp danh tính ở đây ...
Max

2
Họ đang yêu cầu mật khẩu của riêng họ? Nếu không, sau đó chỉ cần nói với họ rằng sẽ mất thời gian và thông báo cho chính quyền thích hợp. Tùy thuộc vào lĩnh vực bạn đang ở, các luật khác nhau có thể được áp dụng ở đây. Điều nghiêm ngặt nhất mà tôi biết là yêu cầu bạn báo cáo việc này với các cơ quan hữu quan mà không để "khách hàng" biết rằng bạn sẽ làm.
Apoorv Khurasia

1
bạn có thể thích đọc cuộc thảo luận này tại SF: serverfault.com/questions/293217/ cấp (về yêu cầu mật khẩu từ kiểm toán viên bảo mật)
gnat

Câu trả lời:


11

Nói với anh ấy phần đầu tiên. Rằng bạn đang lưu trữ mật khẩu trong một hàm băm. Và tất cả các hệ thống mật khẩu hoạt động theo cách này. Quản trị viên có thể thay đổi mật khẩu, đặt lại mật khẩu, nhưng không thể đọc mật khẩu. Nếu khách hàng của bạn am hiểu về lập trình, họ có thể biết rằng bạn có thể chặn mật khẩu trước khi băm.

Bây giờ chuyển sang phần thứ hai. Trang web có chính sách bảo mật hoặc điều khoản sử dụng. Sử dụng trang web để thu thập mật khẩu sẽ vi phạm hầu hết các chính sách này. Nếu khách hàng khăng khăng thu thập thông tin này, hãy giải thích rằng điều này sẽ khiến trang web của anh ta trở nên vô dụng và là một thị trấn ma nếu cộng đồng không thể tin tưởng vào trang web.

Nếu nó trở nên rõ ràng rằng ý định của họ là đánh cắp mật khẩu. Chạy. Tìm một công việc mới hoặc một hợp đồng mới. Nếu bạn làm việc cho một công ty trong hợp đồng này, hãy nói với họ những gì bạn biết.


Như tôi đã chỉ ra trong chính câu hỏi, tùy thuộc vào lĩnh vực mà bạn đang làm việc (ví dụ như ngân hàng), không tạo ra khoảng cách chính sách đối với sự chú ý của các cơ quan quản lý (ví dụ như Fed) khiến bạn phải chịu trách nhiệm hình sự. Nhiều lĩnh vực có luật tương tự (có thể không quá khắc nghiệt). Vì vậy, chạy và tìm một lời khuyên công việc mới có thể không tốt như vậy sau khi tất cả.
Apoorv Khurasia

Bạn có thể cung cấp một liên kết cho luật này? Điều đó có vẻ như nó sẽ ngăn cản rất nhiều tiếng huýt sáo.
Erik Reppen

@ErikReppen: Tại sao phải chịu trách nhiệm hình sự vì không thổi còi ngăn cản việc thổi còi?
Brian

Bởi vì nếu tôi hiểu chính xác Monster Truck (trong phần trả lời bình luận), bạn phải chịu trách nhiệm cho việc nói với khách hàng rằng bạn đang liên hệ với chính quyền. Nhưng nếu đó là điều đầu tiên bạn nói với họ khi họ đưa ra yêu cầu thì sao? Nó cũng đập vỡ bẫy thông qua proxy. Nếu ai đó đã cảnh báo họ, dẫn đến việc họ ngăn chặn hành vi tội phạm và các liên đoàn đang cố gắng ngăn bạn làm điều đó, thì khác với chính các liên đoàn khuyến khích họ vi phạm pháp luật như thế nào? Thật ngu ngốc khi đặt hậu quả lên những người tố giác vì đã không làm mọi thứ chính xác theo cách họ muốn.
Erik Reppen

3

Trang web có "Tuyên bố quyền riêng tư" không? Và tuyên bố đó có bao gồm một cái gì đó về việc đưa ra "thông tin nhạy cảm" không?

Trong trường hợp đó, tôi có thể nói, "Tôi không được tự do đưa ra thông tin nhạy cảm về người dùng. Điều đó vi phạm rõ ràng tuyên bố quyền riêng tư của chúng tôi!" (Dấu chấm than ở đây rất quan trọng). Nếu bạn không có tuyên bố về quyền riêng tư, tôi cũng sẽ nói như vậy, ngoại trừ câu cuối cùng.

Những người đặt câu hỏi như vậy không nên đưa ra những lý do sai lầm, chẳng hạn như về mặt kỹ thuật là không thể. Họ nên được giáo dục về sự thật, mật khẩu của người dùng là riêng tư và điều đó là sai trái về mặt đạo đức và đạo đức (và có lẽ cũng bất hợp pháp như ai đó đã đề cập) để thu thập chúng từ hệ thống.


+1 vì không đưa ra lý do sai. Tốt hơn là cắt thẳng để đuổi theo bất hợp pháp / phi đạo đức, nơi có liên quan đến đạo đức.
Erik Reppen

2

Chỉ cần nói rằng bạn không muốn thử nghiệm cuộc sống trong tù :) Bởi vì bạn biết những gì họ hỏi bạn, nếu rõ ràng việc sử dụng bất hợp pháp mật khẩu người dùng, sẽ dẫn họ đến nhiều vấn đề lớn. Tôi nghĩ cách tốt nhất là cố gắng dạy họ tại sao thực sự tồi tệ khi làm những việc như vậy.

Nhưng vấn đề thực sự là, imho, thực tế là bạn làm việc cho kẻ trộm trong khi bạn không thích kẻ trộm. Thay vì tìm cách làm thế nào để không quá thô lỗ với những người bạn không thích, sẽ không tốt hơn nếu bạn ngừng làm việc cho họ? Tôi sẽ đề nghị bạn thêm một số điều khoản về những gì bạn chưa sẵn sàng làm trong các hợp đồng tương lai của mình để tránh tình huống đó.

Dù sao thì thực tế là bạn chưa sẵn sàng làm những gì họ yêu cầu bạn làm vì điều đó bất hợp pháp tôn vinh bạn.


1

Tất nhiên bạn muốn trở nên tốt đẹp, bạn có thể chỉ ra rằng yêu cầu này là một yêu cầu bất thường và nó cần phải có sự chấp thuận từ các cơ quan cấp cao hơn. Sẽ thật tốt khi giải thích tác động của hành động này đối với tổ chức và người dùng. Điều này là để đảm bảo rằng bot bạn và khách hàng hoàn toàn hiểu được tình hình. Tất nhiên bạn phải giữ mọi thứ bằng văn bản.

Bạn có thể diễn đạt tình huống trong một tuyên bố chính sách và yêu cầu chủ sở hữu / người quản lý cổ phần chính của hệ thống phê duyệt hoặc từ chối chính sách và sử dụng nó làm tài liệu dự phòng cho phản hồi của bạn đối với yêu cầu. Bạn cũng có thể muốn thêm vào đó một thực tế là người dùng sẽ được thông báo về thực tế rằng mật khẩu của họ không bí mật.

Tất cả là một vấn đề chính sách, không hơn không kém.


2
Đó không chỉ là vấn đề chính sách vì khách hàng rõ ràng muốn đánh cắp mật khẩu. Không có nhà phát triển có thể được yêu cầu là đồng phạm của một điều như vậy. Thật khó để gọi cảnh sát về điều này và có lẽ thật khó để MainMa không thô lỗ nhưng anh ta không thể tuân thủ, bất kể chính sách và ngăn xếp nói gì.
Denys Séguret

@dystroy, tốt, chúng tôi không chắc chắn về vai trò của người yêu cầu thông tin này. Bất cứ điều gì là hợp pháp miễn là có luật để nói nó là. Chúng ta đang ở trong một thế giới mà ngay cả việc giết chóc cũng chính đáng theo luật pháp.
NoChance

0

Chắc chắn bạn chỉ lưu trữ mật khẩu băm nên không thể. Nếu không bạn có vấn đề lớn hơn. Vì vậy, đó là phản ứng chính xác.


1
Tuy nhiên, có một cơ hội trước khi mật khẩu được băm. Trình duyệt gửi mật khẩu đến máy chủ ở dạng văn bản thuần và mã phía máy chủ (mà MainMa chịu trách nhiệm) nhận mật khẩu bằng văn bản thuần túy.
dùng16764

0

Trước tiên tôi nghĩ rằng chúng được mã hóa một chiều, sau đó chuyển sang yêu cầu bằng văn bản (trên giấy tờ) (từ bất kỳ ai chịu trách nhiệm) để tôi có thể trình lên cảnh sát / FBI (hoặc bất cứ điều gì tương đương với đất nước có liên quan) / etc nếu và khi được yêu cầu. Stapple rằng để một bản sao của email theo cả hai hướng, sau đó quả bóng là ở tòa án của họ. Tôi không thể thấy bất kỳ công ty nào liên quan đến yêu cầu này, vì vậy đây có thể là một cá nhân và họ có thể sẽ yêu cầu lại.

Nếu họ đưa cho tôi giấy tờ, thì đó là dữ liệu của họ, yêu cầu của họ, nếu họ vi phạm chính sách bảo mật của chính họ hoặc luật pháp, thì đó là đầu của họ.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.