Băm mật khẩu và hỗ trợ cho người dùng của bạn


10

Gần đây chúng tôi đã chuyển sang một chiến lược lưu trữ mật khẩu tốt hơn, với tất cả những thứ hay ho:

  • Mật khẩu được lưu trữ sau khi đi qua bCrypt
  • Người dùng được gửi một liên kết kích hoạt khi tạo tài khoản để xác nhận quyền sở hữu địa chỉ
  • Quên mật khẩu mà không có câu hỏi bảo mật, một liên kết được gửi đến email của họ.
  • Liên kết hết hạn sau 24 giờ, tại thời điểm đó họ sẽ cần yêu cầu một liên kết mới.
  • Nếu tài khoản được tạo từ nhân viên của chúng tôi, một email sẽ được gửi với mật khẩu mạnh ngẫu nhiên trong đó. Khi đăng nhập, người dùng phải đặt lại thành thứ chúng tôi không biết và đó là bCrypt'd.

Bây giờ điều này phù hợp với "thực tiễn tốt nhất" xung quanh, nhưng điều này đã tăng số lượng yêu cầu hỗ trợ của chúng tôi rất nhiều từ những người dùng thông thường không hiểu tất cả những điều này, họ chỉ muốn đăng nhập.

Chúng tôi thường nhận được yêu cầu từ những người dùng phàn nàn về:

  • Mật khẩu không chính xác (từ mật khẩu mà họ cần đặt lại, họ thường dán nó với một khoảng trắng ở cuối). Họ nói với chúng tôi những gì họ đang sử dụng nhưng chúng tôi không có cách nào nói cho họ biết mật khẩu thực sự của họ là gì.
  • Nói rằng họ không nhận được email chúng tôi gửi cho họ (kích hoạt, đặt lại, v.v.). Đây thường không phải là trường hợp, sau nhiều sự cố, chúng tôi thường phát hiện ra họ đã đánh máy trong email, rằng họ không kiểm tra đúng tài khoản email hoặc đơn giản là nó đã vào thư mục thư rác.

Tất nhiên chúng tôi không thể thử nó cho họ vì chúng tôi không có mật khẩu. Chúng tôi đang ghi lại các lần thử thất bại nhưng chúng tôi cũng xóa mật khẩu họ đã sử dụng vì đó có thể là mật khẩu được sử dụng cho một tài khoản khác và chúng tôi không muốn lưu trữ trong tệp nhật ký văn bản đơn giản. Điều này khiến chúng tôi không có gì nhiều để giúp đỡ họ khi họ báo cáo vấn đề.

Tôi tò mò về cách hầu hết mọi người đối phó với các vấn đề như thế này?


2
Khác với việc mô tả nhiều hơn một chút trong e-mail mà hệ thống của bạn gửi cho người dùng, tôi không thấy những gì bạn có thể làm khác đi trong khi duy trì các thực tiễn tốt nhất. Làm cho bạn muốn bạn chỉ có thể tát người dùng ngu ngốc.
Bernard

1
Mọi người thật ngu ngốc, người dùng của bạn, hơn cả những người khác, tôi không thấy câu hỏi ở đây?

8
Jarrod bạn đang xúc phạm người dùng của bạn. Người ngu ở đây là bạn. Bạn không hiểu trình độ hiểu biết về máy tính của người dùng. Không có người đàn ông xúc phạm, nhưng bạn đang viết phần mềm cho mọi người không phải cho chuyên viên máy tính. Nếu bạn thấy không có câu hỏi nào thì có nghĩa là tất cả những chuyên gia về khả năng sử dụng đó sẽ bị sa thải, bởi vì chúng thực sự không cần thiết. Đó chỉ là vấn đề với "những người ngu ngốc", vì vậy chúng tôi - các nhà phát triển thông minh chỉ cấm họ khỏi web và vấn đề sẽ biến mất :) Nếu ai đó viết một hệ thống mà chỉ có tác giả có thể sử dụng, bạn không thấy vấn đề?
Slawek

2
@Slawek: không, thực sự, mọi người thật ngu ngốc.
Bryan Boettcher

@JarrodRoberson, hầu như không chỉ người dùng của anh ấy - khi giao dịch với các ứng dụng web đối mặt công khai, đó thường là những gì bạn nhận được. Điều đó nói rằng, dù muốn hay không , nó vẫn chiếm các tài nguyên hỗ trợ và là câu hỏi rất hợp lệ.
GrandmasterB

Câu trả lời:


7

Mật khẩu không chính xác (từ mật khẩu mà họ cần đặt lại, họ thường dán nó với một khoảng trắng ở cuối). Họ nói với chúng tôi những gì họ đang sử dụng nhưng chúng tôi không có cách nào nói cho họ biết mật khẩu thực sự của họ là gì.

Có thể sửa chữa bằng cách thay vào đó bao gồm một liên kết với GUID một lần để đăng nhập chúng và buộc họ đặt lại mật khẩu. Đừng ép người dùng sao chép-dán. (Ngoài ra, tại sao không loại bỏ khoảng trắng ở cuối mật khẩu trong biểu mẫu của bạn.)

Nói rằng họ không nhận được email chúng tôi gửi cho họ (kích hoạt, đặt lại, v.v.). Đây thường không phải là trường hợp, sau nhiều sự cố, chúng tôi thường phát hiện ra họ đã đánh máy trong email, rằng họ không kiểm tra đúng tài khoản email hoặc đơn giản là nó đã vào thư mục thư rác.

Đảm bảo e-mail gửi đi của bạn được khử thư rác (có thể thiết lập tài khoản kiểm tra trên một số dịch vụ thư phổ biến), ghi nhật ký bất cứ điều gì xảy ra và có thể báo cáo điều đó với người dùng nếu họ cố gắng yêu cầu đặt lại mới (ví dụ: gửi thư đến johndoee @ gmail .com không thành công, người dùng không tìm thấy, bạn đã đánh vần đúng chưa?). Ngoài ra, hãy rõ ràng cho người dùng về các vấn đề chính tả và thư rác.

Ngoài ra, OpenID và các xác thực của bên thứ ba khác cũng là một tùy chọn, như những người khác đã nói.


một số người đặt không gian trong mật khẩu của họ?
soandos

Một số người cắt mật khẩu tự động tạo và bao gồm khoảng trắng ở đầu và / hoặc kết thúc một cách tình cờ. (Đọc câu hỏi.)
Macke

3

Tôi muốn sử dụng phương thức xác thực của bên thứ ba, như Facebook, OpenID, Google ... bất cứ điều gì phù hợp với người dùng của bạn. Tuy nhiên, nếu người dùng của bạn không thể nhớ mật khẩu của bạn, có thể họ sẽ không thể sử dụng hệ thống xác thực của bên thứ ba ...

Tùy thuộc vào tình huống của bạn, bạn có thể sử dụng một hệ thống khác, chẳng hạn như chứng chỉ ứng dụng khách SSL (chúng chắc chắn khó cài đặt cho người dùng cuối, nhưng nếu đây là một công ty và bạn có thể tự động cài đặt hệ thống, thì thật tuyệt), Windows SSO, một ứng dụng di động, v.v.


Chứng chỉ khách hàng là một ý tưởng tuyệt vời. Họ không an toàn và là một cơn ác mộng để khắc phục từ xa nếu có sự cố. Openid là một ý tưởng hay mặc dù
Tom Squires

Chứng chỉ không an toàn như thế nào?
Bernard

@bernard bất cứ ai ở PC đó đều có chứng chỉ. Nó cũng khá dễ dàng để có được. Phát hiện ra virus
Tom Squires

1
Tôi đồng ý rằng chúng chỉ an toàn như máy mà chúng cư trú, nhưng đó hoàn toàn là một vấn đề khác.
Bernard

3

Bạn thậm chí có cần phải làm điều đó? Điều đầu tiên bạn cần làm là xác định những gì bạn đang bảo vệ và bạn đang bảo vệ nó khỏi ai. Có lẽ nó không đáng giá cho việc thực hành tốt nhất và có thể thực hành tốt nhất thậm chí sẽ không ngăn chặn kẻ tấn công của bạn.

Nếu bạn chống lại NSA và có thứ gì đó họ muốn, hãy từ bỏ và làm cho cuộc sống của người dùng trở nên dễ dàng. Nếu bạn có số thẻ tín dụng, thì bạn sẽ phải giải quyết các vấn đề về mức độ bảo mật cần thiết, bởi vì có những kẻ xấu ngoài kia muốn chúng và sẽ dành tiền và thời gian để có được chúng. Đó là quyền truy cập vào album ảnh gia đình, bạn có cần tất cả sự bảo mật đó không.

Đọc về Buce Scheiners hoạt động (Bí mật và dối trá) như một khởi đầu tốt để hiểu bảo mật.


3

Điều đầu tiên nhảy ra là email của bạn đang đi vào thư rác. Thiết lập email để nó được công nhận là thực sự không tầm thường. Tôi đề nghị bạn xem xét làm thế nào để ngăn chặn email của bạn bị gắn cờ không chính xác (câu hỏi riêng biệt về SO?)

Điều thứ hai tôi muốn giới thiệu là cung cấp cho người dùng của bạn một trang web / ứng dụng một lần nhấp để bắt đầu khôi phục mật khẩu email. Từ chối thực hiện bất kỳ cách nào khác ngoài email, điều đó không an toàn và tạo tiền lệ xấu.


Không phải e-mail là một cách đặc biệt an toàn để truyền thông tin nhạy cảm. Nếu chỉ người dùng thông thường có thể bị làm phiền với các phím GPG và ssh ...
tdammers 25/212

@tdammers tôi đồng ý là nó không an toàn. Tuy nhiên, nó đã trở thành chìa khóa của danh tính trực tuyến của bạn (tốt hơn hoặc xấu hơn). Hiện tại không có một sự thay thế khả thi tốt hơn.
Tom Squires

Có, có. E-mail được mã hóa. Tôi sử dụng nó mọi lúc và điều đó làm tôi khó chịu vì ngay cả các tập đoàn lớn cũng không bận tâm đến việc mã hóa pubkey cho e-mail nhạy cảm. Nó thậm chí không khó để thực hiện. Tôi thấy thật kỳ lạ khi luật tồn tại (ít nhất là tại Hà Lan) khiến SSL bắt buộc phải có thông tin nhạy cảm, nhưng đồng thời, việc gửi thông tin tương tự qua SMTP đơn giản được coi là chấp nhận được.
tdammers

@tdammers Tôi không biết đủ về nó để tự giới thiệu nó. OP đáng để xem xét mặc dù
Tom Squires

2

Việc họ sẵn sàng gọi cho bạn và nói với bạn mật khẩu của họ thành tiếng cho bạn biết rằng với những người dùng này, mật khẩu và thông tin mà họ bảo vệ không phải là vấn đề lớn. Tôi sẽ không bao giờ làm bất cứ điều gì với mật khẩu ngân hàng của mình. Nhưng có một số trang web yêu cầu mật khẩu cho những thứ thực sự không xứng đáng với chúng. Tôi có một mật khẩu tiêu chuẩn tôi sử dụng cho tất cả những mật khẩu đó và càng "mật khẩu không mạnh" hoặc "chúng tôi sẽ tạo cho bạn mật khẩu và buộc bạn thay đổi mật khẩu thường xuyên", v.v., tôi càng ít muốn sử dụng dịch vụ đó. Tôi sẽ có một cuộc trò chuyện ngắn với những người "giá trị doanh nghiệp" trong cuộc sống của bạn để xem liệu trên thực tế chỉ giữ họ văn bản đơn giản trong db và gửi email cho họ theo yêu cầu sẽ là cách tiếp cận tốt hơn.

Nếu trên thực tế điều này phải an toàn, bạn có thể thử những gì một trong những khách hàng của tôi đã làm với hệ thống mà chúng tôi đã mã hóa cho họ. Trong khi trên điện thoại với người đó, hãy truy cập db và thay đổi địa chỉ email của họ thành của bạn. Sau đó vào web và nhấp vào Quên mật khẩu. Đợi email và sử dụng nó để đăng nhập. Sử dụng trang web, thay đổi mật khẩu thành Mật khẩu hoặc một cái gì đó khác mà bạn đồng ý bằng lời nói với khách hàng. Thay đổi địa chỉ email của họ trở lại địa chỉ của chính họ và nói với họ "tất cả đã được đặt, mật khẩu mới của bạn hiện đang hoạt động!" Khách hàng hài lòng và bạn không cần phải giải thích cho họ những gì đang diễn ra.


2
Sửa đổi cơ sở dữ liệu trực tiếp là một vi phạm an ninh trong chính nó. Điều này có nghĩa là bạn có thể mạo danh bất kỳ người dùng nào sử dụng hệ thống của bạn.
Bernard

3
Các khách hàng của tôi có ứng dụng Windows mà họ có thể chỉnh sửa bất kỳ trường nào cho bất kỳ người dùng nào, nói rằng nếu họ nhận được fax nói rằng họ hiện có số điện thoại mới. Tất nhiên nó đã được kiểm toán. Tất nhiên khi tôi thấy quy trình bằng văn bản này được dán vào tường gần bàn hỗ trợ, tôi KHÔNG HẠNH PHÚC. Nhưng tôi đã đến để chấp nhận nó, và có một dấu vết kiểm toán cho thấy những gì đã xảy ra nếu bất cứ ai gọi và phàn nàn mật khẩu của họ được đặt lại mà không có sự đồng ý của họ. Điều này là, không phải tất cả mọi thứ cần phải được an toàn này. Và người dùng đang nói với bạn rằng điều này không cần phải như vậy.
Kate Gregory

1
Thật không may, hầu hết người dùng không biết gì hơn. Tùy thuộc vào các nhà phát triển ứng dụng phần mềm để thực thi các thực tiễn tốt nhất.
Bernard

4
Tôi đồng ý rằng đây là một lỗ hổng bảo mật lớn. Và tôi đồng ý rằng nó có thể là giải pháp thích hợp nhất. Tuy nhiên, có vẻ như thật ngớ ngẩn khi bộ phận hỗ trợ khách hàng phải tạm thời thay đổi địa chỉ email của khách hàng để đặt lại mật khẩu của người dùng đó: nếu bạn sẽ để hỗ trợ khách hàng đặt lại mật khẩu, hãy để họ làm điều đó trực tiếp.
John Bartholomew

4
Tôi cũng xin lưu ý rằng tiết lộ mật khẩu đồng bằng văn bản đã được người dùng thiết lập (trong thực tế, lưu trữ mật khẩu trong văn bản đơn giản chút nào), trong quan điểm của tôi, cực kỳ tồi tệ hơn việc hỗ trợ khách hàng khả năng trực tiếp thay đổi mật khẩu người dùng.
John Bartholomew

2

phương pháp cuối cùng tôi đã sử dụng trên một hệ thống có người dùng rất mù chữ trong quá khứ là hướng người dùng đến một màn hình nơi họ được cấp số điện thoại và số xác nhận. Họ gọi số điện thoại, xác minh danh tính của họ thông qua các phương tiện thủ công sau đó đọc xác nhận. người hỗ trợ đăng nhập vào một hệ thống riêng, nhập số và nhận số thứ hai để trả lại cho khách hàng. khách hàng đã sử dụng mã thứ hai để tiếp tục trang đặt lại mật khẩu. phiên bản máy khách của trang không thể chạy từ mạng phụ của nhân viên hỗ trợ và màn hình hỗ trợ không thể chạy từ máy khách.

nó không chống đạn vì một người hỗ trợ có thể sử dụng vpn để chạy cả hai đầu từ một vị trí, nhưng nó đủ để kiểm toán vì tài khoản hỗ trợ được ghi là chịu trách nhiệm cho hoạt động


-5

Có thể bằng cách thực hiện các quy tắc bảo mật không phải là KHÔNG. Bằng cách này, tất cả những gì bạn nhận được thực sự ít bảo mật hơn, bởi vì hệ thống rất khó sử dụng nên khách hàng của bạn sẽ cung cấp lại mật khẩu cho bạn và bạn bè của họ chỉ để nó hoạt động!

Bạn không thể gửi cho họ các liên kết BÌNH THƯỜNG, sau đó mật khẩu bên dưới. Nếu liên kết bị hỏng bởi ứng dụng email, chỉ cần hiển thị biểu mẫu với một trường "mã kích hoạt" ... "nhập mã kích hoạt bạn có trong email" ... 5 chữ số để họ không nhầm 0 với O, v.v. 4 chữ số có ổn cho thẻ tín dụng và bạn cần chính sách phức tạp như vậy để đăng nhập đơn giản? Nếu mã không hoạt động, hãy lặp lại kiểm tra với chuỗi TRIMmed? Tôi đoán nó sẽ không làm cho nó kém an toàn, phải không? :)

Đối với tôi nó cũng xảy ra thường xuyên ... tôi nhân đôi mật khẩu và không gian kết thúc được sao chép. Tôi không thể tin được tại sao peple không thể tìm ra chỉ để loại bỏ các ký tự trắng kết thúc khi kiểm tra thất bại và lặp lại quá trình? Sau đó, có thể vỏ thư TOGGLE cho tôi để kiểm tra xem tôi có vô tình nhấn CL không.

Bạn đã quá phức tạp nó quá tệ. Đó không phải là "đặt lại mật khẩu" và "mật khẩu ban đầu" ... mà là "Mã xác nhận" và "Nhập số xác nhận chúng tôi gửi cho bạn vào email", "Không có email? Nó được gửi đến xxx@yyy.com, kiểm tra thư rác của bạn một lần nữa, vẫn không có nó? Gửi lại email xác nhận của bạn ". Trong cơ thể HTML một liên kết. http://xxx.com/conf-12345-mymail-gmail-com.html . Không có khách hàng thư sẽ phá vỡ điều này.


5
Chính sách bảo mật mà ông đề cập không chỉ không phải là "BẠC" mà còn là một yêu cầu của tất cả các ứng dụng "SANE". Các liên kết như thế này được gửi qua e-mail phải hết hạn sau một thời gian để ngăn mật khẩu được đặt lại (bằng cách ăn cắp liên kết trực tiếp hoặc bằng cách vấp phải nó thông qua thuật toán hỗ trợ của máy tính). Mật khẩu có lẽ nên được cắt trước khi xác nhận. Người dùng thật ngu ngốc. Đây là luật. Câu trả lời không phải là giảm các biện pháp bảo mật của chúng tôi mà là thực hiện các bước chủ động để giúp đảm bảo người dùng của chúng tôi hiểu các quy trình thích hợp.
Dalin Seivewright

7
-1. Đây là một cách lành mạnh để làm điều đó, mà hầu hết các trang web sử dụng. Nếu tôi phát hành "quên mật khẩu" trên một trang web và nhận được email có mật khẩu bằng văn bản thuần túy, tôi sẽ đóng tài khoản của mình.
Matt Grande
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.