Cách bảo vệ tài khoản trực tuyến
- Xác định những điểm có thể khiến tài khoản bị chiếm quyền
- Tạo mật khẩu dài, riêng biệt và quản lý tập trung
- Bật MFA và ưu tiên phương thức chống lừa đảo
- Bảo vệ quy trình khôi phục tài khoản
- Kiểm soát thiết bị, phiên đăng nhập và ứng dụng liên kết
- Nhận biết lừa đảo và xác minh yêu cầu đăng nhập
- Thiết lập quy trình phản ứng khi nghi ngờ bị xâm nhập
Vì vậy, cách phòng vệ hiệu quả không phải là tìm một mật khẩu “không thể đoán”, mà là xây dựng nhiều lớp kiểm soát độc lập. Khi một lớp bị vượt qua — chẳng hạn mật khẩu bị lộ trong một vụ rò rỉ dữ liệu — các lớp còn lại vẫn có thể ngăn kẻ tấn công chiếm tài khoản.
Xác định những điểm có thể khiến tài khoản bị chiếm quyền
Một tài khoản có thể bị xâm nhập dù hệ thống của nhà cung cấp không bị tấn công trực tiếp. Kẻ xấu thường khai thác thông tin xác thực, thiết bị hoặc quy trình khôi phục của chính người dùng.
Các con đường phổ biến gồm:
· Dùng mật khẩu đã rò rỉ từ một dịch vụ khác để thử đăng nhập tự động
· Giả mạo trang đăng nhập nhằm thu thập mật khẩu và mã xác thực
· Thuyết phục người dùng phê duyệt một yêu cầu MFA không do họ khởi tạo
· Chiếm email hoặc số điện thoại dùng để đặt lại mật khẩu
· Đánh cắp cookie hoặc mã phiên đăng nhập từ thiết bị
· Lợi dụng ứng dụng bên thứ ba đã được cấp quyền quá rộng
· Sử dụng thiết bị cũ vẫn còn đăng nhập sau khi bị mất, bán hoặc cho người khác
OWASP gọi việc sử dụng danh sách tên đăng nhập và mật khẩu bị lộ để thử trên dịch vụ khác là credential stuffing. Hình thức này đặc biệt hiệu quả khi người dùng tái sử dụng cùng một mật khẩu cho nhiều tài khoản.
Do đó, cần ưu tiên bảo vệ các tài khoản có khả năng mở đường tới những tài khoản khác:
1. Email chính
2. Trình quản lý mật khẩu
3. Tài khoản Apple, Google hoặc Microsoft dùng để đồng bộ và đăng nhập
4. Tài khoản ngân hàng, ví điện tử và dịch vụ thanh toán
5. Tài khoản công việc hoặc quản trị hệ thống
6. Tài khoản mạng xã hội có nhiều người theo dõi hoặc quyền quản lý trang
Email thường là điểm kiểm soát trung tâm vì nhiều dịch vụ gửi liên kết đặt lại mật khẩu về hộp thư này. Nếu email bị chiếm, mật khẩu mạnh trên các tài khoản khác có thể không còn đủ để bảo vệ người dùng.

Tạo mật khẩu dài, riêng biệt và quản lý tập trung
Mỗi tài khoản cần một mật khẩu riêng. Đây là yêu cầu quan trọng hơn việc tạo ra nhiều biến thể nhỏ của cùng một mật khẩu.
Ví dụ, sử dụng MatKhauChinh-Facebook, MatKhauChinh-Gmail và MatKhauChinh-Bank vẫn tạo ra rủi ro. Chỉ cần một biến thể bị lộ, kẻ tấn công có thể nhận ra quy luật và suy đoán các mật khẩu còn lại.
Ưu tiên độ dài thay vì công thức khó nhớ
Mật khẩu dài giúp mở rộng không gian mà kẻ tấn công phải dò tìm. Một cụm mật khẩu gồm nhiều từ không liên quan thường dễ nhớ và có thể dài hơn một chuỗi ngắn chứa nhiều ký tự đặc biệt.
Không nên dựa hoàn toàn vào các thủ thuật như:
· Thay chữ “a” bằng “@”
· Thay chữ “o” bằng số “0”
· Thêm “123” hoặc năm hiện tại ở cuối
· Viết hoa ký tự đầu tiên để đáp ứng quy tắc
· Dùng tên, ngày sinh, số điện thoại hoặc thông tin công khai
Các quy luật này đã quen thuộc với công cụ dò mật khẩu. NIST hiện nhấn mạnh độ dài, việc chặn các mật khẩu phổ biến hoặc đã bị xâm phạm, đồng thời không yêu cầu đổi mật khẩu định kỳ nếu chưa có dấu hiệu bị lộ. Khi có bằng chứng thông tin xác thực đã bị xâm phạm, mật khẩu mới cần được thay ngay.
Mật khẩu dài cũng không chống được mọi hình thức tấn công. Theo NIST, lừa đảo, ghi lại thao tác bàn phím và kỹ thuật xã hội vẫn có thể thu được một mật khẩu dài, phức tạp giống như một mật khẩu đơn giản.
Sử dụng trình quản lý mật khẩu
Trình quản lý mật khẩu giải quyết ba vấn đề:
· Tạo mật khẩu ngẫu nhiên và riêng biệt cho từng dịch vụ
· Lưu thông tin xác thực mà người dùng không cần ghi nhớ
· Tự động điền mật khẩu theo đúng tên miền, qua đó phần nào giúp nhận biết trang đăng nhập giả
Mật khẩu chính của kho mật khẩu phải dài, không dùng ở nơi khác và được bảo vệ bằng MFA. Người dùng cũng cần lưu mã khôi phục của trình quản lý mật khẩu tại một vị trí ngoại tuyến an toàn.
Trình quản lý mật khẩu không loại bỏ toàn bộ rủi ro. Nếu thiết bị đã bị kiểm soát, kho mật khẩu đang mở khóa hoặc phiên đăng nhập bị đánh cắp, kẻ tấn công vẫn có thể tiếp cận tài khoản. Vì vậy, công cụ này phải được kết hợp với bảo mật thiết bị và MFA.
Bật MFA và ưu tiên phương thức chống lừa đảo
Xác thực đa yếu tố yêu cầu người đăng nhập chứng minh danh tính bằng nhiều yếu tố khác nhau, chẳng hạn:
· Thứ người dùng biết, như mật khẩu hoặc mã PIN
· Thứ người dùng sở hữu, như điện thoại hoặc khóa bảo mật
· Đặc điểm của người dùng, như vân tay hoặc khuôn mặt
Hai mật khẩu không tạo thành MFA vì chúng cùng thuộc nhóm “thứ người dùng biết”. Tương tự, mật khẩu cộng câu hỏi bảo mật thường không tạo ra lớp bảo vệ mạnh nếu câu trả lời có thể tìm thấy hoặc suy đoán.
CISA khuyến nghị bật MFA vì mật khẩu đơn lẻ có thể bị đánh cắp, tái sử dụng hoặc lấy qua lừa đảo.
Xếp hạng các phương thức xác thực
Khi một dịch vụ cung cấp nhiều lựa chọn, có thể ưu tiên theo thứ tự thực tế sau:
1. Khóa bảo mật phần cứng hoặc passkey
2. Ứng dụng xác thực có cơ chế ràng buộc với phiên hoặc thiết bị
3. Ứng dụng tạo mã dùng một lần
4. Thông báo đẩy yêu cầu xác nhận
5. Mã gửi qua SMS hoặc cuộc gọi
6. Chỉ sử dụng mật khẩu
Passkey và các phương thức dựa trên FIDO/WebAuthn có khả năng chống lừa đảo vì cặp khóa được ràng buộc với đúng trang web hoặc dịch vụ. Một trang giả không thể lấy đầu ra xác thực rồi tái sử dụng tại tên miền thật theo cách thường xảy ra với mật khẩu hoặc mã OTP. NIST ghi nhận các trình xác thực đồng bộ được cấu hình đúng có thể đạt khả năng chống lừa đảo và chống phát lại; CISA cũng xác định FIDO/WebAuthn là phương thức chống lừa đảo được triển khai rộng rãi.
SMS vẫn tốt hơn việc chỉ dùng mật khẩu trong nhiều tình huống, nhưng có những điểm yếu như chuyển đổi SIM trái phép, đánh cắp số điện thoại, chuyển tiếp tin nhắn hoặc lừa người dùng cung cấp mã. Vì vậy, không nên xem mọi hình thức MFA có mức bảo vệ giống nhau.
Không phê duyệt yêu cầu MFA bất ngờ
Kẻ tấn công có thể nhập được mật khẩu bị lộ rồi gửi liên tiếp các thông báo xác nhận, hy vọng người dùng nhấn “Đồng ý” vì nhầm lẫn hoặc mệt mỏi.
Khi nhận yêu cầu không do mình khởi tạo:
· Không phê duyệt
· Chụp lại thông tin nếu cần báo cáo
· Đổi mật khẩu từ thiết bị đáng tin cậy
· Kiểm tra các phiên đang hoạt động
· Thu hồi những phiên hoặc thiết bị không nhận ra
· Báo cho bộ phận quản trị nếu đó là tài khoản công việc
MFA làm giảm đáng kể khả năng chiếm tài khoản nhưng không thể bảo vệ một phiên đăng nhập đã bị đánh cắp hoặc một yêu cầu do chính người dùng phê duyệt nhầm. Vì vậy, cần kết hợp MFA với khả năng phát hiện và thu hồi phiên.
Bảo vệ quy trình khôi phục tài khoản
Khôi phục tài khoản thường là đường vòng đi qua các lớp xác thực chính. Một tài khoản dùng passkey vẫn có thể bị chiếm nếu kẻ tấn công kiểm soát email khôi phục hoặc thuyết phục dịch vụ đặt lại phương thức đăng nhập.
Cần kiểm tra định kỳ:
· Email khôi phục còn thuộc quyền kiểm soát
· Số điện thoại khôi phục còn hoạt động
· Thiết bị tin cậy không chứa thiết bị cũ hoặc không rõ nguồn gốc
· Câu hỏi bảo mật không dùng thông tin công khai
· Mã dự phòng chưa bị lộ
· Người liên hệ khôi phục vẫn phù hợp
· Không có quy tắc chuyển tiếp email bất thường
Mã dự phòng nên được coi như mật khẩu có quyền truy cập cao. Không lưu mã trong cùng hộp thư mà mã đó được dùng để khôi phục. Có thể lưu bản in tại nơi an toàn hoặc trong một kho mật khẩu đã được bảo vệ phù hợp.
Khi thay số điện thoại, mất thiết bị hoặc rời khỏi tổ chức, cần cập nhật ngay thông tin khôi phục. Một số điện thoại cũ có thể được cấp lại cho người khác; thiết bị cũ cũng có thể tiếp tục giữ phiên đăng nhập nếu chưa bị thu hồi.
Kiểm soát thiết bị, phiên đăng nhập và ứng dụng liên kết
Sau khi xác thực thành công, dịch vụ thường cấp một mã phiên để duy trì trạng thái đăng nhập. OWASP giải thích rằng mã phiên liên kết quá trình xác thực với lưu lượng truy cập và các quyền kiểm soát truy cập tiếp theo. Điều đó có nghĩa là kẻ tấn công lấy được phiên hợp lệ có thể không cần nhập lại mật khẩu hoặc MFA ngay lập tức.
Bảo vệ thiết bị đang đăng nhập
Thiết bị cần có:
· Mã khóa màn hình đủ mạnh
· Mã hóa bộ nhớ
· Cập nhật hệ điều hành và trình duyệt
· Khóa tự động khi không sử dụng
· Chức năng định vị và xóa dữ liệu từ xa
· Phần mềm chỉ cài từ nguồn đáng tin cậy
· Tài khoản người dùng riêng khi thiết bị được dùng chung
Sinh trắc học trên điện thoại thường đóng vai trò mở khóa một khóa mật mã hoặc thiết bị xác thực, thay vì gửi trực tiếp dữ liệu vân tay hay khuôn mặt cho mọi trang web. Tuy nhiên, người dùng vẫn cần một mã PIN mạnh vì mã này thường là phương án mở khóa dự phòng.
Rà soát phiên và thiết bị
Tại phần bảo mật của tài khoản, hãy kiểm tra:
· Vị trí đăng nhập
· Thời gian truy cập
· Loại thiết bị và trình duyệt
· Phiên đang hoạt động
· Thiết bị đã được đánh dấu tin cậy
· Hoạt động thay đổi mật khẩu hoặc thông tin khôi phục
Một vị trí lạ không phải lúc nào cũng chứng minh tài khoản bị xâm nhập vì địa chỉ IP, mạng di động hoặc VPN có thể làm sai lệch vị trí. Cần đánh giá cùng thời gian, thiết bị, hành động đã thực hiện và thông báo bảo mật.
Thu hồi quyền ứng dụng bên thứ ba
Đăng nhập bằng tài khoản Google, Apple, Microsoft hoặc mạng xã hội có thể giúp giảm số lượng mật khẩu phải quản lý. Tuy nhiên, ứng dụng được liên kết có thể giữ quyền đọc hồ sơ, email, tệp hoặc dữ liệu khác.
Hãy xóa quyền đối với:
· Ứng dụng không còn sử dụng
· Tiện ích trình duyệt không rõ nhà phát triển
· Dịch vụ yêu cầu quyền vượt quá chức năng
· Ứng dụng đã ngừng hoạt động
· Thiết bị hoặc phần mềm từng dùng tạm thời
Đối với tài khoản công việc, nguyên tắc quyền tối thiểu cần được áp dụng: mỗi người và mỗi ứng dụng chỉ nhận những quyền cần thiết cho nhiệm vụ hiện tại. Tài khoản quản trị không nên được dùng cho email, duyệt web hoặc công việc hằng ngày.
Nhận biết lừa đảo và xác minh yêu cầu đăng nhập
Lừa đảo không nhất thiết chứa lỗi chính tả hoặc thiết kế vụng về. Một thông điệp giả có thể sử dụng đúng logo, tên người gửi, nội dung hội thoại cũ và giọng văn phù hợp.
Dấu hiệu cần cảnh giác gồm:
· Yêu cầu hành động gấp vì tài khoản sắp bị khóa
· Đề nghị cung cấp mật khẩu, mã OTP hoặc mã khôi phục
· Thông báo giao dịch hoặc đăng nhập nhằm gây hoảng sợ
· Tên miền gần giống tên miền thật
· Tệp đính kèm hoặc mã QR không mong đợi
· Yêu cầu cài ứng dụng hỗ trợ từ xa
· Cuộc gọi tự xưng là nhân viên hỗ trợ và yêu cầu đọc mã
CISA khuyến nghị nhận diện và báo cáo thông điệp lừa đảo thay vì tương tác trực tiếp với liên kết hoặc tệp đính kèm đáng ngờ.
Khi nhận thông báo về tài khoản:
1. Không mở liên kết trong tin nhắn
2. Mở ứng dụng chính thức hoặc tự nhập địa chỉ dịch vụ
3. Kiểm tra mục hoạt động bảo mật
4. Liên hệ qua kênh hỗ trợ công khai của nhà cung cấp
5. Không cung cấp mã xác thực cho người đang gọi hoặc nhắn tin
Mã OTP xác nhận quyền kiểm soát yếu tố đăng nhập tại thời điểm đó. Nhân viên hỗ trợ hợp pháp thông thường không cần người dùng đọc mã để “hủy giao dịch” hoặc “khóa tài khoản”.
Thiết lập quy trình phản ứng khi nghi ngờ bị xâm nhập
Tốc độ xử lý rất quan trọng vì kẻ tấn công có thể nhanh chóng thay đổi mật khẩu, phương thức MFA, email khôi phục và quy tắc chuyển tiếp thư.
Nên thực hiện theo thứ tự:
1. Sử dụng một thiết bị sạch và đáng tin cậy
2. Đổi mật khẩu của tài khoản bị ảnh hưởng
3. Đăng xuất tất cả phiên đang hoạt động
4. Thu hồi thiết bị, khóa ứng dụng và quyền truy cập không nhận ra
5. Kiểm tra email, số điện thoại và phương thức khôi phục
6. Bật hoặc đăng ký lại MFA bằng phương thức mạnh
7. Kiểm tra quy tắc chuyển tiếp, bộ lọc và thư đã gửi
8. Đổi mật khẩu ở những nơi từng dùng lại thông tin xác thực
9. Thông báo cho ngân hàng, tổ chức hoặc người liên quan khi cần
10. Lưu bằng chứng về thời gian, thiết bị và hành động bất thường
Nếu không thể đăng nhập, chỉ sử dụng quy trình khôi phục chính thức. Không trả tiền cho người tự nhận có thể “hack lại” tài khoản và không cài phần mềm điều khiển từ xa theo hướng dẫn của người lạ.
Sau khi khôi phục, cần tìm nguyên nhân thay vì chỉ đổi mật khẩu. Nếu thiết bị còn phần mềm độc hại, email khôi phục vẫn bị kiểm soát hoặc cookie phiên vẫn còn hiệu lực, tài khoản có thể bị chiếm lại.
Không có biện pháp đơn lẻ nào bảo vệ tài khoản trong mọi tình huống. Mật khẩu riêng biệt hạn chế tác động của rò rỉ dữ liệu; trình quản lý mật khẩu giúp duy trì tính duy nhất; MFA tạo thêm rào cản; passkey hoặc khóa bảo mật giảm rủi ro lừa đảo; còn việc quản lý phiên, thiết bị và quyền ứng dụng ngăn những con đường không đi qua mật khẩu.
Thứ tự ưu tiên thực tế là bảo vệ email chính và trình quản lý mật khẩu trước, bật phương thức MFA mạnh nhất mà dịch vụ hỗ trợ, lưu mã khôi phục an toàn, sau đó rà soát định kỳ thiết bị, phiên đăng nhập và ứng dụng liên kết. Khi xuất hiện yêu cầu xác thực không do mình khởi tạo, hãy coi đó là tín hiệu cần điều tra ngay thay vì chỉ từ chối rồi bỏ qua.
Hỏi đáp về Bảo vệ tài khoản trực tuyến
Có cần đổi mật khẩu định kỳ không?
Không cần đổi chỉ vì đã đến một mốc thời gian cố định. Nên đổi ngay khi mật khẩu bị lộ, đã dùng trên một dịch vụ bị xâm phạm, xuất hiện đăng nhập đáng ngờ hoặc có lý do tin rằng thiết bị đã bị kiểm soát. NIST hiện không yêu cầu thay mật khẩu định kỳ nếu chưa có bằng chứng bị xâm phạm.
MFA có bảo vệ được khi mật khẩu đã bị lộ không?
MFA có thể ngăn kẻ tấn công đăng nhập chỉ bằng mật khẩu. Tuy nhiên, hiệu quả phụ thuộc phương thức được sử dụng. Mã OTP và thông báo đẩy vẫn có thể bị lừa lấy hoặc phê duyệt nhầm; passkey và khóa bảo mật có khả năng chống lừa đảo tốt hơn.
Passkey có thay thế hoàn toàn mật khẩu không?
Passkey có thể thay thế mật khẩu tại những dịch vụ hỗ trợ và giúp chống lừa đảo tốt hơn nhờ xác thực mật mã gắn với đúng dịch vụ. Người dùng vẫn phải bảo vệ thiết bị, tài khoản đồng bộ và quy trình khôi phục passkey.
Có nên lưu mật khẩu trong trình duyệt không?
Kho mật khẩu tích hợp trong trình duyệt có thể tốt hơn việc dùng lại mật khẩu hoặc ghi trong tệp không bảo vệ. Mức an toàn phụ thuộc vào mã khóa thiết bị, tài khoản đồng bộ, MFA và khả năng bảo vệ phiên trình duyệt. Với nhu cầu quản lý phức tạp, một trình quản lý mật khẩu chuyên dụng có thể cung cấp thêm chức năng kiểm tra và tổ chức thông tin xác thực.
Làm gì khi nhận mã OTP dù không đăng nhập?
Không cung cấp mã cho bất kỳ ai và không phê duyệt yêu cầu liên quan. Hãy mở trực tiếp dịch vụ, kiểm tra hoạt động đăng nhập, đổi mật khẩu nếu cần, thu hồi các phiên lạ và xác minh rằng email hoặc số điện thoại khôi phục chưa bị thay đổi.
