Định danh (Identification) và xác thực (Authentication)
1. Tổng quan
A. Định nghĩa
Định danh (Identification) là hành vi khẳng định·phân biệt chủ thể bằng cách nói với hệ thống “tôi là ai”, còn xác thực (Authentication) là hành vi kiểm chứng rằng khẳng định đó là thật. Nếu định danh là tiết lộ danh tính, thì xác thực là xác nhận danh tính đó có thực sự đúng hay không.
Cốt lõi để phân biệt hai khái niệm nằm ở chỗ “khẳng định (claim) và chứng minh (proof) là khác nhau”. Định danh là bước người dùng cho biết mình là ai; tiêu biểu là nhập ID vào màn hình đăng nhập hoặc xuất trình mã nhân viên trên thẻ nhân viên. Tuy nhiên, ID chỉ là nhãn tên để xác định duy nhất (unique identifier) chủ thể trong hệ thống, hoàn toàn không đảm bảo người đó có thật sự là người đó hay không. Bởi vì ai cũng có thể nhập ID của người khác.
Vì vậy cần có xác thực. Xác thực kiểm chứng “bạn có thật sự là người đó không” bằng yếu tố xác thực (authentication factor) như mật khẩu·thông tin sinh trắc·token sở hữu. Ví von với quầy giao dịch ngân hàng, việc nói tên là định danh, còn xuất trình giấy tờ tùy thân để chứng minh là chính mình là xác thực. Kết quả của định danh là “xác định chủ thể (là ai)”, còn kết quả của xác thực là “phán định đúng/sai (có đúng không)”, nên bản thân đầu ra của hai bước đã khác nhau.
Bên cạnh hai bước này, tiếp nối là cấp quyền (Authorization) — xác định người dùng đã xác thực được làm gì, và trách nhiệm giải trình (Accountability)·chống chối bỏ (Non-repudiation) — ngăn việc phủ nhận hành vi. Trong hệ thống thường gọi là AAA (Authentication·Authorization·Accounting), chuỗi định danh→xác thực→cấp quyền→kiểm toán (ghi log) tạo thành khung xương cơ bản của kiểm soát truy cập (Access Control). Nếu định danh yếu thì bản thân đối tượng xác thực trở nên mơ hồ, nếu xác thực yếu thì mọi phán đoán quyền hạn sau cấp quyền đều sụp đổ, nên bốn bước phải được hiểu như một chuỗi mắt xích.
B. Bối cảnh ra đời và sự cần thiết
Định danh·xác thực trở thành điểm xuất phát của an toàn thông tin vì một lý do căn bản: nếu không xác định được “ai” truy cập tài nguyên (dữ liệu·hệ thống) thì không thể bảo vệ bất kỳ thuộc tính nào trong bí mật·toàn vẹn·sẵn sàng (CIA). Không xác định được chủ thể truy cập thì cũng không thể cấp quyền hay truy vết trách nhiệm khi sự cố xảy ra. Ban đầu, người ta cho rằng chỉ ID/mật khẩu (ID/PW) là đủ, nhưng khi mật khẩu bị lộ hàng loạt do phishing·credential stuffing·rò rỉ dữ liệu, giới hạn của xác thực một yếu tố trở nên rõ ràng.
Đặc biệt, với sự lan rộng của đám mây·di động·làm việc từ xa, đường truy cập đã vượt ra ngoài ranh giới “bên trong mạng nội bộ”, khiến tiền đề “tin vì đang ở trong mạng” sụp đổ. Theo đó, mô hình Zero Trust (không tin cậy mặc định) kiểm chứng lại danh tính ở mỗi lần truy cập đã xuất hiện, và định danh·xác thực được đánh giá lại không còn là thủ tục phụ của bảo mật mà là trục trung tâm của kiến trúc. Ngày nay, định danh·xác thực được hiểu không phải là “qua một lần là xong” mà là “quá trình kiểm chứng liên tục”.
C. Khác biệt giữa định danh cá nhân và xác thực người dùng
| Tiêu chí | Định danh (Identification) | Xác thực (Authentication) |
|---|---|---|
| Ý nghĩa | Khẳng định·phân biệt danh tính | Kiểm chứng tính xác thực của khẳng định |
| Câu hỏi cốt lõi | “Bạn là ai?” | “Có thật sự là người đó không?” |
| Ví dụ đầu vào | ID·mã nhân viên·email | Mật khẩu·vân tay·OTP |
| Kết quả đầu ra | Xác định chủ thể (định danh duy nhất) | Xác nhận danh tính (đúng/sai) |
| Mức bảo mật | Có thể công khai (không phải bí mật) | Bắt buộc bí mật·có thể kiểm chứng |
Như bảng cho thấy, về nguyên tắc định danh “không phải là bí mật”. ID hay email dù bị lộ thì bản thân nó không khiến tài khoản bị chiếm đoạt. Ngược lại, yếu tố xác thực bị lộ thì tài khoản bị xâm nhập ngay lập tức. Vì khác biệt này, mức quản lý (mã hóa·cách lưu trữ·bảo vệ truyền tải) của định danh và thông tin xác thực phải khác nhau về căn bản. Đây chính là lý do thiết kế coi định danh như phương tiện xác thực (ví dụ: tập quán lấy số đăng ký cư trú hay số điện thoại làm xác thực luôn) là nguy hiểm.
2. Luồng xử lý và cấu trúc tổng thể của định danh·xác thực·cấp quyền
Trước hết xem xét cấu trúc tổng thể của kiểm soát truy cập bằng sơ đồ khái niệm, sau đó giải thích quá trình xử lý yêu cầu xác thực bằng sơ đồ luồng chi tiết.
flowchart TB
U[Người dùng/chủ thể] --> ID["Định danh<br/>(khẳng định danh tính: ID)"]
ID --> AU["Xác thực<br/>(kiểm chứng: PW·sinh trắc·token)"]
AU --> AZ["Cấp quyền<br/>(trao quyền: quyết định truy cập)"]
AZ --> AC["Kiểm toán/truy vết trách nhiệm<br/>(ghi log·chống chối bỏ)"]
AC --> R[Truy cập tài nguyên được bảo vệ]
style AU fill:#e8f0fe,stroke:#2f6fed,stroke-width:2px
style AZ fill:#fef3e8,stroke:#ed8a2f,stroke-width:2px
Sơ đồ cấu trúc trên thể hiện bốn cửa ải mà một yêu cầu truy cập phải đi qua trước khi đến được tài nguyên. Mỗi cửa ải lấy kết quả của bước trước làm tiền đề tin cậy. Nếu xác thực không thông qua thì phán đoán cấp quyền vô nghĩa, và thông tin chủ thể lưu trong log kiểm toán cũng chỉ đáng tin khi định danh·xác thực chính xác. Tức là giá trị bảo mật của bước sau phụ thuộc vào độ chính xác của bước trước.
Tiếp theo là luồng chi tiết hóa quá trình một yêu cầu xác thực thực tế được kiểm chứng tại máy chủ. Luồng này thể hiện cả cách xác thực lẫn nhau và chống phát lại can thiệp vào.
sequenceDiagram
participant C as Máy khách (người dùng)
participant S as Máy chủ xác thực
participant D as Kho thông tin xác thực
C->>S: 1. Gửi định danh (ID)
S->>C: 2. Gửi challenge (nonce/giá trị ngẫu nhiên)
C->>S: 3. Phản hồi thông tin xác thực (hash·chữ ký·OTP)
S->>D: 4. Tra cứu hash/khóa đã lưu
D-->>S: 5. Trả về giá trị để kiểm chứng
S->>S: 6. Đối chiếu·kiểm tra phát lại·đánh giá chính sách
S-->>C: 7. Nếu thành công cấp token phiên
Cốt lõi của luồng chi tiết này là kiểm chứng theo phương thức challenge-response để mật khẩu dạng gốc không đi qua mạng. Nếu máy chủ mỗi lần gửi một nonce khác nhau và máy khách phản hồi có kèm nonce đó, thì dù kẻ tấn công chặn và phát lại (Replay) phản hồi cũng sẽ thất bại vì nonce khác. Ở bước 6 “đánh giá chính sách”, không chỉ xét việc khớp hay không mà còn xem xét cả ngữ cảnh như vị trí truy cập·thiết bị·thời gian. Đây là điểm tiếp giáp với xác thực thích ứng sẽ được giải thích ở phần sau.
3. Yêu cầu bảo mật khi xác thực người dùng
Để hệ thống xác thực an toàn, không chỉ độ mạnh của từng yếu tố mà toàn bộ hệ thống phải đồng thời đáp ứng nhiều yêu cầu. Các yêu cầu không độc lập với nhau mà hoạt động bổ trợ lẫn nhau.
| Yêu cầu | Nội dung | Kiểm soát tiêu biểu |
|---|---|---|
| Tính bí mật | Ngăn lộ thông tin xác thực (mật khẩu) | Hash có salt (bcrypt·Argon2)·TLS |
| Tính toàn vẹn | Ngăn giả mạo·sửa đổi thông tin xác thực·thông điệp | MAC·chữ ký số |
| Chống tái sử dụng | Phòng thủ tấn công phát lại (Replay) | OTP·nonce·dấu thời gian |
| Xác thực lẫn nhau | Kiểm chứng hai chiều máy chủ·người dùng | Chứng chỉ máy chủ·channel binding |
| Độ mạnh | Chống đoán·tấn công vét cạn | Chính sách độ phức tạp·MFA·khóa tài khoản |
Tính bí mật phải được bảo vệ ở cả hai giai đoạn lưu trữ và truyền tải. Mật khẩu phải được lưu không phải ở dạng gốc mà bằng hash chậm như bcrypt·scrypt·Argon2 sau khi thêm salt khác nhau cho mỗi tài khoản, để dù bị lộ vẫn chịu được rainbow table·bẻ khóa hàng loạt. Đoạn truyền tải được mã hóa bằng TLS để kẻ tấn công trung gian (MITM) không thấy bản rõ. Các trường hợp dịch vụ trước đây lưu bằng MD5·SHA đơn thuần bị bẻ khóa sau các vụ rò rỉ quy mô lớn cho thấy cách lưu trữ là tuyến phòng thủ cuối cùng của bảo mật xác thực.
Xác thực lẫn nhau thường bị bỏ qua nhưng là cốt lõi của phòng chống phishing. Nếu chỉ người dùng chứng minh bản thân còn máy chủ không chứng minh, trang giả mạo có thể đóng vai máy chủ hợp lệ để chặn thông tin xác thực của người dùng. Kiểm chứng chứng chỉ máy chủ của HTTPS và ràng buộc tên miền (xác nhận origin) của FIDO2 bắt buộc xác thực lẫn nhau, khiến thông tin xác thực không hoạt động trên trang phishing. Chống tái sử dụng là ngăn phản hồi xác thực đã dùng một lần bị tái sử dụng; thời gian hiệu lực 30 giây của OTP hay nonce đảm nhận vai trò này.
Không được chỉ đáp ứng một trong các yêu cầu này. Ví dụ, dù dùng mật khẩu mạnh (độ mạnh) nhưng truyền bản rõ (vi phạm tính bí mật) thì vô nghĩa, và dù giữ được tính bí mật nhưng không kiểm chứng máy chủ (vi phạm xác thực lẫn nhau) thì vẫn bị phishing xâm nhập. Bởi vì bảo mật sụp đổ ở mắt xích yếu nhất.
4. Bốn loại xác thực theo phương thức và xác thực đa yếu tố
Xác thực được chia thành bốn yếu tố tùy theo “chứng minh bằng gì”. Mỗi loại có nguyên lý khác nhau nên điểm mạnh và điểm yếu cũng trái ngược, và chính sự trái ngược này là căn cứ cho việc kết hợp (MFA).
| Loại | Căn cứ | Ví dụ | Điểm mạnh | Điểm yếu |
|---|---|---|---|---|
| Dựa trên tri thức | Điều biết (know) | Mật khẩu·PIN | Dễ hiện thực·chi phí thấp | Dễ bị lộ·đoán·tái sử dụng |
| Dựa trên sở hữu | Vật có (have) | OTP·thẻ thông minh·khóa bảo mật | Cần sở hữu vật lý | Nguy cơ mất·trộm·sao chép |
| Dựa trên sinh trắc | Bản thể (are) | Vân tay·mống mắt·khuôn mặt | Tiện lợi·duy nhất·không bị mất | Không thể thay đổi·nhận dạng sai (FAR/FRR) |
| Dựa trên hành vi·vị trí | Điều làm/vị trí | Chữ ký·kiểu gõ phím·GPS | Có thể xác thực không cần ý thức | Độ chính xác thấp nên dùng bổ trợ |
Dựa trên tri thức lâu đời nhất và được dùng rộng rãi nhất nhưng có nhiều điểm yếu căn bản. Mật khẩu mà con người có thể ghi nhớ bị giới hạn độ phức tạp, bị tái sử dụng trên nhiều trang, và khi một nơi bị lộ thì các tài khoản khác cũng bị xâm nhập qua credential stuffing. Việc về mặt thống kê, phần lớn các vụ chiếm đoạt tài khoản quy mô lớn bắt nguồn từ tái sử dụng mật khẩu cho thấy giới hạn bẩm sinh của loại này.
Dựa trên sở hữu đòi hỏi kẻ tấn công phải có được phương tiện vật lý nên mạnh trước các tấn công hàng loạt từ xa. OTP tạo giá trị dùng một lần đồng bộ theo thời gian (TOTP) hoặc sự kiện (HOTP) để vô hiệu hóa phát lại. Tuy nhiên, SMS OTP dễ bị tổn thương trước SIM swapping·phishing chuyển tiếp, nên gần đây khóa bảo mật phần cứng (FIDO2) hoặc ứng dụng xác thực được khuyến nghị. Dựa trên sinh trắc tiện lợi và không có nguy cơ mất, nhưng có đặc tính chí mạng là khi bị lộ thì không thể “cấp lại” như mật khẩu. Vì vậy, phương thức không gửi thông tin sinh trắc lên máy chủ mà lưu·đối chiếu trong vùng bảo mật của thiết bị (ví dụ: TEE·Secure Enclave) đã trở thành tiêu chuẩn.
Vì điểm yếu của mỗi loại khác nhau, xác thực đa yếu tố (MFA, Multi-Factor Authentication) kết hợp các loại khác nhau sẽ nâng cao bảo mật vượt bậc. Cốt lõi là “các loại khác nhau”. Yêu cầu hai mật khẩu vẫn chỉ là một loại dựa trên tri thức nên không phải MFA. Nếu dùng đồng thời mật khẩu (tri thức) và OTP (sở hữu), thì dù mật khẩu bị lộ, kẻ tấn công vẫn bị chặn vì không có thiết bị OTP. Thực tế, MFA được báo cáo là chặn được phần lớn các nỗ lực chiếm đoạt tài khoản hàng loạt tự động, và đó là lý do MFA được bắt buộc trong các hệ thống tài chính·công·doanh nghiệp.
Mặt khác, khi đánh giá xác thực sinh trắc phải xem đồng thời hai tỷ lệ lỗi. Tỷ lệ chấp nhận sai (FAR, False Acceptance Rate) là tỷ lệ chấp nhận nhầm người khác là chính chủ, gắn trực tiếp với rủi ro bảo mật; tỷ lệ từ chối sai (FRR, False Rejection Rate) là tỷ lệ từ chối chính chủ, gắn trực tiếp với khả năng sử dụng. Hai giá trị có quan hệ đánh đổi: siết ngưỡng thì một bên giảm và bên kia tăng, và điểm hai giá trị bằng nhau gọi là tỷ lệ lỗi cân bằng (EER, Equal Error Rate), được dùng làm chỉ số so sánh hiệu năng hệ thống sinh trắc. Thông thường, môi trường bảo mật cao điều chỉnh ngưỡng để giảm FAR (nghiêm ngặt), còn dịch vụ đại chúng điều chỉnh để giảm FRR (dễ dãi), và bản thân việc điều chỉnh này là ví dụ tiêu biểu cho trade-off giữa bảo mật và tiện lợi.
5. Chuyên sâu — Chuyển sang xác thực không mật khẩu (passkey) và xác thực thích ứng
Hai xu hướng lớn nhất của công nghệ xác thực gần đây là: một là passkey (Passkey) loại bỏ hẳn xác thực dựa trên tri thức (mật khẩu), hai là xác thực thích ứng·dựa trên rủi ro (Adaptive/Risk-based Authentication) điều chỉnh động độ mạnh xác thực phản ánh ngữ cảnh.
Passkey là xác thực không mật khẩu dựa trên tiêu chuẩn FIDO2/WebAuthn. Thiết bị của người dùng tạo cặp khóa công khai/khóa riêng, khóa riêng được giữ trong vùng bảo mật của thiết bị và chỉ khóa công khai được đăng ký lên máy chủ. Khi đăng nhập, challenge do máy chủ gửi được ký bằng khóa riêng và máy chủ kiểm chứng bằng khóa công khai, nên trên máy chủ không lưu “bí mật” nào có thể bị đánh cắp để tái sử dụng. Hơn nữa, chữ ký chỉ hợp lệ ở tên miền (origin) đã đăng ký nên không hoạt động trên trang phishing. Tức là passkey có cấu trúc “không có bí mật để lộ, và phishing bị chặn từ gốc”, giải quyết đồng thời hai vấn đề căn bản của mật khẩu (rò rỉ·phishing). Khi các nền tảng chính (hệ điều hành·trình duyệt) bắt đầu hỗ trợ passkey mặc định, tốc độ lan rộng đang tăng nhanh.
Xác thực thích ứng xuất phát từ ý tưởng “không đối xử với mọi truy cập như nhau”. Truy cập từ thiết bị·vị trí·khung giờ quen thuộc được cho qua với ma sát thấp, còn khi phát hiện đăng nhập từ quốc gia mới hoặc mẫu hành vi bất thường thì yêu cầu xác thực bổ sung (step-up). Điều này được phán đoán theo thời gian thực bằng cách chấm điểm ngữ cảnh truy cập (dấu vân tay thiết bị·uy tín IP·phân tích hành vi) ở bước “đánh giá chính sách” trong sơ đồ luồng trước đó. Kết hợp với nguyên tắc “kiểm chứng tường minh (verify explicitly)” của Zero Trust, nó đang phát triển theo hướng nâng đồng thời độ mạnh bảo mật và sự tiện lợi cho người dùng.
Hai xu hướng không loại trừ nhau. Dùng passkey để làm bản thân yếu tố xác thực mạnh lên, và dùng chính sách thích ứng để quyết định thông minh khi nào cần kiểm chứng lại, sẽ tạo ra xác thực “vừa mạnh vừa không phiền phức”. Về hướng ra đề dự kiến thực tế, các chủ đề tự luận có thể gồm “so sánh bảo mật·khả năng sử dụng giữa passkey và MFA truyền thống”, “vai trò của định danh·xác thực trong Zero Trust”, “cách lưu trữ·xử lý để bảo vệ thông tin sinh trắc”, v.v.
6. Những điểm cần cân nhắc và hàm ý
Từ góc nhìn Kỹ sư chuyên nghiệp, khi thiết kế·đánh giá hệ thống định danh·xác thực cần cân nhắc tổng hợp các điểm sau.
Bắt buộc xác thực đa yếu tố (MFA) và chiến lược kết hợp yếu tố. Một yếu tố đơn lẻ (đặc biệt là mật khẩu) vốn dễ bị lộ·chiếm đoạt, nên phải kết hợp các loại khác nhau để dù một yếu tố bị phá, tài khoản vẫn được bảo vệ. Tuy nhiên, tránh các yếu tố đã suy yếu như SMS OTP, và lựa chọn yếu tố tập trung vào khóa bảo mật phần cứng·ứng dụng xác thực·passkey sẽ có lợi hơn xét về trade-off.
Lộ trình chuyển từ mật khẩu sang passkey (FIDO2). Để vượt qua điểm yếu căn bản của xác thực dựa trên tri thức (rò rỉ·tái sử dụng·phishing) cần chuyển sang passkey, nhưng có các ràng buộc thực tế như mất thiết bị·khôi phục tài khoản·tương thích hệ thống cũ. Do đó, then chốt là cách tiếp cận theo giai đoạn “ưu tiên passkey, thu hẹp fallback mật khẩu” thay vì chuyển đổi toàn diện, cùng với thiết kế quy trình khôi phục tài khoản an toàn.
Tiến hóa sang xác thực thích ứng dựa trên tình huống·rủi ro. Xác thực thích ứng phân tích vị trí truy cập·thiết bị·hành vi và chỉ yêu cầu xác thực bổ sung khi có nguy hiểm là hiện thực cốt lõi của Zero Trust. Cần cân bằng bảo mật và tiện lợi, đồng thời đòi hỏi năng lực vận hành liên tục tinh chỉnh ngưỡng giữa báo nhầm (chặn người dùng hợp lệ) và bỏ sót (để lọt tấn công).
Bảo vệ thông tin sinh trắc và tuân thủ quyền riêng tư. Thông tin sinh trắc không thể thay đổi nên thiệt hại khi bị lộ là vĩnh viễn. Bắt buộc phải có thiết kế xử lý trong vùng bảo mật của thiết bị mà không truyền·lưu bản gốc lên máy chủ, và tuân thủ các yêu cầu xử lý thông tin nhạy cảm theo luật bảo vệ thông tin cá nhân. Thiết kế lưu trữ tập trung thông tin sinh trắc chỉ vì chạy theo sự tiện lợi là nguy hiểm cả về quy định lẫn bảo mật.
Nguyên tắc tách biệt định danh và thông tin xác thực. Tập quán dùng kiêm các định danh công khai·tái sử dụng như số đăng ký cư trú·số điện thoại làm phương tiện xác thực là nguy hiểm. Định danh phải được quản lý tách bạch như nhãn tên có thể công khai, còn thông tin xác thực là bí mật, và phải được thiết kế ở dạng có thể cấp lại khi xảy ra sự cố.
Tài liệu tham khảo
- NIST SP 800-63 Digital Identity Guidelines — https://pages.nist.gov/800-63-3/
- FIDO Alliance, Passkeys / FIDO2 & WebAuthn — https://fidoalliance.org/passkeys/
- W3C, Web Authentication (WebAuthn) — https://www.w3.org/TR/webauthn-2/
- NIST, Zero Trust Architecture (SP 800-207) — https://csrc.nist.gov/pubs/sp/800/207/final
Tóm tắt một câu: Định danh là khẳng định danh tính (là ai), xác thực là kiểm chứng tính xác thực của khẳng định đó (có đúng không), tạo thành chuỗi kiểm soát truy cập định danh→xác thực→cấp quyền→kiểm toán, và đang tiến hóa từ MFA kết hợp 4 yếu tố xác thực tri thức·sở hữu·sinh trắc·hành vi sang passkey (FIDO2) chặn tận gốc rò rỉ·phishing và xác thực thích ứng phản ánh ngữ cảnh.