Gần đây tôi đã có thời gian suy nghĩ lại về cách hoạt động của tính năng đặt lại mật khẩu an toàn, lần đầu tiên khi tôi xây dựng chức năng này vào , và sau đó khi anh ấy giúp người khác làm điều gì đó tương tự. Trong trường hợp thứ hai, tôi muốn cung cấp cho anh ấy một liên kết đến tài nguyên chuẩn với tất cả các chi tiết về cách triển khai chức năng đặt lại một cách an toàn. Tuy nhiên, vấn đề là không có nguồn tài nguyên nào như vậy tồn tại, ít nhất là không có nguồn nào mô tả mọi thứ mà tôi cho là quan trọng. Vì thế tôi quyết định tự mình viết nó.
Bạn thấy đấy, thế giới quên mật khẩu thực sự là một thế giới khá bí ẩn. Có nhiều quan điểm khác nhau, hoàn toàn có thể chấp nhận được và cũng có nhiều quan điểm khá nguy hiểm. Có thể bạn đã gặp từng người trong số họ nhiều lần với tư cách là người dùng cuối; vì vậy, tôi sẽ cố gắng sử dụng những ví dụ này để cho biết ai làm đúng, ai làm sai và bạn cần tập trung vào điều gì để đưa tính năng này ngay vào ứng dụng của mình.
Lưu trữ mật khẩu: băm, mã hóa và văn bản thuần túy (thở hổn hển!)
Chúng ta không thể thảo luận việc cần làm với mật khẩu bị quên trước khi thảo luận về cách lưu trữ chúng. Mật khẩu được lưu trữ trong cơ sở dữ liệu theo một trong ba loại chính:
- Văn bản đơn giản. Có một cột mật khẩu, được lưu trữ ở dạng văn bản thuần túy.
- Đã mã hóa. Thông thường sử dụng mã hóa đối xứng (một khóa được sử dụng cho cả mã hóa và giải mã) và mật khẩu được mã hóa cũng được lưu trữ trong cùng một cột.
- Đã băm. Quy trình một chiều (mật khẩu có thể được băm nhưng không thể được băm); mật khẩu, Tôi muốn hy vọng, theo sau là muối và mỗi muối nằm trong cột riêng.
Hãy đi thẳng vào câu hỏi đơn giản nhất: Không bao giờ lưu trữ mật khẩu ở dạng văn bản thuần túy! Không bao giờ. Một lỗ hổng duy nhất đối với , một bản sao lưu bất cẩn hoặc một trong hàng tá lỗi đơn giản khác - và thế là xong, trò chơi kết thúc, tất cả mật khẩu của bạn - nghĩa là, xin lỗi, mật khẩu của tất cả khách hàng của bạn sẽ trở thành miền công cộng. Tất nhiên, điều này có nghĩa là có khả năng rất lớn rằng từ tất cả các tài khoản của họ trong các hệ thống khác. Và đó sẽ là lỗi của bạn.
Mã hóa tốt hơn nhưng có điểm yếu. Vấn đề với mã hóa là giải mã; chúng ta có thể lấy những mật mã trông điên rồ này và chuyển chúng trở lại thành văn bản thuần túy, và khi điều đó xảy ra, chúng ta quay lại tình huống mật khẩu mà con người có thể đọc được. Làm thế nào điều này xảy ra? Một lỗ hổng nhỏ xâm nhập vào mã giải mã mật khẩu, khiến nó được công khai - đây là một cách. Tin tặc có quyền truy cập vào máy lưu trữ dữ liệu được mã hóa - đây là phương pháp thứ hai. Một cách khác nữa là đánh cắp bản sao lưu cơ sở dữ liệu và ai đó cũng lấy được khóa mã hóa, khóa này thường được lưu trữ rất không an toàn.
Và điều này đưa chúng ta đến việc băm. Ý tưởng đằng sau việc băm là nó một chiều; cách duy nhất để so sánh mật khẩu do người dùng nhập với phiên bản băm của nó là băm dữ liệu đầu vào và so sánh chúng. Để ngăn chặn các cuộc tấn công từ các công cụ như bảng cầu vồng, chúng tôi xử lý quy trình một cách ngẫu nhiên (đọc phần của tôi về lưu trữ mật mã). Cuối cùng, nếu được triển khai đúng cách, chúng tôi có thể tin tưởng rằng mật khẩu đã băm sẽ không bao giờ trở thành văn bản thuần túy nữa (tôi sẽ nói về lợi ích của các thuật toán băm khác nhau trong một bài đăng khác).
Lập luận nhanh về băm và mã hóa: lý do duy nhất bạn cần mã hóa thay vì băm mật khẩu là khi bạn cần xem mật khẩu ở dạng văn bản thuần túy và bạn không bao giờ nên muốn điều này, ít nhất là trong tình huống trang web tiêu chuẩn. Nếu bạn cần điều này thì rất có thể bạn đang làm sai điều gì đó!
Cảnh báo!
Bên dưới nội dung của bài đăng có một phần ảnh chụp màn hình của trang web khiêu dâm AlotPorn. Nó được cắt tỉa gọn gàng để không có gì bạn không thể nhìn thấy trên bãi biển, nhưng nếu nó vẫn có khả năng gây ra vấn đề gì thì đừng cuộn xuống.
Luôn đặt lại mật khẩu của bạn không bao giờ đừng nhắc nhở anh ấy
Bạn đã bao giờ được yêu cầu tạo một hàm lời nhắc nhở mật khẩu? Hãy lùi lại một bước và suy nghĩ ngược lại về yêu cầu này: tại sao lại cần “lời nhắc” này? Vì người dùng quên mật khẩu. Chúng ta thực sự muốn làm gì? Giúp anh ta đăng nhập lại.
Tôi nhận thấy từ "nhắc nhở" được sử dụng (thường xuyên) theo nghĩa thông tục, nhưng điều chúng tôi thực sự đang cố gắng làm là giúp người dùng trực tuyến trở lại một cách an toàn. Vì chúng ta cần bảo mật nên có hai lý do khiến lời nhắc (tức là gửi mật khẩu cho người dùng) là không phù hợp:
- Email là một kênh không an toàn. Giống như chúng ta sẽ không gửi bất kỳ nội dung nhạy cảm nào qua HTTP (chúng ta sẽ sử dụng HTTPS), chúng ta không nên gửi bất kỳ nội dung nhạy cảm nào qua email vì lớp truyền tải của nó không an toàn. Trên thực tế, điều này còn tệ hơn nhiều so với việc chỉ gửi thông tin qua giao thức truyền tải không an toàn, vì thư thường được lưu trữ trên một thiết bị lưu trữ, có thể được quản trị viên hệ thống truy cập, được chuyển tiếp và phân phối, có thể bị phần mềm độc hại truy cập, v.v. Email không được mã hóa là một kênh cực kỳ không an toàn.
- Dù sao thì bạn cũng không có quyền truy cập vào mật khẩu. Đọc lại phần trước về lưu trữ - bạn nên có một hàm băm mật khẩu (với muối mạnh), nghĩa là bạn không thể trích xuất mật khẩu và gửi nó qua đường bưu điện bằng bất kỳ cách nào.
Hãy để tôi chứng minh vấn đề bằng một ví dụ : Đây là một trang đăng nhập điển hình:
Rõ ràng, vấn đề đầu tiên là trang đăng nhập không tải qua HTTPS nhưng trang web cũng nhắc bạn gửi mật khẩu (“Gửi mật khẩu”). Đây có thể là một ví dụ về cách sử dụng thông tục của thuật ngữ được đề cập ở trên, vì vậy hãy tiến thêm một bước nữa và xem điều gì sẽ xảy ra:
Thật không may, nó trông không đẹp hơn nhiều; và một email xác nhận có vấn đề:
Điều này cho chúng ta biết hai khía cạnh quan trọng của usoutdoor.com:
- Trang web không băm mật khẩu. Tốt nhất là chúng được mã hóa, nhưng có khả năng chúng được lưu trữ ở dạng văn bản thuần túy; Chúng tôi không thấy bằng chứng nào ngược lại.
- Trang web gửi mật khẩu dài hạn (chúng tôi có thể quay lại và sử dụng mật khẩu đó nhiều lần) qua một kênh không bảo mật.
Ngoài ra, chúng ta cần kiểm tra xem quá trình thiết lập lại có được thực hiện một cách an toàn hay không. Bước đầu tiên để thực hiện việc này là đảm bảo rằng người yêu cầu có quyền thực hiện việc đặt lại. Nói cách khác, trước đó chúng ta cần kiểm tra danh tính; Hãy cùng xem điều gì sẽ xảy ra khi danh tính được xác minh mà không xác minh trước rằng người yêu cầu thực sự là chủ sở hữu tài khoản.
Liệt kê tên người dùng và tác động của nó đối với tính ẩn danh
Vấn đề này được minh họa tốt nhất bằng trực quan. Vấn đề:
Bạn có thấy? Hãy chú ý đến thông báo “Không có người dùng nào đăng ký bằng địa chỉ email này”. Vấn đề rõ ràng sẽ phát sinh nếu một trang web như vậy xác nhận sẵn sàng người dùng đã đăng ký với địa chỉ email đó. Bingo - bạn vừa phát hiện ra sở thích khiêu dâm của chồng/sếp/hàng xóm của mình!
Tất nhiên, nội dung khiêu dâm là một ví dụ khá mang tính biểu tượng về tầm quan trọng của quyền riêng tư, nhưng sự nguy hiểm của việc liên kết một cá nhân với một trang web cụ thể còn rộng hơn nhiều so với tình huống khó xử có thể xảy ra được mô tả ở trên. Một mối nguy hiểm là kỹ thuật xã hội; Nếu kẻ tấn công có thể kết nối một người với dịch vụ thì anh ta sẽ có thông tin mà anh ta có thể bắt đầu sử dụng. Ví dụ: anh ta có thể liên hệ với một người đóng giả là đại diện của một trang web và yêu cầu thông tin bổ sung nhằm cố gắng cam kết .
Những hành vi như vậy cũng làm tăng nguy cơ “liệt kê tên người dùng”, theo đó người ta có thể xác minh sự tồn tại của toàn bộ bộ sưu tập tên người dùng hoặc địa chỉ email trên một trang web bằng cách thực hiện các truy vấn nhóm và kiểm tra phản hồi cho chúng. Bạn có danh sách địa chỉ email của tất cả nhân viên và vài phút để viết kịch bản không? Thế thì bạn sẽ thấy vấn đề là gì!
Giải pháp thay thế là gì? Trên thực tế, nó khá đơn giản và được triển khai một cách tuyệt vời trong :
Ở đây Entropay hoàn toàn không tiết lộ gì về sự tồn tại của một địa chỉ email trong hệ thống của mình cho người không sở hữu địa chỉ này... nếu bạn riêng địa chỉ này và nó không tồn tại trong hệ thống thì bạn sẽ nhận được một email như thế này:
Tất nhiên, có thể có những tình huống có thể chấp nhận được trong đó ai đó nghĩmà bạn đã đăng ký trên trang web. nhưng trường hợp này không phải như vậy hoặc tôi đã thực hiện việc đó từ một địa chỉ email khác. Ví dụ hiển thị ở trên xử lý tốt cả hai tình huống. Rõ ràng, nếu địa chỉ trùng khớp, bạn sẽ nhận được email giúp việc đặt lại mật khẩu của bạn dễ dàng hơn.
Sự tinh tế của giải pháp được Entropay lựa chọn là việc xác minh danh tính được thực hiện theo e-mail trước khi thực hiện bất kỳ xác minh trực tuyến nào. Một số trang web yêu cầu người dùng trả lời câu hỏi bảo mật (thông tin thêm về điều này bên dưới) để quá trình thiết lập lại có thể bắt đầu như thế nào; tuy nhiên, vấn đề với điều này là bạn phải trả lời câu hỏi trong khi cung cấp một số hình thức nhận dạng (email hoặc tên người dùng), điều này khiến bạn gần như không thể trả lời bằng trực giác nếu không tiết lộ sự tồn tại của tài khoản người dùng ẩn danh.
Với cách tiếp cận này có nhỏ giảm khả năng sử dụng vì nếu bạn cố gắng đặt lại tài khoản không tồn tại, sẽ không có phản hồi ngay lập tức. Tất nhiên, đó là toàn bộ mục đích của việc gửi email, nhưng từ góc độ của người dùng cuối thực sự, nếu họ nhập sai địa chỉ, họ sẽ chỉ biết lần đầu tiên khi nhận được email. Điều này có thể gây ra một số căng thẳng cho anh ấy, nhưng đây là một cái giá nhỏ phải trả cho một quá trình hiếm hoi như vậy.
Một lưu ý khác, hơi lạc đề: các chức năng hỗ trợ đăng nhập tiết lộ liệu tên người dùng hoặc địa chỉ email có chính xác hay không cũng gặp vấn đề tương tự. Luôn trả lời người dùng bằng thông báo “Kết hợp tên người dùng và mật khẩu của bạn không hợp lệ” thay vì xác nhận rõ ràng sự tồn tại của thông tin xác thực (ví dụ: “tên người dùng đúng nhưng mật khẩu không chính xác”).
Gửi mật khẩu đặt lại và gửi URL đặt lại
Khái niệm tiếp theo chúng ta cần thảo luận là cách đặt lại mật khẩu của bạn. Có hai giải pháp phổ biến:
- Tạo mật khẩu mới trên máy chủ và gửi nó qua email
- Gửi email có URL duy nhất để giúp quá trình đặt lại dễ dàng hơn
Mặc dù , điểm đầu tiên không bao giờ nên được sử dụng. Vấn đề với điều này là nó có nghĩa là có mật khẩu được lưu trữ, bạn có thể quay lại và sử dụng lại bất kỳ lúc nào; nó đã được gửi qua một kênh không an toàn và vẫn còn trong hộp thư đến của bạn. Rất có thể hộp thư đến được đồng bộ hóa trên các thiết bị di động và ứng dụng email, ngoài ra chúng có thể được lưu trữ trực tuyến trong dịch vụ email trên web trong một thời gian rất dài. Vấn đề là ở chỗ hộp thư không thể được coi là phương tiện lưu trữ lâu dài đáng tin cậy.
Nhưng bên cạnh đó, điểm đầu tiên còn có một vấn đề nghiêm trọng khác - đó là đơn giản hóa hết mức có thể chặn một tài khoản với mục đích xấu. Nếu tôi biết địa chỉ email của người sở hữu tài khoản trên một trang web thì tôi có thể chặn họ bất kỳ lúc nào bằng cách đặt lại mật khẩu của họ; Đây là một cuộc tấn công từ chối dịch vụ được phục vụ trên một đĩa bạc! Đây là lý do tại sao việc đặt lại chỉ nên được thực hiện sau khi xác minh thành công quyền của người yêu cầu đối với nó.
Khi chúng tôi nói về URL đặt lại, chúng tôi muốn nói đến địa chỉ của một trang web duy nhất cho trường hợp cụ thể này của quá trình thiết lập lại. Tất nhiên, nó phải ngẫu nhiên, không dễ đoán và không được chứa bất kỳ liên kết bên ngoài nào đến tài khoản để giúp thiết lập lại dễ dàng hơn. Ví dụ: URL đặt lại không được chỉ là một đường dẫn như "Reset/?username=JohnSmith".
Chúng tôi muốn tạo một mã thông báo duy nhất có thể được gửi dưới dạng URL đặt lại và sau đó khớp với bản ghi máy chủ của tài khoản người dùng, do đó xác nhận rằng chủ sở hữu tài khoản trên thực tế chính là người đang cố gắng đặt lại mật khẩu. Ví dụ: mã thông báo có thể là "3ce7854015cd38c862cb9e14a1ae552b" và được lưu trữ trong một bảng cùng với ID của người dùng thực hiện đặt lại và thời gian mã thông báo được tạo (xem thêm thông tin này bên dưới). Khi email được gửi, nó chứa một URL như “Reset/?id=3ce7854015cd38c862cb9e14a1ae552b” và khi người dùng tải xuống, trang sẽ nhắc về sự tồn tại của mã thông báo, sau đó nó xác nhận thông tin của người dùng và cho phép họ thay đổi mật khẩu.
Tất nhiên, vì quy trình trên (hy vọng) cho phép người dùng tạo mật khẩu mới nên chúng tôi cần đảm bảo rằng URL được tải qua HTTPS. KHÔNG, , URL mã thông báo này phải sử dụng bảo mật lớp truyền tải để hình thức mật khẩu mới không thể bị tấn công và mật khẩu do người dùng tạo được truyền qua kết nối an toàn.
Ngoài ra, đối với URL đặt lại, bạn cần thêm giới hạn thời gian mã thông báo để quá trình đặt lại có thể được hoàn thành trong một khoảng thời gian nhất định, chẳng hạn như trong vòng một giờ. Điều này đảm bảo rằng khoảng thời gian đặt lại được giữ ở mức tối thiểu để người nhận URL đặt lại chỉ có thể hành động trong khoảng thời gian rất nhỏ đó. Tất nhiên, kẻ tấn công có thể bắt đầu lại quá trình đặt lại, nhưng chúng sẽ cần lấy một URL đặt lại duy nhất khác.
Cuối cùng, chúng ta cần đảm bảo rằng quá trình này chỉ dùng một lần. Sau khi quá trình đặt lại hoàn tất, mã thông báo phải được xóa để URL đặt lại không còn hoạt động. Điểm trước đó là cần thiết để đảm bảo rằng kẻ tấn công có một cửa sổ rất nhỏ trong đó hắn có thể thao túng URL đặt lại. Ngoài ra, tất nhiên, sau khi thiết lập lại thành công, mã thông báo sẽ không còn cần thiết nữa.
Một số bước này có vẻ quá dư thừa nhưng chúng không ảnh hưởng đến khả năng sử dụng và trên thực tế cải thiện sự an toàn, mặc dù trong những tình huống mà chúng tôi hy vọng sẽ hiếm xảy ra. Trong 99% trường hợp, người dùng sẽ kích hoạt đặt lại trong một khoảng thời gian rất ngắn và sẽ không đặt lại mật khẩu trong thời gian sắp tới.
Vai trò của CAPTCHA
Ôi, CAPTCHA, tính năng bảo mật mà tất cả chúng ta đều ghét! Trên thực tế, CAPTCHA không hẳn là một công cụ bảo vệ mà nó là một công cụ nhận dạng - cho dù bạn là người hay robot (hoặc một tập lệnh tự động). Mục đích của nó là để tránh việc gửi biểu mẫu tự động, tất nhiên, có thể được sử dụng như một nỗ lực để phá vỡ an ninh. Trong trường hợp đặt lại mật khẩu, CAPTCHA có nghĩa là chức năng đặt lại không thể bị ép buộc một cách thô bạo để gửi thư rác cho người dùng hoặc cố gắng xác định sự tồn tại của các tài khoản (tất nhiên, điều này sẽ không thể thực hiện được nếu bạn làm theo lời khuyên trong phần về xác minh danh tính).
Tất nhiên, bản thân CAPTCHA không hoàn hảo; Đã có nhiều tiền lệ về việc “hack” phần mềm của hãng và đạt tỷ lệ thành công khá cao (60-70%). Ngoài ra, có một giải pháp được hiển thị trong bài viết của tôi về , nơi bạn có thể trả cho mọi người một phần xu để giải từng CAPTCHA và đạt được tỷ lệ thành công là 94%. Nghĩa là, nó dễ bị tổn thương, nhưng nó (một chút) làm tăng rào cản gia nhập.
Chúng ta hãy xem ví dụ về PayPal:
Trong trường hợp này, quá trình đặt lại không thể bắt đầu cho đến khi giải được CAPTCHA, vì vậy trên lý thuyết không thể tự động hóa quá trình này. Về lý thuyết.
Tuy nhiên, đối với hầu hết các ứng dụng web, điều này sẽ là quá mức cần thiết và hoàn toàn đúng thể hiện sự giảm khả năng sử dụng - mọi người không thích CAPTCHA! Ngoài ra, CAPTCHA là thứ mà bạn có thể dễ dàng quay lại nếu cần. Nếu dịch vụ bắt đầu bị tấn công (đây là lúc việc ghi nhật ký trở nên hữu ích, nhưng sẽ nói thêm về điều đó sau), thì việc thêm CAPTCHA không thể dễ dàng hơn được.
Câu hỏi và câu trả lời bí mật
Với tất cả các phương pháp mà chúng tôi đã xem xét, chúng tôi có thể đặt lại mật khẩu chỉ bằng cách có quyền truy cập vào tài khoản email. Tôi nói “chỉ”, nhưng tất nhiên, việc truy cập vào tài khoản email của người khác là bất hợp pháp. nên phải là một quá trình phức tạp. Tuy nhiên .
Trên thực tế, liên kết ở trên về vụ hack Yahoo! phục vụ hai mục đích; thứ nhất, nó minh họa việc hack (một số) tài khoản email dễ dàng như thế nào và thứ hai, nó cho thấy các câu hỏi bảo mật xấu có thể được sử dụng với mục đích xấu như thế nào. Nhưng chúng ta sẽ quay lại vấn đề này sau.
Vấn đề với việc đặt lại mật khẩu XNUMX% dựa trên email là tính toàn vẹn của tài khoản đối với trang web bạn đang cố gắng đặt lại trở nên phụ thuộc XNUMX% vào tính toàn vẹn của tài khoản email. Bất cứ ai có quyền truy cập vào email của bạn có quyền truy cập vào bất kỳ tài khoản nào có thể được đặt lại bằng cách nhận email. Đối với những tài khoản như vậy, email là “chìa khóa mở mọi cánh cửa” cuộc sống trực tuyến của bạn.
Một cách để giảm thiểu rủi ro này là triển khai mẫu câu hỏi và câu trả lời bảo mật. Không còn nghi ngờ gì nữa, bạn đã nhìn thấy chúng: hãy chọn một câu hỏi mà chỉ bạn mới có thể trả lời có biết câu trả lời và khi bạn đặt lại mật khẩu, bạn sẽ được yêu cầu nhập mật khẩu đó. Điều này làm tăng thêm niềm tin rằng người cố gắng đặt lại thực sự là chủ sở hữu tài khoản.
Quay lại với Sarah Palin: sai lầm là có thể dễ dàng tìm thấy câu trả lời cho câu hỏi/câu hỏi bảo mật của cô ấy. Đặc biệt khi bạn là một nhân vật quan trọng của công chúng, thông tin về tên thời con gái của mẹ bạn, quá trình học tập hoặc nơi ai đó có thể đã sống trong quá khứ không phải là điều bí mật. Trên thực tế, hầu hết mọi người đều có thể tìm thấy nó. Đây là những gì đã xảy ra với Sarah:
Hacker David Kernell đã giành được quyền truy cập vào tài khoản của Palin bằng cách tìm thông tin chi tiết về lý lịch của cô, chẳng hạn như trường đại học và ngày sinh, sau đó sử dụng tính năng khôi phục mật khẩu bị quên của Yahoo!.
Trước hết, đây là lỗi thiết kế của Yahoo! — bằng cách chỉ định những câu hỏi đơn giản như vậy, về cơ bản, công ty đã phá hoại giá trị của câu hỏi bảo mật và do đó phá hoại khả năng bảo vệ hệ thống của công ty. Tất nhiên, việc đặt lại mật khẩu cho tài khoản email luôn khó khăn hơn vì bạn không thể chứng minh quyền sở hữu bằng cách gửi email đến chủ sở hữu (không có địa chỉ thứ hai), nhưng may mắn thay, ngày nay không có nhiều cách sử dụng để tạo một hệ thống như vậy.
Hãy quay lại câu hỏi bảo mật - có một tùy chọn cho phép người dùng tạo câu hỏi của riêng họ. Vấn đề là điều này sẽ dẫn đến những câu hỏi quá rõ ràng:
Bầu trời có màu gì?
Những câu hỏi khiến mọi người khó chịu khi dùng câu hỏi bảo mật để nhận dạng người (ví dụ: trong trung tâm cuộc gọi):
Tôi đã ngủ với ai vào dịp Giáng sinh?
Hoặc những câu hỏi thẳng thắn ngu ngốc:
Bạn đánh vần "mật khẩu" như thế nào?
Khi nói đến câu hỏi bảo mật, người dùng cần phải tự cứu mình! Nói cách khác, câu hỏi bảo mật phải được xác định bởi chính trang web đó hoặc tốt hơn là được hỏi. loạt câu hỏi bảo mật mà người dùng có thể chọn. Và thật không dễ để lựa chọn một; lý tưởng nhất là người dùng nên chọn hai hoặc nhiều câu hỏi bảo mật tại thời điểm đăng ký tài khoản, sau đó sẽ được sử dụng làm kênh nhận dạng thứ hai. Việc có nhiều câu hỏi giúp tăng độ tin cậy trong quá trình xác minh, đồng thời cung cấp khả năng thêm tính ngẫu nhiên (không phải lúc nào cũng hiển thị cùng một câu hỏi), đồng thời cung cấp một chút dự phòng trong trường hợp người dùng thực tế quên mật khẩu.
Câu hỏi bảo mật tốt là gì? Điều này bị ảnh hưởng bởi một số yếu tố:
- Nó nên được ngắn gọn - câu hỏi phải rõ ràng, không mập mờ.
- Câu trả lời phải là riêng — chúng ta không cần một câu hỏi mà một người có thể trả lời khác nhau
- Câu trả lời có thể nên là phong phú - hỏi màu sắc yêu thích của ai đó sẽ mang lại một tập hợp rất nhỏ các câu trả lời có thể
- tìm kiếm câu trả lời phải phức tạp - nếu có thể dễ dàng tìm thấy câu trả lời bất kỳ (nhớ người ở vị trí cao) thì anh ấy xấu
- Câu trả lời phải là vĩnh viễn đúng lúc - nếu bạn hỏi ai đó về bộ phim yêu thích thì một năm sau câu trả lời có thể sẽ khác
Thực tế là có một trang web dành riêng cho việc đặt những câu hỏi hay được gọi là . Một số câu hỏi có vẻ khá hay, một số khác không vượt qua được một số bài kiểm tra được mô tả ở trên, đặc biệt là bài kiểm tra “dễ tìm kiếm”.
Hãy để tôi trình bày cách PayPal triển khai các câu hỏi bảo mật và đặc biệt là nỗ lực mà trang web dành cho việc xác thực. Ở trên, chúng tôi thấy trang để bắt đầu quá trình (với CAPTCHA) và ở đây chúng tôi sẽ hiển thị điều gì xảy ra sau khi bạn nhập địa chỉ email của mình và giải CAPTCHA:
Kết quả là người dùng nhận được thư sau:
Cho đến nay mọi thứ đều khá bình thường, nhưng đây là những gì ẩn sau URL đặt lại này:
Vì vậy, đây là lúc các câu hỏi bảo mật phát huy tác dụng. Trên thực tế, PayPal cũng cho phép bạn đặt lại mật khẩu bằng cách xác minh số thẻ tín dụng của mình, do đó, có một kênh bổ sung mà nhiều trang web không có quyền truy cập. Tôi không thể thay đổi mật khẩu mà không trả lời cả hai câu hỏi bảo mật (hoặc không biết số thẻ). Ngay cả khi ai đó chiếm đoạt email của tôi, họ sẽ không thể đặt lại mật khẩu tài khoản PayPal của tôi trừ khi họ biết thêm một chút thông tin cá nhân về tôi. Thông tin gì? Dưới đây là các tùy chọn câu hỏi bảo mật mà PayPal cung cấp:
Câu hỏi về trường học và bệnh viện có thể hơi khó hiểu về mặt dễ tìm kiếm, nhưng những câu hỏi khác thì không quá tệ. Tuy nhiên, để tăng cường bảo mật, PayPal yêu cầu nhận dạng bổ sung cho thay đổi câu trả lời cho câu hỏi bảo mật:
PayPal là một ví dụ khá không tưởng về việc đặt lại mật khẩu an toàn: nó triển khai CAPTCHA để giảm nguy cơ tấn công vũ phu, yêu cầu hai câu hỏi bảo mật và sau đó yêu cầu một loại nhận dạng hoàn toàn khác chỉ để thay đổi câu trả lời—và điều này sau khi người dùng đã đăng nhập rồi. Tất nhiên, đây chính xác là những gì chúng tôi hy vọng từ PayPal; là một tổ chức tài chính giao dịch với số tiền lớn. Điều này không có nghĩa là mỗi lần đặt lại mật khẩu đều phải tuân theo các bước sau—hầu hết các bước này là quá mức cần thiết—nhưng đó là một ví dụ điển hình cho những trường hợp mà vấn đề bảo mật là vấn đề nghiêm túc.
Sự tiện lợi của hệ thống câu hỏi bảo mật là nếu bạn chưa triển khai ngay thì có thể bổ sung sau nếu mức độ bảo vệ tài nguyên yêu cầu. Một ví dụ điển hình cho điều này là Apple, công ty chỉ mới triển khai cơ chế này gần đây [bài viết năm 2012]. Khi tôi bắt đầu cập nhật ứng dụng trên iPad của mình, tôi thấy yêu cầu sau:
Sau đó, tôi thấy một màn hình nơi tôi có thể chọn một số cặp câu hỏi và câu trả lời bảo mật cũng như địa chỉ email cứu hộ:
Đối với PayPal, các câu hỏi đã được chọn trước và một số trong số đó thực sự khá hay:
Mỗi cặp trong số ba cặp câu hỏi/câu trả lời đại diện cho một nhóm câu hỏi có thể khác nhau, vì vậy có rất nhiều cách để định cấu hình tài khoản.
Một khía cạnh khác cần cân nhắc khi trả lời câu hỏi bảo mật của bạn là lưu trữ. Việc có cơ sở dữ liệu văn bản đơn giản trong cơ sở dữ liệu gây ra các mối đe dọa gần như giống như mật khẩu, cụ thể là việc lộ cơ sở dữ liệu ngay lập tức sẽ tiết lộ giá trị và không chỉ khiến ứng dụng gặp rủi ro mà còn có khả năng là các ứng dụng hoàn toàn khác sử dụng cùng một câu hỏi bảo mật (lại nữa). ). Một tùy chọn là băm an toàn (thuật toán mạnh và muối ngẫu nhiên bằng mật mã), nhưng không giống như hầu hết các trường hợp lưu trữ mật khẩu, có thể có lý do chính đáng để phản hồi hiển thị dưới dạng văn bản thuần túy. Một tình huống điển hình là xác minh danh tính bởi một nhà điều hành điện thoại trực tiếp. Tất nhiên, băm cũng có thể được áp dụng trong trường hợp này (người vận hành có thể chỉ cần nhập phản hồi do khách hàng đặt tên), nhưng trong trường hợp xấu nhất, phản hồi bí mật phải được đặt ở một mức lưu trữ mật mã nào đó, ngay cả khi đó chỉ là mã hóa đối xứng. . Tóm tắt: coi bí mật như bí mật!
Một khía cạnh cuối cùng của câu hỏi và câu trả lời bảo mật là chúng dễ bị tấn công bởi kỹ nghệ xã hội hơn. Cố gắng trích xuất trực tiếp mật khẩu vào tài khoản của người khác là một chuyện, nhưng bắt đầu cuộc trò chuyện về sự hình thành của nó (một câu hỏi bảo mật phổ biến) lại hoàn toàn khác. Trên thực tế, bạn có thể trao đổi rất tốt với ai đó về nhiều khía cạnh trong cuộc sống của họ mà có thể đặt ra một câu hỏi bí mật mà không gây nghi ngờ. Tất nhiên, điểm mấu chốt của câu hỏi bảo mật là nó liên quan đến trải nghiệm cuộc sống của ai đó, vì vậy nó rất đáng nhớ, và đó là vấn đề nằm ở chỗ - mọi người thích nói về kinh nghiệm sống của họ! Bạn có thể làm được rất ít điều này, chỉ khi bạn chọn các tùy chọn câu hỏi bảo mật như vậy để chúng được ít hơn có lẽ có thể được rút ra bằng kỹ thuật xã hội.
[Còn tiếp.]Như một quảng cáo
VDSina cung cấp đáng tin cậy , mỗi máy chủ được kết nối với kênh Internet 500 Megabits và được bảo vệ miễn phí khỏi các cuộc tấn công DDoS!
Nguồn: www.habr.com