Trong công việc và cuộc sống hằng ngày, nhiều người có thói quen gửi mật khẩu qua Zalo hoặc Messenger vì nhanh chóng và tiện lợi.

Khi đồng nghiệp cần đăng nhập vào website, tài khoản quảng cáo, phần mềm quản lý hay một nền tảng dùng chung, cách xử lý phổ biến thường là nhắn trực tiếp:

Tài khoản: admin@example.com
Mật khẩu: Abc@123456

Chỉ mất vài giây, người nhận đã có đủ thông tin để đăng nhập. Tuy nhiên, chính sự tiện lợi này lại tạo ra một rủi ro bảo mật lớn.

Mật khẩu được gửi qua tin nhắn có thể tồn tại trong lịch sử trò chuyện rất lâu, được đồng bộ sang nhiều thiết bị, xuất hiện trong thông báo, bị chụp màn hình hoặc rơi vào tay người khác nếu một trong hai tài khoản nhắn tin bị chiếm quyền.

Vậy vì sao không nên gửi mật khẩu qua Zalo hoặc Messenger? Mã hóa đầu cuối có khiến việc này trở nên an toàn không? Và cá nhân, doanh nghiệp nên chia sẻ quyền truy cập bằng cách nào?

Mật khẩu không phải là một nội dung thông thường

Mật khẩu là một loại thông tin xác thực, được sử dụng để chứng minh rằng người đăng nhập có quyền truy cập vào tài khoản hoặc hệ thống.

Nếu gửi một hình ảnh, tài liệu thông thường hoặc đường dẫn qua tin nhắn, hậu quả khi nội dung đó bị nhìn thấy có thể tương đối giới hạn. Nhưng khi mật khẩu bị lộ, người khác có thể sử dụng nó để:

Đăng nhập vào tài khoản.
Đọc email hoặc tin nhắn.
Truy cập dữ liệu khách hàng.
Thay đổi thông tin tài khoản.
Đăng xuất chủ tài khoản thật.
Đặt lại mật khẩu của các dịch vụ khác.
Giả mạo người dùng.
Thực hiện giao dịch trái phép.
Xâm nhập sâu hơn vào hệ thống doanh nghiệp.

Vì vậy, mật khẩu cần được quản lý như một bí mật bảo mật, không phải như một đoạn văn bản thông thường.

NIST cho biết các hướng dẫn an ninh mạng từ lâu đã khuyến cáo không chia sẻ phương thức xác thực giữa nhiều người; thay vào đó, mỗi người nên có thông tin xác thực riêng của mình.

Vì sao gửi mật khẩu qua Zalo hoặc Messenger vẫn có rủi ro?

1. Mật khẩu tồn tại trong lịch sử trò chuyện

Khi gửi mật khẩu bằng tin nhắn, nội dung đó thường không biến mất sau khi người nhận sử dụng xong.

Nó có thể tiếp tục tồn tại trong:

Lịch sử cuộc trò chuyện.
Thiết bị của người gửi.
Thiết bị của người nhận.
Phiên đăng nhập trên máy tính.
Bản sao lưu hoặc vùng lưu trữ tin nhắn.
Ảnh chụp màn hình.
Tin nhắn được chuyển tiếp.
Nội dung được sao chép sang ứng dụng khác.

Sau vài tháng, người dùng có thể quên rằng mật khẩu từng được gửi. Nhưng chỉ cần tìm lại một từ khóa như “password”, “mật khẩu”, “tài khoản” hoặc tên website, người có quyền truy cập cuộc trò chuyện có thể tìm thấy thông tin đó.

Một bí mật đã được lưu trong lịch sử trò chuyện sẽ khó kiểm soát hơn rất nhiều so với một quyền truy cập được cấp thông qua hệ thống chuyên dụng.

2. Tài khoản nhắn tin có thể bị chiếm quyền

Ngay cả khi Zalo hoặc Messenger có các cơ chế bảo mật, tài khoản của người dùng vẫn có thể bị chiếm quyền do:

Mật khẩu tài khoản yếu.
Dùng lại mật khẩu ở nhiều nơi.
Đăng nhập vào website giả mạo.
Cung cấp mã OTP cho kẻ lừa đảo.
Quét mã QR đăng nhập không an toàn.
Thiết bị bị mất.
Máy tính bị cài phần mềm độc hại.
Quên đăng xuất khỏi thiết bị công cộng.
Người khác biết mã khóa điện thoại.

Zalo có hướng dẫn người dùng bật bảo mật hai lớp, xử lý thiết bị lạ và đề phòng các hình thức mạo danh, cho thấy việc bảo vệ chính tài khoản nhắn tin vẫn là một phần quan trọng của an toàn thông tin.

Nếu tài khoản Zalo hoặc Messenger của một người bị xâm nhập, kẻ tấn công có thể đọc lại lịch sử trò chuyện và tìm kiếm những thông tin nhạy cảm đã được gửi trước đó.

Khi đó, một tài khoản nhắn tin bị mất có thể kéo theo hàng loạt tài khoản khác.

Vì sao không nên dùng chung một mật khẩu?

3. Tin nhắn có thể xuất hiện trong thông báo

Mật khẩu gửi qua tin nhắn có thể hiện trực tiếp trên:

Màn hình khóa điện thoại.
Trung tâm thông báo.
Đồng hồ thông minh.
Màn hình máy tính.
Thiết bị kết nối với tài khoản.
Nội dung xem trước của thông báo.

Người khác không nhất thiết phải mở khóa hoàn toàn thiết bị. Trong một số trường hợp, họ chỉ cần nhìn vào thông báo hiện trên màn hình là đã thấy được một phần hoặc toàn bộ mật khẩu.

Rủi ro này đặc biệt cao tại văn phòng, quán cà phê, phòng họp, nơi làm việc chung hoặc khi người dùng cho người khác mượn thiết bị.

4. Người nhận có thể chụp màn hình hoặc chuyển tiếp

Sau khi mật khẩu được gửi dưới dạng văn bản, người gửi gần như không còn toàn quyền kiểm soát nó.

Người nhận có thể:

Chụp màn hình.
Sao chép mật khẩu.
Chuyển tiếp tin nhắn.
Lưu vào ghi chú.
Gửi cho một đồng nghiệp khác.
Đăng nhập trên thiết bị cá nhân.
Lưu mật khẩu vào trình duyệt.

Ngay cả khi người nhận không có ý xấu, họ vẫn có thể vô tình làm lộ thông tin.

Ví dụ, nhân viên chụp màn hình đoạn hội thoại để lưu lại, sau đó ảnh được tự động đồng bộ lên dịch vụ đám mây. Từ một mật khẩu ban đầu chỉ có hai người biết, nhiều bản sao không được kiểm soát có thể được tạo ra.

5. Không biết chính xác ai đang sử dụng mật khẩu

Nếu nhiều người cùng nhận một mật khẩu dùng chung, doanh nghiệp sẽ gặp khó khăn trong việc xác định:

Ai đã đăng nhập.
Ai thay đổi dữ liệu.
Ai tải tài liệu xuống.
Ai gửi thông tin ra ngoài.
Ai thay đổi cấu hình hệ thống.
Ai thực hiện một hành động bất thường.

Ví dụ, một tài khoản quản trị website được chia sẻ cho năm nhân viên qua nhóm chat. Khi một bài viết bị xóa hoặc cấu hình bị thay đổi, doanh nghiệp có thể chỉ biết tài khoản quản trị đã thực hiện hành động đó, nhưng không biết người cụ thể đứng sau.

Việc mỗi nhân viên có tài khoản và quyền riêng sẽ giúp quá trình kiểm tra, truy vết và thu hồi quyền rõ ràng hơn.

6. Khó thu hồi quyền truy cập

Khi mật khẩu đã được gửi cho người khác, không có nút nào giúp “thu hồi” kiến thức mà người đó đã biết.

Ngay cả khi xóa tin nhắn, người nhận vẫn có thể đã:

Ghi nhớ mật khẩu.
Sao chép mật khẩu.
Chụp màn hình.
Lưu vào trình duyệt.
Lưu trên thiết bị cá nhân.
Chuyển tiếp cho người khác.

Muốn chắc chắn người đó không còn quyền truy cập, doanh nghiệp thường phải đổi mật khẩu.

Nếu cùng một mật khẩu đã được gửi cho nhiều người, việc đổi mật khẩu còn tạo ra một vòng lặp mới:

Quản trị viên đổi mật khẩu.
Gửi mật khẩu mới vào nhóm chat.
Mật khẩu mới lại được lưu trong lịch sử trò chuyện.
Quy trình không an toàn tiếp tục lặp lại.

7. Nhân viên nghỉ việc vẫn có thể biết mật khẩu

Đây là rủi ro đặc biệt phổ biến ở doanh nghiệp nhỏ.

Trong quá trình làm việc, nhân viên có thể được gửi mật khẩu của:

Website công ty.
Hosting.
Tên miền.
Email chung.
Tài khoản quảng cáo.
Phần mềm kế toán.
Hệ thống quản lý khách hàng.
Mạng xã hội.
Công cụ phân tích.
Dịch vụ lưu trữ đám mây.

Khi nhân viên nghỉ việc, doanh nghiệp có thể thu hồi tài khoản nội bộ nhưng quên rằng mật khẩu của nhiều dịch vụ đã từng được gửi qua Zalo hoặc Messenger.

Nếu những mật khẩu đó không được thay đổi, nhân viên cũ vẫn có thể đăng nhập sau khi rời công ty.

8. Mật khẩu có thể bị dùng lại ở nhiều tài khoản

Một mật khẩu được gửi qua tin nhắn có thể không chỉ bảo vệ một tài khoản.

Nhiều người có thói quen dùng lại cùng một mật khẩu cho:

Email.
Facebook.
Website.
Hosting.
Phần mềm công việc.
Tài khoản lưu trữ.
Tài khoản cá nhân.

Nếu mật khẩu trong cuộc trò chuyện bị lộ, kẻ tấn công có thể thử nó trên nhiều nền tảng khác. Hình thức này thường được gọi là Credential Stuffing.

CISA khuyến nghị sử dụng trình quản lý mật khẩu vì công cụ này có thể tạo, lưu và tự động điền mật khẩu, đồng thời cảnh báo khi người dùng sử dụng mật khẩu yếu hoặc bị lặp lại.

Bao lâu nên thay đổi mật khẩu một lần?

Messenger có mã hóa đầu cuối thì gửi mật khẩu có an toàn không?

Messenger sử dụng mã hóa đầu cuối cho các cuộc trò chuyện được hỗ trợ. Theo Meta, mã hóa đầu cuối giúp chỉ người gửi và những người tham gia cuộc trò chuyện có thể xem hoặc nghe nội dung được gửi.

Đây là một lớp bảo vệ quan trọng đối với dữ liệu trong quá trình truyền và lưu trữ. Tuy nhiên, mã hóa đầu cuối không loại bỏ mọi rủi ro khi gửi mật khẩu.

Mã hóa không thể ngăn chặn trường hợp:

Điện thoại của người nhận bị mở khóa.
Tài khoản người nhận đang đăng nhập trên thiết bị lạ.
Thiết bị bị cài mã độc.
Người nhận chụp màn hình.
Người nhận chuyển tiếp mật khẩu.
Mật khẩu hiện trên thông báo.
Người nhận lưu mật khẩu ở nơi không an toàn.
Người gửi nhắn nhầm người.
Mật khẩu không được đổi sau khi nhân viên nghỉ việc.

Nói cách khác, mã hóa có thể bảo vệ nội dung trên đường truyền, nhưng không giải quyết đầy đủ vấn đề quản lý quyền truy cập, vòng đời của mật khẩu và hành vi của người dùng tại hai đầu cuộc trò chuyện.

Meta cũng cung cấp chức năng lưu trữ và khôi phục lịch sử trò chuyện mã hóa trên nhiều thiết bị. Điều này hữu ích cho người dùng, nhưng đồng thời cho thấy nội dung trò chuyện có thể tiếp tục tồn tại để được khôi phục thay vì tự động biến mất sau khi mật khẩu được sử dụng.

Zalo có mã hóa thì gửi mật khẩu có an toàn không?

Chính sách quyền riêng tư của Zalo đề cập đến tính năng mã hóa đầu cuối như một công cụ người dùng có thể lựa chọn để tăng cường bảo vệ tin nhắn.

Tuy nhiên, tương tự Messenger, mã hóa không thể bảo vệ mật khẩu nếu:

Một trong hai tài khoản bị chiếm quyền.
Thiết bị bị mất hoặc bị người khác sử dụng.
Tin nhắn bị chụp màn hình.
Mật khẩu bị sao chép ra ngoài.
Người nhận tiếp tục giữ mật khẩu sau khi không còn được phép truy cập.
Mật khẩu được gửi vào nhóm có quá nhiều thành viên.
Người gửi chọn nhầm cuộc trò chuyện.

Do đó, câu hỏi quan trọng không chỉ là “ứng dụng có mã hóa hay không”, mà còn là:

Mật khẩu được lưu ở đâu?
Ai đang có quyền xem?
Có thể thu hồi quyền không?
Có ghi nhận được ai đã truy cập không?
Khi nhân viên nghỉ việc, quyền có bị loại bỏ ngay không?
Mật khẩu có bị sử dụng lại ở nơi khác không?

Ứng dụng nhắn tin được thiết kế chủ yếu để giao tiếp. Nó không thay thế hoàn toàn một hệ thống quản lý thông tin xác thực chuyên dụng.

Data Breach là gì?

Xóa tin nhắn sau khi gửi có đủ an toàn không?

Xóa tin nhắn tốt hơn việc để mật khẩu tồn tại vô thời hạn, nhưng không thể đảm bảo mật khẩu đã hoàn toàn biến mất.

Trước khi tin nhắn bị xóa, người nhận có thể đã:

Đọc và ghi nhớ mật khẩu.
Sao chép nội dung.
Chụp màn hình.
Lưu vào trình duyệt.
Chuyển tiếp cho người khác.
Đăng nhập trên thiết bị khác.
Đồng bộ nội dung sang thiết bị liên kết.

Ngoài ra, người gửi có thể chỉ xóa tin nhắn ở phía mình hoặc nhầm tưởng rằng việc thu hồi tin nhắn đồng nghĩa với thu hồi quyền truy cập.

Khi mật khẩu đã được tiết lộ, biện pháp chắc chắn hơn vẫn là đổi mật khẩu hoặc thu hồi phiên đăng nhập và quyền truy cập liên quan.

Gửi mật khẩu thành hai phần có an toàn hơn không?

Một số người chia mật khẩu thành hai phần rồi gửi qua hai ứng dụng khác nhau, chẳng hạn:

Gửi nửa đầu qua Zalo.
Gửi nửa sau qua Messenger.

Cách này có thể giảm một phần rủi ro so với việc gửi toàn bộ mật khẩu trong một tin nhắn, nhưng vẫn không phải giải pháp quản lý mật khẩu tốt.

Người nhận cuối cùng vẫn phải ghép hai phần và có thể lưu lại mật khẩu hoàn chỉnh. Ngoài ra, doanh nghiệp vẫn không giải quyết được những vấn đề quan trọng như:

Không kiểm soát được bản sao.
Không thu hồi được quyền dễ dàng.
Không xác định được ai đang sử dụng.
Không có lịch sử quản lý quyền rõ ràng.
Không phát hiện được mật khẩu bị dùng lại.
Phải đổi mật khẩu khi thành viên rời nhóm.

Đây chỉ nên được xem là biện pháp tình thế trong trường hợp khẩn cấp, không phải quy trình bảo mật lâu dài.

Nếu bắt buộc phải gửi mật khẩu tạm thời thì nên làm gì?

Trong một số tình huống, người dùng chưa có hệ thống chia sẻ mật khẩu chuyên dụng nhưng buộc phải cấp quyền truy cập ngay.

Khi đó, có thể giảm rủi ro bằng cách:

Tạo một mật khẩu tạm thời, không dùng ở bất kỳ tài khoản nào khác.
Chỉ gửi cho đúng một người cần truy cập.
Tránh gửi tên đăng nhập và mật khẩu trong cùng một tin nhắn.
Bật xác thực nhiều lớp.
Giới hạn quyền của tài khoản.
Kiểm tra thiết bị và phiên đăng nhập sau khi sử dụng.
Đổi mật khẩu ngay khi công việc hoàn tất.
Không gửi mã OTP hoặc mã khôi phục cố định.
Không gửi mật khẩu của email chính, tài khoản ngân hàng hoặc tài khoản quản trị cấp cao.
Chuyển sang một giải pháp chia sẻ quyền truy cập chuyên dụng sớm nhất có thể.

Đây vẫn chỉ là cách giảm thiểu rủi ro, không khiến ứng dụng nhắn tin trở thành nơi lưu trữ mật khẩu phù hợp.

Cách chia sẻ quyền truy cập an toàn hơn

Cấp tài khoản riêng cho từng người

Thay vì chia sẻ một tài khoản chung, doanh nghiệp nên tạo tài khoản riêng cho từng nhân viên khi nền tảng hỗ trợ.

Ví dụ:

Mỗi nhân viên có tài khoản quản trị website riêng.
Mỗi thành viên được mời vào tài khoản quảng cáo bằng email cá nhân.
Mỗi nhân viên sử dụng tài khoản phần mềm riêng.
Quyền được cấp theo đúng vai trò công việc.

Cách này giúp doanh nghiệp:

Xác định ai đã thực hiện hành động.
Thu hồi đúng tài khoản khi nhân viên nghỉ việc.
Giới hạn quyền theo chức vụ.
Không phải đổi mật khẩu cho cả đội.
Theo dõi lịch sử truy cập rõ ràng hơn.

Sử dụng xác thực nhiều lớp

Xác thực nhiều lớp yêu cầu người dùng cung cấp thêm một yếu tố ngoài mật khẩu, chẳng hạn ứng dụng xác thực, khóa bảo mật hoặc thiết bị đã đăng ký.

NIST xem MFA là một biện pháp tăng cường bảo mật vì người dùng phải chứng minh danh tính bằng nhiều yếu tố thay vì chỉ dựa vào tên đăng nhập và mật khẩu.

Tuy nhiên, không nên gửi mã OTP cho người khác qua tin nhắn. Mã xác thực là lớp bảo vệ bổ sung, không phải một loại mật khẩu thứ hai để tiếp tục chia sẻ.

Sử dụng trình quản lý mật khẩu

Trình quản lý mật khẩu cho phép người dùng lưu trữ thông tin đăng nhập trong một kho được bảo vệ thay vì rải mật khẩu trong:

Zalo.
Messenger.
Email.
Tệp Excel.
Ghi chú điện thoại.
Tài liệu nội bộ.
Ảnh chụp màn hình.

CISA khuyến nghị sử dụng trình quản lý mật khẩu để tạo và lưu mật khẩu mạnh. Với doanh nghiệp, việc nhân viên chỉ cần nhớ một mật khẩu chính giúp hạn chế mật khẩu yếu, mật khẩu bị dùng lại và các sự cố vô tình làm lộ thông tin đăng nhập.

Một giải pháp phù hợp còn có thể giúp doanh nghiệp chia sẻ quyền sử dụng thông tin đăng nhập mà không cần gửi mật khẩu dưới dạng văn bản trong cuộc trò chuyện.

Quy trình chia sẻ tài khoản an toàn cho doanh nghiệp

Doanh nghiệp có thể áp dụng quy trình sau:

Bước 1: Xác định tài khoản có thực sự cần dùng chung hay không

Trước khi chia sẻ mật khẩu, hãy kiểm tra nền tảng có hỗ trợ:

Mời thành viên.
Tạo tài khoản phụ.
Phân quyền theo vai trò.
Cấp quyền quản trị giới hạn.
Đăng nhập một lần.
Chia sẻ thông qua tổ chức hoặc nhóm.

Nếu có, hãy sử dụng những chức năng này thay vì gửi mật khẩu.

Bước 2: Chỉ cấp quyền tối thiểu cần thiết

Nhân viên viết bài không nhất thiết phải có quyền thay đổi cấu hình máy chủ. Nhân viên chạy quảng cáo không nhất thiết phải sở hữu toàn bộ tài khoản doanh nghiệp.

Mỗi người chỉ nên được cấp đúng quyền cần thiết cho công việc.

Bước 3: Dùng trình quản lý mật khẩu nếu buộc phải chia sẻ

Nếu nền tảng chỉ có một tài khoản dùng chung, hãy đưa thông tin đó vào một kho mật khẩu được quản lý thay vì gửi qua nhóm chat.

Bước 4: Bật xác thực nhiều lớp

Tài khoản quan trọng cần có lớp bảo vệ bổ sung ngoài mật khẩu.

Bước 5: Kiểm tra quyền định kỳ

Doanh nghiệp nên thường xuyên rà soát:

Ai đang có quyền truy cập?
Người đó còn cần quyền hay không?
Có tài khoản cũ nào chưa bị thu hồi?
Có mật khẩu nào bị dùng lại không?
Có thiết bị lạ đang đăng nhập không?

Bước 6: Thu hồi quyền ngay khi nhân sự thay đổi

Khi nhân viên nghỉ việc hoặc chuyển bộ phận, quyền truy cập cần được cập nhật ngay, không chờ đến khi xảy ra sự cố.

TJGuard – Chia sẻ mật khẩu an toàn hơn, không cần gửi qua tin nhắn

Gửi mật khẩu qua Zalo hoặc Messenger có thể nhanh, nhưng không cung cấp một quy trình quản lý quyền truy cập đầy đủ.

TJGuard là nền tảng quản lý mật khẩu dành cho cá nhân và doanh nghiệp, được phát triển theo kiến trúc Zero-Knowledge và định hướng Zero-Trust.

Thay vì gửi mật khẩu dưới dạng văn bản trong cuộc trò chuyện, TJGuard giúp người dùng quản lý thông tin đăng nhập trong một hệ thống tập trung và an toàn hơn.

Với TJGuard, cá nhân và doanh nghiệp có thể:

Lưu trữ mật khẩu trong kho được mã hóa.
Tạo mật khẩu mạnh và riêng biệt cho từng tài khoản.
Tự động điền thông tin đăng nhập bằng TJGuard Extension.
Chia sẻ quyền truy cập mà không cần gửi mật khẩu trực tiếp qua Zalo hoặc Messenger.
Quản lý quyền của từng thành viên.
Thu hồi quyền khi nhân viên nghỉ việc hoặc thay đổi vai trò.
Phát hiện mật khẩu yếu hoặc bị sử dụng lại.
Hạn chế việc lưu mật khẩu trong ghi chú, tệp Excel và ảnh chụp màn hình.
Xây dựng quy trình quản lý thông tin đăng nhập chuyên nghiệp hơn.

TJGuard không chỉ giúp người dùng ghi nhớ mật khẩu. Mục tiêu quan trọng hơn là giảm số lần mật khẩu phải xuất hiện, được sao chép và được chia sẻ ngoài môi trường kiểm soát.

Dark Web là gì?

Kết luận

Zalo và Messenger là những công cụ giao tiếp tiện lợi, nhưng không nên được sử dụng như kho lưu trữ hoặc hệ thống quản lý mật khẩu.

Ngay cả khi tin nhắn được mã hóa đầu cuối, mật khẩu vẫn có thể bị lộ nếu thiết bị bị mất, tài khoản bị chiếm quyền, thông báo bị nhìn thấy, người nhận chụp màn hình hoặc quyền truy cập không được thu hồi sau này.

Đối với cá nhân, hãy sử dụng mật khẩu riêng cho từng tài khoản, bật xác thực nhiều lớp và lưu mật khẩu bằng một trình quản lý chuyên dụng.

Đối với doanh nghiệp, hãy ưu tiên tạo tài khoản riêng, phân quyền theo vai trò, áp dụng nguyên tắc quyền tối thiểu và thu hồi quyền ngay khi nhân sự thay đổi.

Sự tiện lợi của một tin nhắn chỉ kéo dài vài giây, nhưng hậu quả của một mật khẩu bị lộ có thể kéo dài trong nhiều tháng hoặc nhiều năm. Sử dụng một giải pháp quản lý mật khẩu như TJGuard sẽ giúp cá nhân và doanh nghiệp chia sẻ quyền truy cập an toàn, có kiểm soát và chuyên nghiệp hơn.

Những vụ rò rỉ dữ liệu lớn nhất thế giới và bài học bảo mật quan trọng

Vì sao không nên gửi mật khẩu qua Zalo hoặc Messenger?