Xác thực hai yếu tố
Mọi thứ bạn đọc trong liên quan đến nhận dạng dựa trên thực tế là người yêu cầu biết. Anh ấy biết địa chỉ email của mình, biết cách truy cập nó (nghĩa là biết mật khẩu email của anh ấy) và biết câu trả lời cho các câu hỏi bảo mật.
"Kiến thức" được coi là một yếu tố xác thực; hai yếu tố phổ biến khác là bạn có gì, ví dụ, một thiết bị vật lý, và bạn là aichẳng hạn như dấu vân tay hoặc võng mạc của mắt.
Trong hầu hết các trường hợp, việc thực hiện nhận dạng sinh học là không khả thi, đặc biệt khi chúng ta đang nói về tính bảo mật của các ứng dụng web, do đó, với xác thực hai yếu tố (xác thực hai yếu tố, 2FA), thuộc tính thứ hai thường được sử dụng - “những gì bạn có”. Ví dụ, một biến thể phổ biến của yếu tố thứ hai này là mã thông báo vật lý, :
Mã thông báo vật lý thường được sử dụng để xác thực trong VPN công ty và dịch vụ tài chính. Để xác thực dịch vụ, bạn cần sử dụng cả mật khẩu và mã trên mã thông báo (thường xuyên thay đổi) kết hợp với mã PIN. Về mặt lý thuyết, để xác định kẻ tấn công, anh ta phải biết mật khẩu, có mã thông báo và cũng biết mã PIN của mã thông báo. Trong trường hợp đặt lại mật khẩu, bản thân mật khẩu rõ ràng là không xác định, nhưng việc sở hữu mã thông báo có thể được sử dụng để chứng minh quyền sở hữu tài khoản. Tất nhiên, như với bất kỳ triển khai bảo mật nào, , nhưng chắc chắn làm tăng rào cản gia nhập.
Một trong những vấn đề chính của cách tiếp cận này là chi phí và hậu cần thực hiện; chúng ta đang nói về việc bàn giao các thiết bị vật lý cho từng khách hàng và hướng dẫn họ quy trình mới. Ngoài ra, người dùng cần phải có một thiết bị bên mình, điều này không phải lúc nào cũng đúng với mã thông báo vật lý. Một tùy chọn khác là triển khai yếu tố xác thực thứ hai bằng SMS, trong trường hợp 2FA có thể đóng vai trò xác nhận rằng người thực hiện quy trình đặt lại có điện thoại di động của chủ sở hữu tài khoản. Đây là cách Google thực hiện:
Bạn cũng cần kích hoạt , nhưng điều này có nghĩa là lần sau khi bạn đặt lại mật khẩu, điện thoại di động của bạn có thể trở thành yếu tố xác thực thứ hai. Hãy để tôi chứng minh điều này bằng cách sử dụng iPhone của mình làm ví dụ, vì những lý do sẽ sớm trở nên rõ ràng:
Sau khi xác định địa chỉ email của tài khoản, Google xác định rằng 2FA đã được bật và chúng tôi có thể đặt lại tài khoản bằng cách sử dụng xác minh, được gửi qua SMS tới điện thoại di động của chủ sở hữu tài khoản:
Bây giờ chúng ta cần chọn bắt đầu quá trình thiết lập lại:
Hành động này sẽ gửi một email đến địa chỉ đã đăng ký:
Email này chứa URL đặt lại:
Khi truy cập URL đặt lại, một tin nhắn SMS sẽ được gửi và trang web yêu cầu:
Đây là tin nhắn SMS:
Sau khi nhập nó vào trình duyệt, chúng tôi quay lại lãnh thổ đặt lại mật khẩu cổ điển:
Điều này nghe có vẻ hơi dài dòng và đúng như vậy, nhưng biểu mẫu xác nhận rằng người thực hiện đặt lại có quyền truy cập vào địa chỉ email và điện thoại di động của chủ tài khoản. Nhưng nó có thể an toàn hơn chín lần so với việc đặt lại mật khẩu của bạn chỉ qua email. Tuy nhiên, có những vấn đề...
Vấn đề liên quan đến điện thoại thông minh. Thiết bị hiển thị bên dưới chỉ có thể chứng nhận một yếu tố xác thực - thiết bị có thể nhận SMS nhưng không thể nhận email:
Tuy nhiên, thiết bị này có thể nhận tin nhắn SMS и nhận email đặt lại mật khẩu:
Vấn đề là chúng tôi coi email là yếu tố xác thực đầu tiên và SMS (hoặc thậm chí là ứng dụng tạo mã thông báo) là yếu tố thứ hai, nhưng ngày nay chúng được kết hợp trong một thiết bị. Tất nhiên, điều này có nghĩa là nếu ai đó sử dụng điện thoại thông minh của bạn, thì tất cả sự tiện lợi này dẫn đến thực tế là chúng ta quay lại cùng một kênh; yếu tố thứ hai này "những gì bạn có" có nghĩa là bạn cũng có yếu tố đầu tiên. Và tất cả đều được bảo vệ bằng một mã PIN gồm bốn chữ số duy nhất...nếu điện thoại hoàn toàn có mã PIN. и anh ta đã bị chặn.
Có, tính năng 2FA của Google chắc chắn cung cấp khả năng bảo vệ bổ sung, nhưng tính năng này không hoàn hảo và chắc chắn tính năng này không phụ thuộc vào hai kênh hoàn toàn tự trị.
Đặt lại theo tên người dùng so với đặt lại theo địa chỉ email
Tôi có nên chỉ cho phép đặt lại theo địa chỉ email không? Hoặc người dùng cũng có thể đặt lại theo tên? Vấn đề với việc đặt lại theo tên người dùng là không có cách nào để thông báo cho người dùng về tên người dùng không hợp lệ, mà không tiết lộ rằng người khác có thể có tài khoản với tên đó. Trong phần trước, việc đặt lại email đảm bảo rằng chủ sở hữu hợp pháp của email đó sẽ luôn nhận được phản hồi mà không tiết lộ công khai sự tồn tại của họ trong hệ thống. Điều này không thể được thực hiện chỉ với tên người dùng.
Vì vậy, câu trả lời ngắn gọn là: chỉ email. Nếu bạn cố gắng đặt lại chỉ bằng tên người dùng, thì sẽ có trường hợp người dùng sẽ thắc mắc chuyện gì đã xảy ra, hoặc bạn sẽ tiết lộ sự tồn tại của các tài khoản. Có, đó chỉ là tên người dùng, không phải địa chỉ email và vâng, bất kỳ ai cũng có thể chọn bất kỳ tên người dùng (có sẵn) nào, nhưng vẫn có khả năng bạn sẽ gián tiếp tiết lộ chủ sở hữu tài khoản do xu hướng sử dụng lại tên của người dùng.
Vậy điều gì sẽ xảy ra khi ai đó quên tên người dùng của họ? Giả sử rằng tên người dùng không phải là địa chỉ email ngay lập tức (thường là như vậy), thì quá trình này tương tự như cách bắt đầu đặt lại mật khẩu - nhập địa chỉ email, sau đó gửi thư đến địa chỉ này mà không tiết lộ sự tồn tại của nó. Sự khác biệt duy nhất là lần này tin nhắn chỉ chứa tên người dùng chứ không phải URL đặt lại mật khẩu. Hoặc là như vậy, hoặc email sẽ nói rằng không có tài khoản cho địa chỉ này.
Xác minh danh tính và độ chính xác của địa chỉ email
Một khía cạnh quan trọng của việc đặt lại mật khẩu và thậm chí có thể nhiều nhất khía cạnh quan trọng là xác minh danh tính của người đang cố đặt lại. Đây có thực sự là chủ sở hữu hợp pháp của tài khoản hay ai đó đang cố xâm nhập vào tài khoản hoặc gây bất tiện cho chủ sở hữu?
Rõ ràng, email là kênh xác minh danh tính thuận tiện nhất và phổ biến nhất. Nó không phải là hoàn hảo và có nhiều trường hợp chỉ có thể nhận thư tại địa chỉ của chủ sở hữu tài khoản là không đủ nếu yêu cầu mức độ tin cậy cao trong nhận dạng (đó là lý do tại sao 2FA được sử dụng), nhưng nó hầu như luôn luôn là điểm bắt đầu.thiết lập lại quá trình.
Nếu email sẽ đóng vai trò mang lại sự tin cậy, thì bước đầu tiên là đảm bảo rằng địa chỉ email trên thực tế là chính xác. Nếu ai đó mắc lỗi với biểu tượng, thì rõ ràng, quá trình thiết lập lại sẽ không bắt đầu. Quá trình xác minh email tại thời điểm đăng ký là một cách đáng tin cậy để xác minh tính chính xác của địa chỉ. Tất cả chúng ta đều đã thấy nó hoạt động: khi bạn đăng ký, bạn sẽ được gửi một email có một URL duy nhất để nhấp vào, URL này xác nhận rằng bạn là chủ sở hữu thực sự của tài khoản email đó. Không thể đăng nhập cho đến khi quá trình này hoàn tất đảm bảo rằng có động lực để xác minh địa chỉ.
Như trường hợp của nhiều khía cạnh bảo mật khác, mô hình này làm giảm khả năng sử dụng để đổi lấy việc cung cấp mức độ bảo mật tăng lên tương ứng với độ tin cậy vào danh tính của người dùng. Điều này có thể chấp nhận được đối với một trang web nơi người dùng đánh giá cao việc đăng ký và sẵn sàng thêm một bước khác vào quy trình (dịch vụ trả phí, ngân hàng, v.v.), nhưng những thứ như vậy có thể khiến người dùng khó chịu nếu anh ta coi tài khoản là “một- time” và sử dụng , ví dụ, như một phương tiện để bình luận về một bài đăng.
Xác định người đã bắt đầu quá trình thiết lập lại
Rõ ràng, có những lý do để sử dụng tính năng đặt lại một cách ác ý và những kẻ tấn công có thể sử dụng tính năng này theo nhiều cách khác nhau. Một thủ thuật đơn giản mà chúng ta có thể sử dụng để giúp xác minh nguồn gốc của một yêu cầu (thủ thuật này thường works) là phần bổ sung cho bức thư với đề xuất đặt lại địa chỉ IP của người yêu cầu. Nó cung cấp cho người nhận một vài thông tin để xác định nguồn gốc của yêu cầu.
Đây là một ví dụ từ chức năng đặt lại mà tôi hiện đang tích hợp vào ASafaWeb:
Liên kết "tìm hiểu thêm" đưa người dùng đến trang web , cung cấp thông tin như vị trí và tổ chức của người yêu cầu đặt lại:
Tất nhiên, bất kỳ ai muốn che giấu danh tính của mình đều có nhiều cách để làm xáo trộn địa chỉ IP thực của họ, nhưng đây là một cách thuận tiện để thêm nhận dạng một phần của người yêu cầu và trong đa số Trong một số trường hợp, điều này sẽ cung cấp cho bạn ý tưởng hợp lý về việc ai sẽ hoàn thành yêu cầu đặt lại mật khẩu.
Thông báo thay đổi email
Bài đăng này thấm nhuần một chủ đề - giao tiếp; cho chủ sở hữu tài khoản biết càng nhiều càng tốt về những gì xảy ra ở mỗi bước của quy trình mà không tiết lộ bất kỳ điều gì có thể được sử dụng với mục đích xấu. Điều tương tự cũng áp dụng cho trường hợp mật khẩu đã thực sự thay đổi - thông báo cho chủ sở hữu!
Lý do thay đổi mật khẩu có thể từ hai nguồn:
- Thay đổi mật khẩu sau khi đăng nhập vì người dùng muốn có mật khẩu mới
- Đặt lại mật khẩu mà không cần đăng nhập do người dùng quên mật khẩu
Mặc dù bài đăng này chủ yếu là về việc đặt lại, nhưng việc thông báo cho bài đăng đầu tiên sẽ giảm nguy cơ ai đó thay đổi mật khẩu mà chủ sở hữu hợp pháp không hề hay biết. Làm thế nào điều này có thể xảy ra? Một tình huống rất phổ biến là lấy được mật khẩu của chủ sở hữu hợp pháp (mật khẩu được sử dụng lại bị rò rỉ từ nguồn khác, mật khẩu lấy được do keylogging, mật khẩu dễ đoán, v.v.), sau đó kẻ tấn công quyết định thay đổi mật khẩu đó, do đó chặn chủ sở hữu. Nếu không có thông báo qua email, chủ sở hữu thực sự sẽ không biết về việc thay đổi mật khẩu.
Tất nhiên, trong trường hợp đặt lại mật khẩu, chủ sở hữu phải tự bắt đầu quá trình (hoặc bỏ qua các công cụ xác minh danh tính được mô tả ở trên), vì vậy việc thay đổi không nên làm anh ấy ngạc nhiên, tuy nhiên, email xác nhận sẽ là phản hồi tích cực và xác minh bổ sung. Ngoài ra, nó cung cấp sự thống nhất với kịch bản được mô tả ở trên.
Ồ, và trong trường hợp nó vẫn chưa rõ ràng - không gửi mật khẩu mới qua thư! Nó có thể làm cho một số người cười, nhưng :
Nhật ký, nhật ký, nhật ký và một số nhật ký khác
Tính năng đặt lại mật khẩu rất hấp dẫn đối với những kẻ tấn công: kẻ tấn công muốn có quyền truy cập vào tài khoản của người khác hoặc đơn giản là gây bất tiện cho chủ sở hữu tài khoản/hệ thống. Nhiều phương pháp được mô tả ở trên giúp giảm nguy cơ lạm dụng nhưng không ngăn chặn được và chắc chắn chúng sẽ không ngăn mọi người cố gắng sử dụng một tính năng theo cách ngoài ý muốn.
Để phát hiện hành vi nguy hiểm, việc ghi nhật ký là phương pháp hoàn toàn vô giá, và ý tôi là nhật ký rất chi tiết. Ghi lại các lần đăng nhập không thành công, đặt lại mật khẩu, thay đổi mật khẩu (tức là khi người dùng đã đăng nhập) và bất kỳ thứ gì có thể giúp bạn hiểu chuyện gì đang xảy ra; điều này sẽ rất hữu ích trong tương lai. Sửa chữa trong các bản ghi ngay cả cá nhân các bộ phận quy trình, ví dụ: một tính năng đặt lại tốt nên bao gồm bắt đầu đặt lại qua một trang web (ghi lại yêu cầu đặt lại và các lần đăng nhập bằng tên người dùng hoặc email không chính xác), ghi lại lượt truy cập vào trang web tại URL đặt lại (bao gồm cả các lần cố gắng sử dụng một tên người dùng hoặc email không chính xác). mã thông báo), sau đó ghi lại thành công hay thất bại của câu trả lời cho câu hỏi bảo mật.
Khi tôi nói về ghi nhật ký, ý tôi là không chỉ ghi lại thực tế là một trang đã được tải mà còn thu thập càng nhiều thông tin càng tốt, nếu nó không bí mật. Các bạn, vui lòng không đăng nhập mật khẩu! Nhật ký cần đăng ký danh tính của người dùng được ủy quyền (anh ta sẽ được ủy quyền nếu anh ta thay đổi mật khẩu hiện có hoặc cố gắng thiết lập lại mật khẩu của người khác sau khi đăng nhập), bất kỳ tên người dùng hoặc địa chỉ email nào mà nó cố gắng sử dụng, cộng với bất kỳ mã thông báo đặt lại nào mà nó cố gắng sử dụng. Nhưng cũng đáng để ghi lại những thứ như địa chỉ IP và nếu có thể, thậm chí cả tiêu đề yêu cầu. Điều này cho phép bạn tạo lại không chỉ mà người dùng (hoặc kẻ tấn công) đang cố gắng thực hiện, nhưng cũng ai anh ấy là như vậy.
Giao trách nhiệm cho người thực hiện khác
Nếu bạn nghĩ rằng tất cả những điều này đại diện cho một khối lượng công việc khổng lồ, thì bạn không đơn độc. Trên thực tế, việc xây dựng một hệ thống đáng tin cậy để làm việc với các tài khoản không phải là một nhiệm vụ dễ dàng. Nó không khó về mặt kỹ thuật, chỉ là nó có rất nhiều tính năng. Nó không chỉ là đặt lại, mà còn có cả quá trình đăng ký, lưu trữ mật khẩu an toàn, xử lý nhiều lần đăng nhập không hợp lệ, v.v. Mặc dù ngoài ra còn nhiều việc phải làm.
Ngày nay, có nhiều nhà cung cấp bên thứ ba sẵn lòng giải quyết vấn đề này và trừu tượng hóa tất cả thành một dịch vụ được quản lý. Các dịch vụ này bao gồm OpenID, OAuth và thậm chí cả Facebook. Một số người (OpenID đã thực sự rất thành công trên Stack Overflow), nhưng những người khác .
Không còn nghi ngờ gì nữa, một dịch vụ như OpenID giải quyết được rất nhiều vấn đề của nhà phát triển, nhưng cũng chắc chắn rằng nó sẽ bổ sung thêm những vấn đề mới. Họ có vai trò gì không? Có, nhưng rõ ràng là chúng tôi không thấy việc sử dụng ồ ạt dịch vụ của các nhà cung cấp dịch vụ xác thực. Các ngân hàng, hãng hàng không và thậm chí cả cửa hàng đều triển khai cơ chế xác thực của riêng họ và rõ ràng là có những lý do rất chính đáng cho việc này.
Đặt lại độc hại
Một khía cạnh quan trọng của mỗi ví dụ trên là mật khẩu cũ chỉ được coi là vô dụng sau khi xác nhận danh tính của chủ sở hữu tài khoản. Điều này rất quan trọng vì nếu tài khoản có thể được đặt lại để kiểm tra danh tính, điều này sẽ tạo cơ hội cho tất cả các loại hoạt động độc hại.
Đây là một ví dụ: ai đó đang đặt giá thầu trên một trang web đấu giá và khi kết thúc quá trình đặt giá thầu, họ chặn đối thủ cạnh tranh bằng cách bắt đầu quy trình đặt lại, do đó loại họ khỏi đặt giá thầu. Rõ ràng, nếu chức năng thiết lập lại được thiết kế kém có thể bị lạm dụng, nó có thể dẫn đến kết quả tiêu cực nghiêm trọng. Điều đáng chú ý là việc chặn các tài khoản có nỗ lực đăng nhập không hợp lệ cũng là một tình huống tương tự, nhưng đây là một chủ đề cho một bài đăng khác.
Như tôi đã nói ở trên, nếu bạn cung cấp cho người dùng ẩn danh khả năng đặt lại mật khẩu của bất kỳ tài khoản nào chỉ bằng cách biết địa chỉ email của họ, thì đây là tình huống sẵn sàng cho một cuộc tấn công từ chối dịch vụ. Nó có thể không phải là một , điều mà chúng ta đã từng nói đến, nhưng không có cách nào nhanh hơn để chặn quyền truy cập vào tài khoản hơn là chức năng đặt lại mật khẩu được suy nghĩ kỹ lưỡng.
Liên kết yếu nhất
Từ quan điểm bảo vệ một tài khoản, mọi thứ được viết ở trên đều tuyệt vời, nhưng bạn luôn cần lưu ý hệ sinh thái xung quanh tài khoản mà bạn đang bảo vệ. Tôi sẽ cho bạn một ví dụ:
ASafaWeb được lưu trữ trên một dịch vụ tuyệt vời do AppHarbor cung cấp. Quá trình đặt lại tài khoản lưu trữ như sau:
Giai đoạn 1:
Giai đoạn 2:
Giai đoạn 3:
Giai đoạn 4:
Sau khi đọc tất cả các thông tin trước đó, thật dễ hiểu những khía cạnh nào trong một thế giới lý tưởng mà chúng ta sẽ thực hiện hơi khác một chút. Tuy nhiên, điều tôi đang nói ở đây là nếu tôi xuất bản một trang web như ASafaWeb trên AppHarbor, sau đó đưa ra các câu hỏi và câu trả lời bảo mật tuyệt vời, thêm yếu tố xác thực thứ hai và thực hiện mọi thứ khác theo quy tắc, thì điều đó không thay đổi thực tế là mắt xích yếu nhất trong toàn bộ quá trình sẽ có thể phá vỡ tất cả. Nếu ai đó xác thực thành công trong AppHarbor bằng thông tin của tôi, thì anh ta sẽ có thể thay đổi mật khẩu cho bất kỳ tài khoản ASafaWeb nào thành mật khẩu mà anh ta cần!
Vấn đề là sức mạnh của việc triển khai bảo mật nên được xem xét một cách tổng thể: các mối đe dọa nên được mô hình hóa tại mọi điểm vào trong hệ thống, ngay cả khi đó là một quy trình hời hợt như đăng nhập vào AppHarbor. Điều này sẽ cho tôi ý tưởng tốt về mức độ nỗ lực mà tôi cần bỏ ra cho quy trình đặt lại mật khẩu ASafaWeb.
Để tất cả chúng cùng nhau
Bài đăng này chứa rất nhiều thông tin, vì vậy tôi muốn tập trung nó vào một lược đồ trực quan đơn giản:
Hãy nhớ rằng bạn nên ghi nhật ký chi tiết nhất của từng mục này. Thế là xong, đơn giản thôi!
Kết quả
Bài đăng của tôi có vẻ toàn diện, tuy nhiên có rất nhiều tài liệu bổ sung mà tôi có thể bao gồm trong đó, nhưng quyết định không vì lý do ngắn gọn: vai trò của địa chỉ email cứu hộ, tình huống bạn mất quyền truy cập vào email được liên kết với tài khoản của mình (ví dụ: bạn nghỉ việc), v.v. Như tôi đã nói trước đó, chức năng đặt lại không phức tạp lắm, chỉ có nhiều quan điểm khác nhau về nó.
Mặc dù thiết lập lại không quá phức tạp, nhưng nó thường được thực hiện không chính xác. Ở trên, chúng ta đã thấy một vài ví dụ trong đó việc triển khai có thể dẫn đến trục trặc và còn nhiều trường hợp reset sai nữa thực sự gây ra vấn đề. Gần đây hóa ra là . Đây là một kết quả tiêu cực nghiêm trọng!
Vì vậy, hãy cẩn thận với các chức năng thiết lập lại của bạn, ở nhiều điểm khác nhau và khi thiết kế một tính năng, đừng bỏ chiếc mũ đen của bạn ra vì rất có thể người khác sẽ đội nó!
Như một quảng cáo
VDSina cung cấp không tốn kém với khoản thanh toán hàng ngày, mỗi máy chủ được kết nối với kênh Internet 500 Mbps và được bảo vệ khỏi các cuộc tấn công DDoS miễn phí!
Nguồn: www.habr.com