Hiểu danh tính và xác thực với mật khẩu, MFA, passkeys và SSO; đối chiếu NIST 800-63B-4, thực hành salt và băm, lập đường khôi phục tài khoản phù hợp.
Một nhân viên đổi mật khẩu rất dài nhưng vẫn bị chiếm tài khoản vì nhập nó vào trang giả. Người khác bật MFA nhưng chấp thuận thông báo đăng nhập mà họ không khởi tạo. Độ dài và số bước xác thực đều có giá trị, song cần hiểu cơ chế, điểm tin cậy và đường khôi phục để sử dụng đúng.
Sau bài này, bạn phân biệt danh tính, xác thực, phân quyền và ghi nhận hoạt động; chọn cách quản lý mật khẩu, MFA và passkeys phù hợp; giải thích salt, băm mật khẩu cùng quy trình khôi phục. Kiến thức tiên quyết là khóa mật mã, TLS và bảo vệ thiết bị.
Bài tham chiếu mục tiêu 025.1 của giáo trình Security Essentials 020-100, PDF phiên bản 2026-04-15, trang in 264–281. Ví dụ và lab được biên soạn độc lập, đối chiếu nguồn ngày 23/10/2026. Thử nghiệm chỉ dùng mật khẩu DEMO công khai với Python 3.14.4 trong container Ubuntu 26.04.1 ARM64 riêng. Không đăng ký passkey, bật MFA, đổi tài khoản thật hoặc kiểm thử ngân hàng.
Một định danh như tên đăng nhập cho biết tài khoản đang được nhắc tới. Xác thực kiểm tra khả năng kiểm soát phương tiện xác thực gắn với tài khoản, không tự chứng minh toàn bộ danh tính ngoài đời. Việc kiểm tra giấy tờ khi mở dịch vụ là một quá trình khác với xác thực khi quay lại.
Phân quyền quyết định tài khoản được làm gì trên tài nguyên. Ghi nhận hoạt động cung cấp dữ liệu để kiểm tra và truy vết theo phạm vi log. Một lần đăng nhập thành công không tự cấp quyền quản trị. Một dòng log lúc 03:00 cũng chưa chứng minh ai trực tiếp thao tác; cần xét múi giờ, tác vụ tự động, phiên và khả năng tài khoản bị chiếm.
Ví dụ giả định ID39-A: người dùng đăng nhập được nhưng không sửa được hồ sơ chung. Help Desk cần kiểm tra quyền và nhóm đúng tài nguyên, không đặt lại mật khẩu ngay. ID39-B: mật khẩu đúng nhưng thiết bị chưa được phép truy cập. Cần đọc điều kiện chính sách, không hạ bảo vệ để biến kết nối thành công.
NIST SP 800-63B-4, phần yêu cầu mật khẩu, quy định tối thiểu 15 ký tự khi chỉ dùng mật khẩu; trong quy trình MFA có thể cho phép ngắn hơn nhưng ít nhất tám. Tài liệu không yêu cầu trộn loại ký tự hoặc đổi định kỳ, nhưng yêu cầu đổi khi có bằng chứng bị xâm phạm. Đây là chuẩn hướng dẫn có phạm vi áp dụng, không tự thay chính sách của mọi tổ chức.
Người dùng nên tạo giá trị riêng cho từng dịch vụ, tránh thông tin dễ đoán và các biến thể như thêm năm ở cuối. Độ dài không khắc phục việc nhập vào website giả, keylogger hoặc dùng lại cùng bí mật. Khi tổ chức vẫn có quy tắc riêng, thực hiện quy trình được duyệt và chuyển góp ý cải tiến tới người quản trị, không tự tắt yêu cầu.
Brute force thử nhiều khả năng; dictionary attack ưu tiên từ hoặc mẫu có khả năng; credential stuffing thử thông tin đã lộ trên dịch vụ khác. Giới hạn thử đăng nhập hỗ trợ chống đoán trực tuyến, nhưng kẻ có dữ liệu băm có thể đoán ngoại tuyến. Vì thế cần cả hành vi người dùng và cách lưu của dịch vụ.
Trình quản lý giúp sinh giá trị ngẫu nhiên, giữ chúng theo dịch vụ và giảm gánh nặng ghi nhớ. Dữ liệu vault cần được bảo vệ bằng bí mật mở khóa phù hợp, bảo vệ thiết bị và phương án khôi phục. Không coi vault đang mở trên máy nhiễm là an toàn chỉ vì tệp lưu trữ đã mã hóa.
KeePassXC hướng dẫn tạo và lưu database, với tài liệu mang phiên bản 2.7.11. Đây là ví dụ công cụ quản lý vault cục bộ, không phải phiên bản ứng dụng đã chạy trong lab. Cần giữ tệp database cùng đường mở khóa, có bản sao và thử khôi phục; không đặt mật khẩu mở vault trong chính tệp mà bạn không thể mở.
Câu hỏi bảo mật dựa vào nơi sinh hoặc tên người thân dễ bị đoán từ thông tin công khai. Không dùng chúng như bằng chứng mạnh để bỏ qua quy trình khôi phục; chọn phương án dịch vụ và tổ chức hỗ trợ.
Cục bộ và cloud có đánh đổi về đồng bộ, khả dụng, kiểm soát và khôi phục. Không thể kết luận cục bộ luôn an toàn hơn hoặc cloud luôn truy cập được. Khi xuất CSV, dữ liệu có thể thành bản rõ; chỉ thực hiện theo quy trình và bảo vệ bản xuất. Trong công việc, dùng vault được phê duyệt thay cho gửi mật khẩu qua chat hoặc ghi vào ticket.
MFA dùng các yếu tố khác loại, như điều bạn biết và vật bạn kiểm soát. Hai mật khẩu không tự thành hai yếu tố. Số màn hình cũng không bằng số yếu tố: một phương tiện mật mã có thể yêu cầu PIN hoặc sinh trắc học để kích hoạt. Cách đánh giá phụ thuộc thiết kế, không chỉ giao diện.
TOTP dựa trên bí mật chia sẻ và thời gian theo RFC 6238, không phải mỗi bên tự chọn số ngẫu nhiên rồi tình cờ trùng. Sai giờ hoặc sai tài khoản có thể làm mã không khớp. QR khi đăng ký thường chứa bí mật để tạo mã; không gửi nó cho Help Desk hoặc đăng ảnh lên diễn đàn.
OTP và thông báo chấp thuận vẫn có thể bị lừa chuyển tiếp hoặc chấp thuận sai. Khi không tự khởi tạo, từ chối yêu cầu và báo theo kênh chính thức. Không đọc OTP cho người gọi tự xưng hỗ trợ. Việc đặt lại bằng email cũng không mặc định chứng minh có hai yếu tố độc lập.
FIDO Alliance mô tả passkeys dùng xác thực mật mã khóa công khai và được thiết kế chống phishing. Credential gắn với dịch vụ giúp tránh đưa bí mật dùng chung cho trang giả. Không diễn giải thành chống mọi chiếm tài khoản: phiên bị đánh cắp, thiết bị nhiễm, đăng ký sai hoặc đường khôi phục yếu vẫn cần xem xét.
Passkey có thể gắn thiết bị hoặc được đồng bộ tùy hệ sinh thái. Người dùng cần biết cách thêm phương án dự phòng và xử lý mất thiết bị theo dịch vụ. Help Desk hướng dẫn trên tài liệu được duyệt; không giữ PIN, khóa riêng hoặc mã khôi phục của người dùng trong ghi chú hỗ trợ.
SSO cho phép các ứng dụng dựa vào nhà cung cấp danh tính trong quy trình đã thiết lập. OpenID Foundation giải thích OpenID Connect là giao thức xác thực dựa trên OAuth 2.0. Đừng đồng nhất việc cho ứng dụng quyền đọc dữ liệu với đăng nhập, hoặc hiểu mọi token đều là mật khẩu đã mã hóa.
Khi ứng dụng xin quyền, đọc tên ứng dụng, đơn vị phát hành, phạm vi và nhu cầu công việc. Một dịch vụ lên lịch đăng bài không mặc định cần toàn quyền tài khoản. Mất tài khoản IdP có thể ảnh hưởng nhiều dịch vụ; cần kế hoạch khôi phục và thu hồi quyền ứng dụng. Đăng xuất một màn hình chưa đủ bằng chứng mọi phiên và token đã hết hiệu lực.
Băm dùng cho kiểm tra giá trị, khác mã hóa có thể giải mã bằng khóa. Không có thao tác “giải mã hash” thông thường, nhưng mật khẩu yếu vẫn có thể bị đoán rồi so kết quả. Salt riêng làm cùng mật khẩu tạo giá trị khác và hạn chế tái sử dụng bảng tính sẵn, không biến mật khẩu yếu thành không đoán được.
OWASP Password Storage Cheat Sheet ưu tiên thuật toán thích hợp như Argon2id với cấu hình được chọn đúng; SHA-256 nhanh dùng đơn lẻ không phù hợp để lưu mật khẩu. Hệ thống thật nên dùng thư viện và framework đã được rà soát, có tham số, nâng cấp và giới hạn thử phù hợp.
Đoạn Python sau dùng API scrypt của hashlib để minh họa. Tham số nhẹ n=2**14, r=8, p=1 chỉ dành cho bài thử nhỏ, thấp hơn cấu hình scrypt tối thiểu chính được OWASP nêu; không chép làm cấu hình production. Chỉ dùng giá trị DEMO, không nhập mật khẩu thật.
import hashlib
import hmac
import secrets
params = dict(n=2**14, r=8, p=1, dklen=32)
password = b'DEMO-only-public-example'
salt_a = secrets.token_bytes(16)
salt_b = secrets.token_bytes(16)
stored_a = hashlib.scrypt(password, salt=salt_a, **params)
stored_b = hashlib.scrypt(password, salt=salt_b, **params)
def verify(candidate):
derived = hashlib.scrypt(candidate, salt=salt_a, **params)
return hmac.compare_digest(stored_a, derived)
print('different salted values:', stored_a != stored_b)
print('correct:', verify(password))
print('wrong:', verify(b'DEMO-wrong'))
Mong đợi lần lượt True, True, False. Salt không phải bí mật phải giấu như mật khẩu; hệ thống cần salt và tham số tương ứng để kiểm tra lại. So sánh hai giá trị khác nhau không xác định người dùng đã chọn hai mật khẩu khác nhau.
Trong lần kiểm chứng với Python 3.14.4, ba kết quả đúng; harness còn xác nhận dùng sai salt không khớp. Chạy nonroot, mạng tắt, root filesystem chỉ đọc, dữ liệu ở bộ nhớ. Không triển khai đăng nhập, đo độ chống bẻ khóa, kiểm thử timing, MFA hay passkey; tài liệu Python 3.14 trực tuyến có thể hiển thị patch mới hơn binary đã thử.
Email thường là đường nhận thông báo và khôi phục của nhiều tài khoản, nên cần ưu tiên bảo vệ. Nếu nghi bị chiếm, kiểm tra phiên, phương thức khôi phục và quy tắc chuyển tiếp theo hướng dẫn nhà cung cấp. Đổi mật khẩu đơn lẻ có thể chưa xử lý mọi phiên, token hoặc quyền ứng dụng còn tồn tại.
Cảnh báo rò rỉ là dữ kiện để xác minh qua trang chính thức, không nhấp liên kết gấp gáp trong thư lạ. Không nhập mật khẩu hiện tại vào một website kiểm tra không rõ nguồn. Khi có bằng chứng lộ, đổi giá trị liên quan và xử lý những nơi dùng lại qua thiết bị đáng tin.
Với ngân hàng và thẻ, tự mở ứng dụng hoặc URL chính thức, kiểm tra nội dung giao dịch trước xác nhận và dùng kênh liên hệ lấy độc lập khi có bất thường. Không dùng máy lạ để “thử đăng nhập”, không đọc OTP hoặc mã khôi phục cho người gọi. Bài không đưa quy định hay quy trình riêng của một ngân hàng.
Tự kiểm tra ID39-C: người dùng nhớ mật khẩu nhưng mất thiết bị MFA. Không bỏ yếu tố chỉ vì họ biết thông tin cá nhân; thực hiện khôi phục được duyệt, ghi căn cứ và quyền thay đổi. Hoàn thành yêu cầu khi người dùng truy cập lại đúng quyền, phương tiện bị mất được xử lý và các điểm chưa xác nhận được bàn giao rõ ràng.
Học bảo vệ quyền riêng tư qua cookie, fingerprinting, hồ sơ và quyền dữ liệu; thực hành quan sát cookie trong lab riêng, phân biệt xóa cục bộ và log server.
Học giao tiếp an toàn qua phishing, tệp đính kèm, phân loại thông tin và quyền cloud; thực hành xác minh người nhận, giảm dữ liệu và xử lý chia sẻ nhầm.
Phân biệt mã hóa mạng và ẩn danh với VPN, proxy, Tor và E2EE; đọc ranh giới bảo vệ, hiểu bút danh blockchain qua bốn tình huống thực hành giả định.
Học bảo mật mạng và Internet qua Wi-Fi, TLS, DoS/DDoS và bộ lọc gói; thực hành quy tắc hẹp trong lab riêng, kiểm tra tác động và phục hồi kết nối.