MeldID đã thêm chế độ hoảng loạn: chuyện gì xảy ra khi không thể tin tưởng vào truy cập tài khoản nữa

Trong bài viết trước về MeldID, tôi đã mô tả cách hệ thống hoạt động theo chế độ thông thường: lưu trữ hồ sơ quản lý, hỗ trợ đăng nhập các dịch vụ liên kết, đồng bộ hóa ghi chú TOTP giữa các thiết bị và cho phép xác nhận các đăng nhập mới qua ứng dụng di động.

Tuy nhiên, bất cứ hệ thống nhận dạng nào cũng có kịch bản mà thường bị bỏ quên quá muộn: phải làm gì nếu người dùng không còn tin tưởng vào trạng thái truy cập hiện tại của họ?

Không cần phải phát hiện rõ ràng hệ thống bị xâm phạm. Đôi khi chỉ cần một email phục hồi mật khẩu bất ngờ, một phiên truy cập lạ hoặc đăng nhập bằng thiết bị mà chủ sở hữu không quen biết.

Chính để đối phó với những tình huống như vậy, MeldID đã bổ sung hai cơ chế mới: đổi mật khẩu hoãn lại và chế độ hoảng loạn.

Trước tiên, cần hiểu cách hệ thống mật khẩu của MeldID hoạt động

Trong MeldID, người dùng không tự đặt mật khẩu — hệ thống tự tạo ra. Điều này giúp loại trừ các mật khẩu yếu, dễ đoán, sử dụng lại mật khẩu thông thường hoặc những vấn đề liên quan đến việc chọn mật khẩu thủ công.

Hơn nữa, mật khẩu hiện tại không được gửi đến người dùng qua email. Hộp thư email không thể dùng để lấy mật khẩu của MeldID.

Quá trình phục hồi cũng không tiết lộ mật khẩu cũ, mà chỉ cho phép bắt đầu tạo mật khẩu mới.

Vì vậy, việc bị xâm phạm email tạo ra một mối đe dọa khác: người có quyền truy cập vào hộp thư có thể không biết mật khẩu hoạt động của MeldID, nhưng có thể cố gắng dùng thủ tục phục hồi để thiết lập mật khẩu mới.

Chính kịch bản này đã dẫn đến quyết định thay đổi logic của quá trình phục hồi.

Bây giờ, mật khẩu không đổi ngay lập tức

Trong các kịch bản phục hồi thông thường, mọi thứ diễn ra gần như tức thì. Người dùng yêu cầu mật khẩu mới, nhận email và hoàn tất quá trình.

Điều này thuận tiện nếu email chỉ thuộc quyền kiểm soát của chủ sở hữu. Nhưng nếu ai đó có quyền truy cập vào email, quá trình phục hồi nhanh biến email thành đường dẫn trực tiếp tới tài khoản liên kết.

Trong MeldID, yêu cầu tạo mật khẩu mới đầu tiên chỉ cảnh báo chứ không thay đổi mật khẩu cũ ngay lập tức. Người dùng sẽ nhận được thông báo về truy vấn phục hồi, rồi sau đó hệ thống bắt đầu thời gian chờ định trước.

Thời gian chờ có thể thay đổi, nhưng nguyên tắc vẫn giữ nguyên: giữa yêu cầu và việc chính thức kích hoạt mật khẩu mới, có một khoảng thời gian để kiểm tra tình hình.

Mật khẩu cũ lúc này vẫn còn hiệu lực. Điều này có nghĩa là việc bắt đầu quá trình phục hồi chưa chắc đã chuyển quyền kiểm soát sang người khác.

Nếu ứng dụng không khả dụng

Cũng có thể dễ lầm tưởng một tình huống: người dùng có thể tự phục hồi mật khẩu nhưng không còn truy cập ứng dụng MeldID — điện thoại bị mất, hỏng, hết pin hoặc tạm thời không dùng được.

Trong trường hợp này, việc phục hồi vẫn có thể hoàn tất. Sau thời gian chờ cài đặt, mật khẩu mới sẽ tự động có hiệu lực. Ứng dụng di động không bắt buộc trong quy trình phục hồi tiêu chuẩn.

Do đó, người đã tự kích hoạt đổi mật khẩu và không thể mở ứng dụng, không cần bắt đầu lại quy trình. Chỉ cần đợi quá trình kết thúc và đăng nhập bằng mật khẩu mới.

Nếu ứng dụng còn khả dụng, còn nhiều khả năng hơn: người dùng có thể kích hoạt ngay mật khẩu mới hoặc hủy yêu cầu đáng ngờ. Nếu không có quyền truy cập, quá trình phục hồi hoãn lại vẫn tiếp tục hoạt động bình thường.

Người dùng tự quyết định xử lý tiếp theo

Nếu quá trình phục hồi thực sự do chủ sở hữu tài khoản khởi tạo và họ còn trong tay ứng dụng, họ có thể mở MeldID và kích hoạt mật khẩu mới ngay, không cần chờ hết thời gian chờ.

Nếu yêu cầu này là bất ngờ, có thể hủy bỏ trong ứng dụng. Trong trường hợp này, mật khẩu mới sẽ không có hiệu lực và mật khẩu cũ vẫn giữ nguyên.

Điều này là một thay đổi quan trọng trong logic phục hồi. Hệ thống không xem bất kỳ yêu cầu nào là hợp lệ chỉ vì nó được gửi qua email. Chủ sở hữu tài khoản có thể can thiệp và quyết định qua thiết bị đáng tin cậy.

Chẳng hạn, người dùng nhận thông báo thay đổi mật khẩu mà họ không yêu cầu, hủy bỏ thao tác trong ứng dụng rồi kiểm tra email, thiết bị và tìm nguyên nhân hoạt động đáng ngờ.

MeldID không thể khôi phục quyền kiểm soát hộp thư bị xâm phạm, nhưng có thể ngăn việc xâm phạm email dẫn đến việc đặt mật khẩu mới cho tài khoản chính ngay lập tức.

Chế độ hoảng loạn thu hồi các truy cập hoạt động

Đổi mật khẩu hoãn giúp thời gian để ứng phó. Chế độ hoảng loạn dành cho những tình huống khi đó là chưa đủ, và người dùng muốn chấm dứt ngay các truy cập đã cấp trước đó.

Chế độ này kích hoạt từ ứng dụng di động chỉ bằng một thao tác.

Sau khi kích hoạt, hệ thống thu hồi các token — các khóa truy cập, xác định trạng thái đã được đăng nhập của người dùng. Đồng thời, mọi phiên hoạt động hiện tại trên thiết bị di động và web liên kết cũng bị kết thúc.

Điều này không chỉ dừng phiên trên điện thoại, mà còn ngăn truy cập trên các điện thoại, máy tính bảng, trình duyệt và ứng dụng đã đăng nhập trước đó.

Chế độ này có thể hoạt động trong một khoảng thời gian nhất định, có thể thay đổi, nhưng nguyên tắc chính là các truy cập hiện tại bị thu hồi, và người dùng có thời gian kiểm tra tình hình một cách an toàn.

Chế độ hoảng loạn không xóa dữ liệu

Tiêu đề chế độ có thể nghe có vẻ dữ dội, nên cần giải thích rõ nó không làm gì với dữ liệu người dùng.

Chế độ hoảng loạn không xóa bỏ ghi chú TOTP, hồ sơ đã lưu, cài đặt hay dữ liệu cá nhân khác. Nó không xóa nội dung tài khoản hay biến nó thành trống rỗng.

Thay đổi duy nhất là trạng thái truy cập: các token hợp lệ bị thu hồi, các phiên mở bị đóng. Khi tài khoản trở lại chế độ bình thường, dữ liệu lưu trữ vẫn còn nguyên, không cần họ phải thêm lại từ đầu.

Điều này phân biệt rõ giữa việc chấm dứt truy cập khẩn cấp và xóa nội dung tài khoản. Người dùng có thể ngắt các kết nối hiện tại mà không sợ mất các ghi chú hay cài đặt.

Điều gì xảy ra khi đổi mật khẩu trong chế độ hoảng loạn

Chế độ hoảng loạn còn có quy tắc quan trọng khác: nó sẽ chấm dứt mọi yêu cầu đổi mật khẩu chưa hoàn tất.

Không quan trọng là yêu cầu đổi mật khẩu được gửi trước hay trong khi chế độ hoảng loạn còn hiệu lực. Yêu cầu đó sẽ không tự hoàn tất sau khi chế độ bảo vệ kết thúc.

Sau khi kết thúc chế độ này, mật khẩu còn hiệu lực là mật khẩu đã đặt trước khi kích hoạt trạng thái này.

Điều này là cố ý.

Thông thường, quy trình phục hồi cho phép chủ sở hữu bỏ qua yêu cầu bất kỳ khi nào nhận thấy hoạt động đáng ngờ trong MeldID, trước khi mật khẩu mới có hiệu lực.

Trong chế độ hoảng loạn, không thể dựa vào kịch bản này nữa.

Chẳng hạn, nếu người dùng phát hiện hoạt động bất thường và kích hoạt chế độ, thì nếu để quá trình tự phục hồi bình thường tiếp tục, kẻ xấu có thể yêu cầu tạo mật khẩu mới trong thời gian chế độ này còn hiệu lực. Nếu thời gian chờ kết thúc trước khi chế độ kết thúc, mật khẩu mới sẽ mất hiệu lực trước khi tài khoản trở lại bình thường.

Điều này dẫn đến nghịch lý: người dùng kích hoạt chế độ bảo vệ, nhưng chính trong thời gian đó, hệ thống cho phép đổi mật khẩu mà không cho chủ sở hữu hủy bỏ qua qua ứng dụng.

Vì vậy, chế độ hoảng loạn không tạm dừng quá trình phục hồi để tiếp tục sau này. Nó chấm dứt các yêu cầu chưa hoàn tất.

Các yêu cầu trong trước khi kích hoạt chế độ sẽ không thể thay đổi mật khẩu sau khi chế độ kết thúc. Các yêu cầu mới trong thời gian bảo vệ cũng không thể làm điều này.

Vì thế, không có gì của quá trình phục hồi chưa hoàn tất vượt qua ranh giới chế độ hoảng loạn.

Nếu người dùng muốn đổi mật khẩu trước

Chế độ hoảng loạn không giới hạn người dùng trong việc lựa chọn hành động tiếp theo.

Nếu người dùng còn trong tay ứng dụng MeldID và muốn đổi mật khẩu, có thể bắt đầu quy trình đổi ngay, rồi xác nhận mật khẩu mới trong ứng dụng.

Trong trường hợp này, quá trình đổi sẽ kết thúc trước khi chế độ hoảng loạn bắt đầu.

Sau đó, người dùng kích hoạt chế độ bảo vệ với mật khẩu mới đã có hiệu lực. Chính mật khẩu này sẽ còn hiệu lực sau khi chế độ kết thúc.

Cũng có thể ban đầu bật hoảng loạn, xác định nguyên nhân hoạt động đáng ngờ, rồi sau đó, khi mọi thứ ổn, bắt đầu quá trình đổi mật khẩu mới nếu cần.

Ý nghĩa của cơ chế là không bắt buộc người dùng phải hành động theo một trình tự cố định. Quy tắc chính là: các yêu cầu đổi mật khẩu chưa hoàn tất sẽ không tồn tại qua chế độ hoảng loạn.

Chế độ hoảng loạn giúp lấy lại quyền kiểm soát email

Có kịch bản đặc biệt mà cơ chế này trở nên cực kỳ hữu ích: đó là người dùng tin vào vấn đề không nằm ở MeldID hay điện thoại, mà ở email.

Chính email được dùng làm kênh khôi phục, nên sự xâm phạm email nguy hiểm kể cả khi mật khẩu MeldID còn chưa bị biết bởi kẻ khác.

Trong tình huống này, người dùng có thể kích hoạt chế độ, rồi tập trung xử lý nguyên nhân chính: khôi phục quyền truy cập email, đổi mật khẩu, chấm dứt các phiên không rõ, kiểm tra cài đặt bảo mật.

Trong thời gian chế độ hoảng loạn hoạt động, MeldID không cho phép quá trình phục hồi tạo ra mật khẩu mới hợp lệ.

Nếu ai đó đã yêu cầu phục hồi trước khi chế độ bật, yêu cầu đó sẽ không thể vượt qua trạng thái bảo vệ. Nếu yêu cầu mới xuất hiện trong lúc này, kết quả cũng tương tự.

Điều này tạo ra một khoảng thời gian bảo vệ: các truy cập MeldID đã bị thu hồi, email có thể bị xâm phạm không thể dùng để tạo mật khẩu mới cho tới khi chế độ kết thúc, và chủ sở hữu có thời gian lấy lại quyền kiểm soát email.

Sau khi chế độ kết thúc, mật khẩu MeldID cũ vẫn còn hiệu lực. Nếu quyền truy cập email đã khôi phục và không có triệu chứng bất thường nào khác, người dùng có thể tiếp tục dùng tài khoản bình thường.

Nếu qua kiểm tra, họ muốn đổi mật khẩu MeldID, có thể làm sau đó một cách riêng biệt.

Các lý do để bật chế độ hoảng loạn là gì

Khởi động chế độ không đòi hỏi phải xác minh đã bị tấn công trước đó.

Điện thoại có thể rơi vào tay kẻ lạ. Phiên không rõ có thể xuất hiện trong danh sách thiết bị. Người dùng có thể nhận thông báo bất ngờ về đăng nhập hoặc phục hồi. Đôi khi, nghi ngờ đến từ nhiều dấu hiệu nhỏ chứ không chỉ một sự kiện rõ ràng.

Trong hoàn cảnh đó, người dùng không nhất thiết phải điều tra kỹ càng trước khi thực hiện hành động bảo vệ đầu tiên. Đôi khi, an toàn hơn là tạm thời thu hồi các quyền truy cập rồi sau đó xem xét chi tiết.

Trong logic của MeldID, nếu chủ sở hữu cảm thấy tình huống nguy hiểm, còn có quyền truy cập vào ứng dụng đáng tin cậy, họ có thể kích hoạt chế độ này ngay lập tức. Hệ thống không yêu cầu chứng minh rõ ràng rằng đang bị tấn công trước.

Tại sao đổi mật khẩu không đủ

Mật khẩu chỉ là một phần của quá trình xác thực. Nếu có phiên đã hoạt động hoặc token truy cập đã cấp, đổi mật khẩu chỉ riêng chưa đủ để vô hiệu tất cả truy cập cũ đã cấp.

Chính vì thế, chế độ hoảng loạn hoạt động rộng hơn. Nó không chỉ đổi một thiết lập từng phần của tài khoản, mà đặt toàn bộ tài khoản vào trạng thái bảo vệ đặc biệt.

Các bước diễn ra như sau:

1. Thu hồi các phiên và token đang hoạt động;

2. Chấm dứt các yêu cầu đổi mật khẩu chưa hoàn tất trước đó;

3. Yêu cầu phục hồi trong thời gian chế độ, không thể thay đổi mật khẩu sau khi chế độ kết thúc;

4. Mật khẩu hiện có sẽ còn hiệu lực trong quá trình này;

5. Người dùng có thời gian kiểm tra email, thiết bị và các nguồn khác;

6. Sau khi thoát chế độ, tài khoản trở lại trạng thái bình thường hoặc có thể đổi mật khẩu nếu cần.

Chế độ này không thay thế các biện pháp bảo vệ tiêu chuẩn, mà là một kịch bản khẩn cấp trong tình huống mất niềm tin tạm thời vào trạng thái truy cập.

Ứng dụng di động như một điểm tin cậy

Các tính năng mới có trong ứng dụng MeldID cho iPhone và Android. Trong kiến trúc này, điện thoại không chỉ là thiết bị đăng nhập nữa, mà còn là điểm quản lý bảo mật đáng tin cậy của tài khoản.

Thông qua ứng dụng, người dùng có thể:

• Xác nhận đổi mật khẩu hoãn lại;

• Hủy yêu cầu đáng ngờ;

• Kích hoạt chế độ hoảng loạn;

• Chấm dứt các phiên hoạt động trên các thiết bị khác;

• Xác định các hành động khác cho tài khoản.

Ứng dụng không hủy bỏ TOTP hay thay thế các phương pháp bảo vệ khác. Nó cung cấp một kênh quản lý riêng cho các tình huống mà xác thực thông thường không đủ để đảm bảo an toàn cho tài khoản.

Ranh giới bảo vệ của MeldID

Quan trọng là phân biệt giữa an toàn của chính cơ chế MeldID và an toàn của môi trường sử dụng.

MeldID được thiết kế để chính dịch vụ không tạo ra kênh thông thường để lấy mật khẩu thực sự. Mật khẩu do hệ thống tự tạo, không do người dùng chọn hoặc gửi qua email. Quá trình phục hồi cũng không hé lộ mật khẩu hiện tại, mà bắt đầu tạo một mật khẩu mới.

Người dùng vẫn còn có thể tự rò rỉ thông tin của mình, ví dụ chia sẻ với người khác hoặc nhập ở những nơi không an toàn.

Mức độ an toàn thứ cấp liên quan đến bảo vệ thiết bị và hệ điều hành của nó. Ứng dụng di động hoạt động bên trong các cơ chế bảo vệ của iOS và Android, không thể thay thế hay xâm phạm nền tảng.

Chính vì vậy, MeldID tập trung vào những rủi ro mà hệ thống có thể kiểm soát: sinh dữ liệu đăng nhập, xác thực, token, phiên, phục hồi và phản ứng với các xâm phạm tiềm năng của kênh phục hồi.

Từ đăng nhập đến phản ứng

Khi lần đầu làm quen với MeldID, có thể mô tả nó như một hệ thống nhận dạng và quản lý hồ sơ thống nhất. Sau khi ra mắt các ứng dụng di động và các cơ chế bảo vệ mới, mô tả này trở nên quá hẹp.

Bây giờ, hệ thống không chỉ trả lời câu hỏi “làm thế nào để đăng nhập?”, mà còn các câu hỏi phức tạp hơn:

• Phải làm gì khi có một yêu cầu phục hồi bất ngờ;

• Làm thế nào khôi phục tài khoản nếu không còn truy cập ứng dụng;

• Làm thế nào có thêm thời gian kiểm tra trước khi kích hoạt mật khẩu mới;

• Làm thế nào hủy bỏ phục hồi không phải của chủ sở hữu;

• Làm thế nào thu hồi các phiên đang hoạt động;

• Làm thế nào ngăn email bị xâm phạm đổi mật khẩu trong chế độ khẩn cấp;

• Làm thế nào lấy lại quyền kiểm soát kênh phục hồi bên ngoài;

• Làm thế nào giữ các dữ liệu người dùng khi chấm dứt tất cả truy cập hoạt động;

• Làm thế nào trở lại trạng thái bình thường sau khi kiểm tra tình hình.

Kết quả là, một mô hình bảo vệ tuần tự được hình thành.

Mật khẩu hoạt động của MeldID không được truyền qua kênh phục hồi. Việc truy cập email không tự tiết lộ mật khẩu, nhưng có thể giúp kích hoạt quá trình tạo mật khẩu mới. Chính vì vậy, quá trình phục hồi bị trì hoãn và có thể bị hủy bỏ qua ứng dụng đáng tin cậy.

Nếu vẫn còn chưa đủ, chế độ hoảng loạn sẽ chấm dứt các phiên hoạt động, thu hồi token và không cho phép quá trình phục hồi chưa xong lưu lại sau thời gian bảo vệ.

Người dùng nhận được thứ đặc biệt quan trọng trong tình huống thực: thời gian.

Thời gian để lấy lại quyền kiểm soát email, kiểm tra thiết bị, xử lý vấn đề rồi mới mở lại truy cập bình thường.

Chính vì lý do này, chế độ hoảng loạn của MeldID không chỉ là nút “đăng xuất tất cả”. Đó là một kịch bản phản ứng riêng biệt cho tình huống khi xác thực thông thường không còn đủ, và trước tiên phải lấy lại niềm tin vào môi trường của tài khoản.

Chi tiết dự án tại: meldid.de.