An ninh mạng cho nhà giao dịch — 2FA, phishing, rút tiền và bảo vệ thiết bị
Bảo mật tài khoản giao dịch bắt đầu từ tài khoản email, mật khẩu riêng và phương thức xác thực phù hợp. Thiết bị, phiên đăng nhập, quy tắc rút tiền và phương án khôi phục khi mất điện thoại cũng rất quan trọng. Bài viết hướng dẫn từng bước các biện pháp này, giải thích giới hạn và cách ứng phó khi nghi ngờ tài khoản bị chiếm quyền. Người dùng VPS và robot giao dịch cũng sẽ tìm thấy hướng dẫn bảo vệ truy cập từ xa, khóa API và các vị thế đang mở. Các hình thức lừa đảo mạo danh doanh nghiệp được trình bày riêng trong bài về nhà môi giới giả mạo.
- Tài khoản email là lớp 1, không phải phần bổ sung tùy chọn. Email bị xâm phạm có thể cho phép người khác đặt lại mật khẩu tài khoản tại nhà môi giới và chặn xác nhận thay đổi, tùy các biện pháp kiểm soát khôi phục của nhà môi giới. Đặt mật khẩu email riêng và bật MFA trước khi cấu hình các lớp còn lại.
- Chỉ một mật khẩu bị tái sử dụng cũng có thể đủ để tài khoản bị chiếm quyền, nhất là khi không có MFA hiệu quả. Credential stuffing là việc tự động thử các cặp tên đăng nhập/mật khẩu từ những vụ rò rỉ khác, nhắm vào mọi mật khẩu bị dùng lại đã lộ. Mật khẩu riêng kết hợp 2FA, ưu tiên TOTP thay vì SMS, là mức tối thiểu trong vận hành.
- 2FA qua SMS tốt hơn việc không có 2FA, nhưng yếu hơn TOTP hoặc khóa bảo mật phần cứng. SIM swapping có thể diễn ra nhanh và ít tốn kém; thời gian, chi phí và tỷ lệ thành công phụ thuộc vào nhà mạng và quốc gia. TOTP trong ứng dụng không sao lưu mã khởi tạo lên đám mây, hoặc khóa bảo mật phần cứng như YubiKey, là chuẩn thực tế.
- Phishing trong FX có thể nhắm mục tiêu cụ thể. Email giả mạo xưng là “nhà môi giới”, cuộc gọi từ “bộ phận bảo mật” và liên kết đến trang đăng nhập MT4 giả mạo có thể được thiết kế riêng để nhắm vào nhà giao dịch thay vì hoàn toàn gửi ngẫu nhiên.
- Đưa nơi nhận tiền rút vào danh sách cho phép sau khi bảo vệ email. Nếu nhà môi giới cung cấp danh sách tài khoản ngân hàng được phép nhận tiền rút, hãy bật tính năng đó: kẻ tấn công sẽ phải đổi thông tin và vượt qua xác minh bổ sung. Tuy nhiên, việc xác minh thường dùng email nên khả năng bảo vệ bị hạn chế nếu lớp 1 đã bị xâm phạm.
- Dùng một thiết bị cho mọi việc làm tăng bề mặt tấn công. Thiết bị hoặc hồ sơ người dùng riêng cho giao dịch thể hiện sự kỷ luật trong vận hành, chứ không phải sự thận trọng quá mức.
1. Dùng lại mật khẩu — khi một vụ rò rỉ đe dọa tài khoản giao dịch
Bắt đầu bằng một tình huống rất đỗi bình thường, mà chính sự bình thường đó khiến nó nguy hiểm. Không có hacker trùm đầu hay việc phá mã hóa. Đó là credential stuffing: tự động thử trên nhiều dịch vụ các cặp tên đăng nhập/mật khẩu lấy từ những vụ rò rỉ cơ sở dữ liệu[1].
Cơ chế rất đơn giản. Ngày 22 tháng 1 năm 2024, nhóm nghiên cứu Cybernews mô tả một tập hợp có thể truy cập công khai chứa hơn 26 tỷ bản ghi và 12 terabyte dữ liệu, được gọi là “Mother of All Breaches”[5]. Cần nêu chính xác tình trạng và bản chất của tập hợp này vì chúng làm thay đổi ý nghĩa của con số đó: đây không phải một vụ rò rỉ mới đơn lẻ, mà là tập hợp các bản ghi từ hàng nghìn vụ rò rỉ trước đó và những cơ sở dữ liệu được mua bán riêng. Chính báo cáo cho biết rất có khả năng có dữ liệu trùng lặp và coi sự hiện diện của thông tin chưa từng công bố là một khả năng, chứ không phải kết luận đã được xác lập. Phần tường thuật về việc tập hợp này tiếp tục bị lộ cũng là phát biểu của một tổ chức, chứ không phải kết luận được xác lập độc lập: dịch vụ tìm kiếm dữ liệu rò rỉ Leak-Lookup tuyên bố họ sở hữu tập hợp và cho biết việc lộ dữ liệu bắt nguồn từ cấu hình tường lửa sai mà họ đã sửa[5]. Chúng tôi không có xác nhận độc lập rằng các bản sao đã ngừng lưu hành. Với nhà giao dịch, kết luận thực tế không phụ thuộc vào sự bất định đó: nếu bạn dùng cùng mật khẩu cho diễn đàn giao dịch, Gmail và tài khoản tại nhà môi giới, một trong hàng nghìn tập dữ liệu ấy có thể cung cấp cho kẻ tấn công thông tin đăng nhập của cả ba.
Chuỗi tấn công có thể xảy ra là: email bị xâm phạm → đặt lại mật khẩu tài khoản tại nhà môi giới → đổi thông tin liên hệ → yêu cầu rút tiền về tài khoản của kẻ tấn công. Khoảng thời gian từ lúc email bị xâm phạm đến khi gửi yêu cầu rút tiền có thể ngắn, nhưng chúng tôi không đưa ra thời lượng cụ thể: nó phụ thuộc vào quy trình thay đổi thông tin của nhà môi giới và kênh thanh toán, và chúng tôi không tìm thấy phép đo nào hỗ trợ một con số chính xác. Nhà môi giới gửi email xác nhận rút tiền, nhưng kẻ tấn công đã kiểm soát tài khoản email đó.
Mô hình nhiều lớp — xác định thứ bạn đang bảo vệ
Trước khi cấu hình bất kỳ thứ gì, hãy xác định một mô hình mối đe dọa: bạn bảo vệ điều gì, trước ai, và chuyện gì xảy ra nếu một lớp bảo vệ cụ thể bị vô hiệu hóa. Nếu không xác định rõ, bạn có thể mua khóa bảo mật phần cứng cho một tài khoản mà việc khôi phục mật khẩu vẫn phụ thuộc vào tài khoản Gmail cũ.
Đối với tài khoản giao dịch, chuỗi phụ thuộc có bảy mắt xích. Hãy xử lý theo thứ tự sau:
- Email — tài khoản nền tảng. Nếu tài khoản này bị chiếm quyền, khả năng khôi phục các tài khoản khác cũng bị đe dọa.
- Danh tính — số điện thoại, mã khôi phục và giấy tờ xác nhận danh tính của bạn với nhà môi giới.
- Thiết bị — máy tính và điện thoại mà bạn dùng để nhập thông tin bí mật và nhận mã.
- Nhà môi giới — mật khẩu, MFA, các phiên đang hoạt động và cài đặt cổng thông tin khách hàng.
- API — các khóa truy cập bằng chương trình có thể xác thực quyền truy cập độc lập với mật khẩu và MFA của cổng thông tin khách hàng.
- Thanh toán — phương thức nạp, rút tiền và danh sách tài khoản nhận tiền được phép.
- Khôi phục — các kênh khôi phục quyền truy cập, thường là đường vòng được kẻ tấn công ưu tiên.
Nguyên tắc thực tế là mỗi lớp phụ thuộc vào lớp làm nền tảng cho nó. Không thể tin cậy danh sách tài khoản rút tiền được phép nếu kẻ tấn công kiểm soát email nhận xác nhận thay đổi tài khoản đích. Vì vậy, bài viết được sắp xếp có chủ đích: mục 1 và 2 nói về email, danh tính và nhà môi giới; mục 5 và 6 nói về thiết bị và API; mục 4 nói về thanh toán. Khôi phục được đề cập xuyên suốt vì đây là đường truy cập thay thế vào các lớp khác.
Các bước thực hiện
Dùng mật khẩu riêng cho tài khoản môi giới. Không dùng lại mật khẩu này ở bất kỳ đâu. Sử dụng trình quản lý mật khẩu như Bitwarden, 1Password hoặc KeePass. Tạo mật khẩu ngẫu nhiên dài ít nhất 16 ký tự, có khoảng dự phòng so với ngưỡng 15 ký tự trong hướng dẫn hiện hành của NIST dành cho mật khẩu được dùng làm yếu tố xác thực duy nhất[2]. Tránh tự nghĩ mật khẩu: con người không giỏi tạo ra sự ngẫu nhiên.
Dùng địa chỉ email riêng cho giao dịch. Tạo một tài khoản chỉ dùng để liên lạc với nhà môi giới và nền tảng giao dịch. Không dùng tài khoản này để đăng ký diễn đàn, mạng xã hội hay dịch vụ khác. Nếu địa chỉ email chính bị rò rỉ, địa chỉ gắn với tài khoản giao dịch sẽ không bị lộ qua cùng bộ hồ sơ đăng ký. Cách này giảm rủi ro nhưng tự nó không đủ bảo vệ tài khoản.
Kiểm tra xem thông tin của bạn có bị lộ không. Nhập địa chỉ email tại haveibeenpwned.com và xem những dữ liệu nào đã bị tiết lộ. Đổi mật khẩu ngay nếu mật khẩu bị rò rỉ, được dùng lại hoặc có căn cứ nghi ngờ tài khoản bị xâm phạm. Việc địa chỉ email xuất hiện trong vụ rò rỉ của dịch vụ khác không tự nó chứng minh mật khẩu riêng, khác biệt của tài khoản môi giới đã bị lộ.
2. 2FA — yêu cầu tối thiểu, không phải tùy chọn
Xác thực hai yếu tố (2FA) bổ sung một lớp sau mật khẩu. Khi được triển khai đúng, 2FA khiến việc đăng nhập bằng mật khẩu bị đánh cắp khó hơn, nhưng lừa đảo có thể chặn lấy mã, còn khôi phục tài khoản hoặc đánh cắp phiên có thể bỏ qua màn hình đăng nhập thông thường. Vấn đề là các phương thức 2FA không tương đương nhau. SMS và TOTP có những điểm yếu khác biệt đáng kể, cũng như các loại khóa khác nhau đem lại mức bảo vệ khác nhau.
| Phương thức 2FA | Cách hoạt động | Mức bảo mật | Điểm yếu chính |
|---|---|---|---|
| SMS | Mã dùng một lần được gửi đến số điện thoại của bạn | Thấp | Chiếm đoạt SIM: kẻ tấn công giành quyền kiểm soát số điện thoại thông qua nhà mạng |
| Mã được gửi đến địa chỉ email của bạn | Thấp nhất | Nếu tài khoản email bị chiếm quyền, 2FA qua email không còn cung cấp sự bảo vệ độc lập | |
| TOTP (ứng dụng xác thực) | Mã được tạo ngay trên thiết bị mỗi 30 giây (Google Authenticator, Authy); ưu tiên cấu hình không sao lưu khóa bí mật lên đám mây | Cao | Trang lừa đảo có thể chặn lấy mã dùng một lần; ngoài ra, mất điện thoại khi không có mã khôi phục có thể khiến bạn không truy cập được tài khoản |
| Khóa bảo mật phần cứng | Thiết bị USB vật lý (YubiKey, Titan Key) | Cao nhất | Trong ví dụ chi phí tại Ba Lan, giá vài trăm PLN tùy mẫu và nhà bán lẻ; số nhà môi giới hỗ trợ còn hạn chế |
Vì sao 2FA qua SMS chưa đủ
2FA qua SMS tốt hơn không có 2FA, nhưng yếu hơn TOTP hoặc khóa bảo mật phần cứng. Trong một vụ chiếm đoạt SIM, kẻ lừa đảo liên hệ nhà mạng, giả danh chủ số điện thoại và yêu cầu chuyển số sang SIM thay thế. Những cuộc tấn công này có thể nhanh và ít tốn kém, nhưng thời gian, chi phí và tỷ lệ thành công phụ thuộc vào nhà mạng, quốc gia và chất lượng thông tin về nạn nhân. Mỗi nhà mạng có quy trình xác minh riêng khi cấp SIM thay thế, và thông tin dùng để xác minh có thể đã có trong các vụ rò rỉ. Quy mô được ghi nhận tại Mỹ: FCC cho biết Trung tâm Khiếu nại Người tiêu dùng của cơ quan này nhận khoảng 300 khiếu nại về chiếm đoạt SIM và chuyển mạng giữ số trái phép trong năm 2020, 400 trong năm 2021 và 500 trong năm 2022[4].
TOTP — tiêu chuẩn thực tế
TOTP (mật khẩu dùng một lần dựa trên thời gian) tạo mã ngay trên thiết bị mỗi 30 giây. Phương thức này không dùng mạng di động, nên việc chiếm đoạt SIM không chặn lấy được mã và quá trình tạo mã không cần kết nối internet. Trong thứ tự ưu tiên của NCSC Vương quốc Anh, mã do ứng dụng tạo được xếp cao hơn đáng kể so với mã gửi qua tin nhắn[7], nhưng đây chưa phải phương thức được xếp cao nhất. Tiểu mục về passkey giải thích những phương thức có thứ hạng cao hơn.
Để cấu hình TOTP, tải ứng dụng xác thực và chọn chế độ không cần tài khoản hoặc tắt đồng bộ đám mây. Google Authenticator đồng bộ mã với tài khoản Google nếu bạn đăng nhập, đồng thời cũng cho phép dùng không cần tài khoản; Authy có chức năng sao lưu đám mây. Điều đó tiện lợi, nhưng sự cố LastPass đã được xác nhận vào tháng 12 năm 2022, được trình bày bên dưới, cho thấy việc lưu thông tin xác thực trên đám mây tạo thêm một điểm có thể bị xâm phạm. Ưu tiên công cụ tạo mã ngoại tuyến, cùng bản sao vật lý của mã khôi phục. Trong cài đặt tài khoản môi giới, tìm “Bảo mật” → “Xác thực hai yếu tố” rồi dùng ứng dụng quét mã QR. Sau đó, việc đăng nhập yêu cầu mật khẩu cùng mã 6 chữ số của ứng dụng.
Bước quan trọng: lưu mã khôi phục. Nếu nhà môi giới cấp mã dự phòng dùng một lần để xử lý trường hợp mất điện thoại, hãy lưu chúng ngay khi thiết lập. Nếu không có, hãy kiểm tra quy trình khôi phục chính thức được công bố và ghi lại trước khi cần dùng. In các mã khôi phục nếu có và cất giữ an toàn, tách khỏi điện thoại, tài khoản đám mây và trình quản lý mật khẩu: mất quyền truy cập trình quản lý không được đồng nghĩa với mất luôn mã. Một tờ giấy cất trong két hoặc ngăn kéo khóa là một lựa chọn.
Passkey và FIDO2 — hướng phát triển
Khóa phần cứng trong bảng là một cách triển khai vật lý của tiêu chuẩn rộng hơn: FIDO2/WebAuthn. Thay vì một mã có thể đọc cho người khác hoặc sao chép vào trang giả, trình duyệt và bộ xác thực trao đổi chữ ký mật mã gắn với tên miền phù hợp. Một tên miền khác không thể nhận xác thực cho thông tin xác thực đã đăng ký. Chính sự ràng buộc với tên miền này là điểm khác biệt cốt yếu so với TOTP.
Một passkey sử dụng cơ chế này với thông tin xác thực FIDO2 được lưu trên điện thoại, máy tính hoặc trình quản lý mật khẩu và mở khóa bằng vân tay hay mã PIN thiết bị, nên có thể không cần khóa rời. NCSC xếp thông tin xác thực FIDO2 đứng đầu về khả năng chống đoán, lừa đảo và đánh cắp bí mật xác thực. Mã do ứng dụng tạo đứng thứ ba; tài liệu nêu rõ khả năng mã bị chặn lấy[7]. NIST cho phép bộ xác thực mật mã đa yếu tố ở các mức bảo đảm cao nhất khi đáp ứng yêu cầu của từng mức; passkey được đồng bộ không tự động trở thành thông tin xác thực AAL3. Xác thực qua mạng điện thoại, bao gồm SMS, thuộc nhóm bị hạn chế sử dụng[2].
Việc nên làm ngay hôm nay. Mức hỗ trợ passkey của các nhà môi giới bán lẻ khác nhau: một số cổng khách hàng chỉ có TOTP và SMS. Kiểm tra cài đặt bảo mật để tìm “khóa bảo mật”, “passkey” hoặc “WebAuthn”. Nếu được hỗ trợ, bật làm phương thức chính và giữ TOTP dự phòng. Nếu chưa có, TOTP cùng mã khôi phục ngoại tuyến vẫn là mức tối thiểu hợp lý. Bật passkey cho email độc lập với nhà môi giới, vì email là lớp 1 trong mô hình trên.
3. Lừa đảo — email, điện thoại và kỹ nghệ xã hội trong FX
Lừa đảo trong Forex có thể nhắm mục tiêu: kẻ tấn công biết nhà giao dịch giữ tiền trong tài khoản và phản ứng với thông báo “gọi bổ sungký quỹ ” và “cảnh báo bảo mật”. Nó cũng có thể chỉ là thư rác thông thường dùng logo nhà môi giới và tên miền đăng ký với chi phí thấp. Cuộc tấn công không cần tinh vi mới có hiệu quả.
Email giả mạo từ “nhà môi giới”
Đây là phương thức tấn công ít tốn kém nên khá phổ biến. Email bắt chước màu sắc, logo và chân thư của nhà môi giới. Tiêu đề có thể là “Khẩn cấp: Xác minh tài khoản”, “Cảnh báo bảo mật: Phát hiện đăng nhập bất thường” hoặc “Cần hành động: Cập nhật phương thức thanh toán”. Liên kết mở bản sao trang đăng nhập nhà môi giới trên tên miền khác. Nhập thông tin đăng nhập đồng nghĩa trao chúng cho kẻ tấn công. Hướng dẫn dành cho tổ chức của NCSC đề cập hai nội dung: giả mạo người gửi, được xử lý bằng các biện pháp chống giả mạo DMARC, SPF và DKIM; cùng nhu cầu có cách báo cáo thư đáng ngờ đơn giản, kịp thời[6]. Tài liệu đó không bàn về tên miền gần giống; phần giải thích bên dưới là của chúng tôi, không phải nhận định được gán cho NCSC.
Cuộc gọi từ “bộ phận bảo mật”
Phương thức có nhiều bước hơn là vishing, tức lừa đảo qua giọng nói. Một người gọi đến tự nhận làm việc tại bộ phận bảo mật của nhà môi giới, nói rằng phát hiện hoạt động đáng ngờ và yêu cầu xác minh danh tính: “Vui lòng cho tôi số tài khoản và mã 2FA chúng tôi vừa gửi.” Cung cấp mã đó có thể cho phép kẻ tấn công đăng nhập.
Nhà môi giới vận hành đúng chuẩn không nên yêu cầu mã 2FA đăng nhập qua điện thoại. Người gọi yêu cầu mã có thể đang xâm phạm tài khoản thay vì bảo vệ nó. Hãy cúp máy rồi gọi số chính thức trên trang web nhà môi giới, không dùng số trong email. Áp lực phải hành động nhanh có thể hiệu quả hơn phần mềm độc hại.
Liên kết tải MT4/MT5 giả
Nhà giao dịch tìm Google bằng cụm “tải MT4” hoặc “tải MT5”. Kẻ tấn công có thể mua quảng cáo dẫn đến bộ cài nền tảng đã bị chỉnh sửa: trông quen thuộc và có thể hoạt động bình thường nhưng đồng thời gửi thông tin đăng nhập đến máy chủ do chúng kiểm soát. Trang tải giả là cách phát tán phần mềm độc hại hiệu quả vì chính người dùng chạy bộ cài và cấp quyền cho nó.
Kỹ nghệ xã hội trong các nhóm giao dịch
Các nhóm giao dịch Telegram, Discord và Facebook tạo cơ hội cho kỹ nghệ xã hội. Một người tự xưng là quản trị viên gửi tin riêng: “Tôi có ưu đãi đặc biệt từ nhà môi giới X, nhưng bạn phải đăng ký qua liên kết của tôi.” Hoặc: “Đăng ảnh chụp tài khoản, tôi sẽ giúp cấu hình EA.” Ảnh chụp tài khoản có thể lộ số tài khoản môi giới, giúp kẻ tấn công thao túng quy trình xác minh danh tính qua điện thoại yếu kém. Hãy hiểu nguy cơ đó trước khi đăng “lợi nhuận hôm nay” lên nhóm.
4. Rút tiền an toàn — phương thức, danh sách cho phép và giấy tờ KYC
Kẻ tấn công chiếm được tài khoản có thể đóng vị thế và gây thiệt hại vốn, nhưng chuyển tiền sang nơi khác sẽ khó hơn khi danh sách tài khoản được phép hoạt động hiệu quả. Mục đích của biện pháp này là tiền chỉ đến tài khoản đã phê duyệt, đứng tên bạn. Cấu hình rút tiền là vấn đề bảo mật cũng như tiện ích.
Danh sách tài khoản ngân hàng được phép
Nếu nhà môi giới có “Tài khoản nhận tiền rút đã phê duyệt” hoặc “Danh sách rút tiền được phép”, hãy kiểm tra quy tắc cụ thể. Bật tính năng sẽ giới hạn rút tiền về các tài khoản ngân hàng đã duyệt. Thêm tài khoản có thể cần xác minh bổ sung và thời gian chờ; nhà môi giới quyết định có những biện pháp này hay không và mất bao lâu. Điều này khiến chuyển hướng tiền khó hơn, nhưng không bảo đảm lệnh rút sẽ bị chặn sau khi tài khoản bị chiếm quyền.
Kiểm tra nhà môi giới có hỗ trợ danh sách được phép hay không và bật nếu có. Tìm “danh sách rút tiền được phép”, “tài khoản nhận tiền rút đã phê duyệt” hoặc “tài khoản tin cậy” trong cổng khách hàng. Xác minh hợp đồng và cài đặt bảo mật: tính năng có thể thay đổi theo thời gian và khác nhau giữa các pháp nhân trong cùng tập đoàn. Khi so sánh biện pháp kiểm soát, xem việc thiếu tính năng là một bất lợi, không phải bằng chứng kết luận thiếu trung thực.
Thông báo rút tiền
Bật thông báo email và thông báo đẩy cho mọi yêu cầu rút tiền. Nếu thấy yêu cầu không do bạn gửi, gọi nhà môi giới ngay: email có thể đã bị chiếm quyền. Thường có thời gian xử lý từ lúc gửi đến khi nhà môi giới và ngân hàng thực hiện, nhưng điều khoản của pháp nhân cụ thể quyết định khoảng thời gian này. Kiểm tra trước, thay vì chờ đến khi xảy ra sự cố. Khoảng thời gian đó thường là cơ hội tốt nhất để chặn chuyển tiền, dù không phải điểm can thiệp duy nhất: sau khi gửi đi, ngân hàng hoặc nhà cung cấp thanh toán vẫn có thể khởi động quy trình yêu cầu thu hồi, như giải thích bên dưới.
Thay đổi thông tin — điểm bảo mật then chốt
Sự kiện then chốt thường là thay đổi email, số điện thoại, tài khoản ngân hàng hoặc người thụ hưởng tiền rút, chứ không phải bản thân lần đăng nhập. Đổi phương thức rút hằng tuần có thể kích hoạt kiểm tra tuân thủ thủ công và, trong một số trường hợp, hạn chế tạm thời đúng lúc bạn muốn rút lợi nhuận. Chọn phương thức phù hợp, xác minh và dùng nhất quán.
Giấy tờ KYC — thông tin có thể dùng để mở tài khoản môi giới khác
Để mở tài khoản, bạn gửi nhà môi giới bản quét căn cước hoặc hộ chiếu, giấy tờ chứng minh địa chỉ và đôi khi sao kê ngân hàng. Kết hợp lại, các giấy tờ đó có thể hỗ trợ mở hoặc khôi phục tài khoản khác. Hãy coi chúng là thông tin định danh nhạy cảm, không phải tệp đính kèm thông thường.
Trong thực tế, tải giấy tờ qua cổng khách hàng, thay vì email hay ứng dụng nhắn tin. Nếu email yêu cầu giấy tờ, hãy gọi số trên trang web đã xác minh để kiểm tra yêu cầu. Không để bản quét trong thư mục tải xuống hoặc thư viện ảnh điện thoại; nếu cần giữ, dùng vùng lưu trữ mã hóa hoặc trình quản lý mật khẩu hỗ trợ tệp đính kèm. Xóa các bản làm việc sau xác minh, kể cả trong thư đã gửi và cuộc trò chuyện. Giấy tờ bị lộ có thể hỗ trợ nỗ lực khôi phục tài khoản bằng lý do “Tôi quên mật khẩu và mất 2FA”. Nếu có tính năng này, hãy đặt trước mật khẩu liên hệ qua điện thoại. Câu hỏi như họ thời con gái của mẹ hoặc trường học đầu tiên là vấn đề riêng: câu trả lời có thể được suy ra từ dữ liệu rò rỉ và mạng xã hội. Nếu nhà môi giới dùng chúng, hãy coi đó là bước kiểm tra bổ trợ bên cạnh MFA mạnh và quy trình khôi phục đã xác minh, không phải phương án thay thế.
5. Bảo vệ thiết bị — VPN, Wi-Fi công cộng, cập nhật và tách biệt
Máy tính và điện thoại là cổng vào tài khoản giao dịch. Nếu thiết bị bị xâm phạm, ngay cả mật khẩu, 2FA và danh sách được phép kết hợp cũng có thể chưa đủ: kẻ tấn công có khả năng quan sát những gì bạn làm trên màn hình.
Wi-Fi công cộng — VPN giải quyết và không giải quyết điều gì
Hãy phân biệt các yếu tố thiết yếu với biện pháp bổ sung, vì có nhiều lời phóng đại về Wi-Fi công cộng. Điều thiết yếu là HTTPS được xác minh đúng, địa chỉ cổng nhập thủ công trên đúng tên miền, không bỏ qua cảnh báo chứng chỉ, thiết bị được cập nhật và MFA chống lừa đảo. Cơ quan bảo vệ người tiêu dùng Mỹ nêu rõ rằng mã hóa phổ biến thường khiến kết nối qua Wi-Fi công cộng an toàn[13]. Cơ quan này cũng lưu ý kẻ lừa đảo có thể lấy chứng chỉ cho trang của chúng, nên chỉ riêng mã hóa không xác định ai đang nhận thông tin của bạn.
Wi-Fi công cộng vẫn có rủi ro từ điểm truy cập giả, chuyển hướng đến trang đăng nhập bắt chước và lừa đảo. VPN hoặc điểm truy cập cá nhân là lớp bổ sung, không phải điều kiện tiên quyết của bảo mật. Nó có thể giảm việc lộ lưu lượng phụ trợ và sự phụ thuộc vào mạng không quen thuộc, nhưng không thể sửa thiết bị nhiễm mã độc hay ngăn bạn nhập mật khẩu vào tên miền giả.
Nếu chọn VPN, hãy chọn nhà cung cấp có chính sách ghi nhật ký rõ ràng và kiểm tra nguồn tài trợ dịch vụ. Với dịch vụ miễn phí, câu hỏi đó quan trọng hơn riêng mức giá: một số gói miễn phí được tài trợ bằng thuê bao trả phí, số khác kiếm tiền từ lưu lượng và dữ liệu người dùng. Đánh giá mô hình kinh doanh, chính sách nhật ký và kiểm toán độc lập của nhà cung cấp cụ thể, không mặc nhiên coi trả phí là đáng tin. Chia sẻ kết nối LTE/5G từ điện thoại của bạn thường đơn giản hơn và không đưa thêm một nhà cung cấp cần tin cậy vào chuỗi.
Các lớp bảo mật, chẳng hạn VPN hoặc quét trên VPS, có thể ảnh hưởng độ trễ mạng hoặc tải thiết bị. Hãy đo tác động trong cấu hình của bạn. Bài viết về hạ tầng khớp lệnh giải thích khi nào điều đó quan trọng, chẳng hạn giao dịch theo tin hoặc giao dịch lướt sóng, và khi nào không.
Phiên đang hoạt động — rà soát và thu hồi
Đăng nhập tạo ra phiên có thể vẫn hoạt động trong trình duyệt, ứng dụng di động hoặc phần mềm giao dịch. Phần mềm độc hại đánh cắp cookie phiên có thể không cần mật khẩu hay mã 2FA: một phiên hợp lệ có thể đã đủ. Vì vậy, đổi mật khẩu sau sự cố mà không thu hồi phiên có thể để kẻ tấn công tiếp tục kết nối.
Tìm “phiên đang hoạt động”, “thiết bị”, “thiết bị đã đăng nhập” hoặc “hoạt động bảo mật” trong cổng khách hàng. Rà soát định kỳ và đăng xuất những gì không quen thuộc: máy tính khác, điện thoại cũ hay địa điểm không nhận ra. Nếu có nút “đăng xuất mọi thiết bị”, hãy biết vị trí trước khi có sự cố. Rà soát tương tự với email liên kết nhà môi giới, tức lớp 1 trong mô hình trên.
Tách biệt thiết bị
Bạn đang quản lý vốn, vì vậy hãy giữ môi trường giao dịch sạch. Một thiết bị dành riêng cho giao dịch là máy tính xách tay hoặc máy tính bảng mà bạn tránh dùng để duyệt nội dung không liên quan, mở tệp đính kèm và cài phần mềm chưa xác minh. Các công cụ cần thiết là nền tảng giao dịch, trình duyệt cho cổng khách hàng và trình quản lý mật khẩu.
Trong ví dụ ngân sách tại Ba Lan, ThinkPad tân trang giá khoảng một nghìn PLN có thể là một lựa chọn để bảo vệ tài khoản. Nếu thiết bị riêng không khả thi, hồ sơ người dùng hệ điều hành riêng giúp tổ chức công việc và giảm một số nguy cơ, nhưng không thay thế thiết bị riêng trước các mối đe dọa phần mềm độc hại nghiêm trọng hơn.
Cập nhật — thường lệ nhưng rất quan trọng
Windows, macOS, Android, iOS, MT5 và cTrader nhận các bản cập nhật, bao gồm bản vá bảo mật; MT4 được đề cập riêng bên dưới. Bản cài lỗi thời có thể chứa lỗ hổng đã biết mà kẻ tấn công khai thác được. Bật cập nhật tự động thay vì trì hoãn vô thời hạn.
MetaTrader 4 vẫn nhận bản cập nhật của nhà sản xuất. Chúng tôi không gán cho MetaQuotes tuyên bố chính thức chấm dứt phát triển MT4, vì không tìm thấy thông báo của nhà sản xuất xác lập điều đó. Nếu dùng MT4, hãy bảo đảm bạn có phiên bản mới nhất từ nhà môi giới hoặc nhà sản xuất. Bản cũ từ trang không liên quan có thể chứa lỗ hổng đã biết.
6. Bảo mật VPS và EA — lệnh mất giám sát và truy cập từ xa
Chạy các robot Expert Advisor (EA) trên VPS tạo thêm bề mặt tấn công. Máy tính từ xa này hoạt động 24/7, duy trì kết nối với nhà môi giới và có thể truy cập tài khoản giao dịch. Xâm phạm nó có thể giúp kẻ tấn công kiểm soát môi trường giao dịch.
Cấu hình RDP an toàn
Giao thức máy tính từ xa (RDP) là cách thông dụng để kết nối với VPS Windows. RDP mở trực tiếp ra internet luôn là mục tiêu: bot quét liên tục thử tấn công mật khẩu, 24/7.
Chỉ đổi cổng RDP đem lại rất ít bảo vệ. Ưu tiên không mở RDP công khai, truy cập qua đường hầm VPN/WireGuard; danh sách IP được phép nếu nhà cung cấp internet cấp địa chỉ ổn định; xác thực cấp mạng (NLA); MFA tại nhà cung cấp VPS và riêng tại cổng truy cập nếu sử dụng; cùng ảnh chụp hệ thống định kỳ và ghi nhật ký sự kiện. Áp dụng nguyên tắc quyền tối thiểu: chỉ cài những gì môi trường giao dịch cần.
Kiểm soát việc lưu mật khẩu trong MT4/MT5 trên VPS
MT4 và MT5 có tùy chọn “Lưu mật khẩu” khi đăng nhập. Tắt nếu không cần cho hoạt động dự kiến: thông tin đã lưu giúp truy cập dễ hơn sau khi máy chủ hoặc phiên bị xâm phạm. Tuy nhiên, với EA chạy 24/7, hãy kiểm tra cách phần mềm kết nối lại sau khi khởi động lại. Tắt lưu mật khẩu mà không có kế hoạch xác thực lại có thể khiến tự động hóa dừng.
Điều này khác với lưu mật khẩu trong trình quản lý mật khẩu. Trình quản lý mã hóa bí mật sau lớp xác thực riêng và có thể là một phần của cấu hình EA 24/7 khi máy chủ cùng đường truy cập được bảo vệ bằng MFA và danh sách IP được phép. Thứ tự là bảo vệ máy chủ và đường truy cập trước, rồi quyết định cách cung cấp thông tin đăng nhập. Hai việc không thay thế nhau: giới hạn lưu trữ và quyền của thông tin đăng nhập theo nhu cầu tự động hóa; đồng thời, nhập mật khẩu thủ công không biện minh cho dịch vụ RDP mở công khai với cấu hình mặc định.
Lệnh mất giám sát — vị thế không còn bộ điều khiển
Lệnh mất giám sát do EA mở nhưng không còn được quản lý sau khi VPS hỏng, mất kết nối hoặc khởi động lại. Nó có thể không có lệnh dừng lỗ vì thuật toán được dự kiến sẽ quản lý thoát lệnh linh hoạt, không có chốt lời và không ai theo dõi. Vị thế có thể tiếp tục phơi nhiễm cho đến khi bị gọi bổ sung ký quỹ hoặc có can thiệp khác.
Biện pháp bảo vệ: EA nên đặt lệnh dừng lỗ được máy chủ chấp nhận thay vì chỉ dựa vào mức dừng ảo của thuật toán. Nếu EA dừng, SL đã được chấp nhận vẫn ở máy chủ, nhưng không bảo đảm giá khớp hoặc mức lỗ giới hạn theo dự kiến. Sự đánh đổi rất đáng lưu ý: khi thanh khoản thấp và chênh lệch giá mua bán rộng, chẳng hạn lúc chuyển ngày giao dịch của nhà môi giới, lệnh dừng có thể bị kích hoạt trong điều kiện xấu hơn dự kiến. Nếu chuyển ngày lúc 17:00 giờ New York, ví dụ tại Ba Lan thường là 23:00, hoặc 22:00 trong các giai đoạn lệch lịch đổi giờ mùa hè. Việc kích hoạt như vậy tự nó không chứng minh nhà môi giới nhắm vào mức dừng của bạn. Dừng ảo che mức dừng thường trực trong phần mềm nhưng tăng phụ thuộc hạ tầng. Chọn cách bố trí phù hợp điều kiện khớp lệnh và phương pháp giao dịch.
Không dùng chung VPS
Dùng chung VPS để tiết kiệm có thể để EA và vị thế mở tiếp xúc với người dùng khác có khả năng truy cập phần mềm, tệp, nhật ký và bí mật. Trong minh họa tại Ba Lan, tiết kiệm PLN 50 tạo ra nguy cơ đó. Giữ VPS giao dịch dưới quyền kiểm soát của một nhà giao dịch thay vì chia sẻ môi trường tài khoản với người dùng không liên quan.
Tài khoản lớn và giao dịch thuật toán có thể dùng FIX API hoặc đặt máy chủ gần máy chủ môi giới, được trình bày trong hạ tầng khớp lệnh. Cần phân biệt về bảo mật tương tự các khóa API khác: tách thông tin xác thực chỉ đọc khỏi thông tin được quyền đặt lệnh.
7. Danh sách kiểm tra 10 phút và ứng phó sự cố
Hôm nay bạn có thể truy cập vị thế mở và ngày mai mất quyền truy cập. Phần sau được thiết kế như một lần rà soát 10 phút: đủ để xem danh sách và xác định những mục bạn chưa thể đánh dấu hoàn thành.
| # | Hạng mục | Tiêu chuẩn tối thiểu | Trạng thái |
|---|---|---|---|
| 1 | Email được bảo vệ độc lập | Mật khẩu email riêng, MFA (ưu tiên passkey), đã rà soát quy tắc chuyển tiếp và bộ lọc — lớp 1 tại mục 1 | ☐ |
| 2 | Email riêng cho giao dịch | Địa chỉ chuyên dụng không dùng đăng ký dịch vụ không liên quan | ☐ |
| 3 | Mật khẩu môi giới riêng | 16+ ký tự ngẫu nhiên từ trình quản lý mật khẩu, không dùng lại ở nơi khác | ☐ |
| 4 | Đã bật 2FA (TOTP) | Ứng dụng TOTP không sao lưu đám mây, thay cho SMS hoặc email | ☐ |
| 5 | Mã khôi phục 2FA ngoại tuyến | Đã in và cất ở nơi an toàn | ☐ |
| 6 | Tài khoản nhận tiền rút thuộc danh sách được phép | Nếu được hỗ trợ: chỉ tài khoản ngân hàng đã duyệt, với quy tắc thay đổi người nhận đã được xác minh | ☐ |
| 7 | Thông báo rút tiền | Thông báo email và thông báo đẩy cho mọi yêu cầu rút | ☐ |
| 8 | Cập nhật hệ thống và nền tảng | Đã bật cập nhật tự động; bản MT4/MT5 hiện hành | ☐ |
| 9 | Mạng không quen thuộc: HTTPS đã xác minh, VPN là lớp bổ sung | Nhập địa chỉ cổng thủ công; không bỏ qua cảnh báo chứng chỉ. VPN có chính sách nhật ký đã kiểm tra hoặc chia sẻ mạng điện thoại là bổ sung | ☐ |
| 10 | Thiết bị hoặc hồ sơ riêng | Máy tính hoặc hồ sơ người dùng giao dịch tách khỏi hoạt động hằng ngày | ☐ |
| 11 | VPS: đường hầm VPN, danh sách IP và MFA nhà cung cấp | Không mở RDP công khai; truy cập VPN/WireGuard, danh sách IP được phép, MFA nhà cung cấp và MFA riêng cho cổng nếu dùng | ☐ |
| 12 | VPS: bí mật được kiểm soát và giới hạn | Lưu thông tin đăng nhập theo nhu cầu tự động hóa; đã thử đăng nhập sau khởi động lại, có trình quản lý mật khẩu và bảo vệ máy chủ cùng truy cập | ☐ |
| 13 | EA: SL phía máy chủ khi VPS hỏng | SL được máy chủ nhà môi giới chấp nhận, không chỉ mức dừng ảo của EA | ☐ |
| 14 | Rà soát phiên đang hoạt động | Đã rà soát danh sách thiết bị môi giới và email; đã đăng xuất phiên không quen thuộc | ☐ |
| 15 | Đã thu hồi khóa API không dùng | Khóa không dùng đã thu hồi; quyền còn lại thu hẹp và giới hạn IP nếu được hỗ trợ | ☐ |
| 16 | Đã lưu kênh liên hệ nhà môi giới được xác minh | Số điện thoại chính thức, cổng khách hàng và địa chỉ tuân thủ được ghi ngoài email | ☐ |
| 17 | Không cho người chưa xác minh truy cập máy tính từ xa | Không dùng AnyDesk, TeamViewer hay chia sẻ màn hình theo yêu cầu bất ngờ của “cố vấn”, “bộ phận bảo mật” hoặc “công ty thu hồi tiền” | ☐ |
Tôi đã nhấp liên kết, nhập mật khẩu và duyệt MFA — giờ phải làm gì?
Đây là tình huống khó vì về kỹ thuật yếu tố thứ hai không thất bại: chính bạn đã duyệt. Kẻ tấn công có thể đang có phiên hợp lệ và quyền đổi thông tin. Thứ tự hành động quan trọng, không chỉ tốc độ của từng việc. Hãy dùng thiết bị đáng tin cậy khác và ngừng tương tác với email đáng ngờ.
- Thu hồi phiên cùng với đổi mật khẩu. Đăng xuất mọi thiết bị trong cổng nhà môi giới, rồi đổi mật khẩu. Đổi mật khẩu không phải lúc nào cũng chấm dứt phiên. Nếu không có nút thực hiện, hãy nói rõ với đường dây hỗ trợ.
- Bảo vệ email. Đổi mật khẩu, chấm dứt phiên và kiểm tra quy tắc chuyển tiếp cùng bộ lọc. Quy tắc chuyển thư nhà môi giới vào thùng rác có thể che giấu việc chiếm quyền.
- Gọi nhà môi giới bằng số đã lưu trước, thay vì số trong tin nhắn. Yêu cầu tạm dừng rút tiền và ghi nhận nghi ngờ xâm phạm. Hỏi xem thông tin liên hệ hoặc tài khoản nhận tiền rút có thay đổi trong những giờ gần đây không.
- Đặt lại yếu tố thứ hai. Thu hồi thông tin xác thực bị ảnh hưởng và cấu hình lại MFA. Tạo mã khôi phục mới và vô hiệu hóa bộ cũ.
- Thu hồi khóa API và kiểm tra có khóa mới được tạo không. Khóa có quyền giao dịch có thể vẫn hợp lệ sau khi đổi mật khẩu.
- Kiểm tra thông tin rút tiền và danh sách được phép. Báo tài khoản lạ như một phần của cùng sự cố, thay vì coi là việc hành chính riêng.
- Ghi lại mọi thứ. Giữ ảnh chụp có ngày giờ, email kèm đầy đủ tiêu đề kỹ thuật, lịch sử đăng nhập và số tham chiếu từ đường dây hỗ trợ. Chúng hỗ trợ khiếu nại hoặc tranh chấp với nhà môi giới.
- Kiểm tra thiết bị. Nếu còn nghi ngờ mã độc, chẳng hạn cửa sổ hay tiện ích lạ hoặc máy chậm không rõ lý do, hãy dùng thiết bị sạch cho đến khi được điều tra, như trình bày tại mục 5.
- Báo cáo sự việc. Báo việc rút tiền trái phép cho cảnh sát và cơ quan giám sát nhà môi giới. Trong ví dụ tại Ba Lan, báo riêng sự cố kỹ thuật, bao gồm lừa đảo, email hoặc thiết bị bị xâm phạm, cho CERT Polska qua incydent.cert.pl[14]. Kênh kỹ thuật này không thay thế tố giác tội phạm hay khiếu nại nhà môi giới và không quyết định việc hoàn tiền. Ngoài Ba Lan, hãy dùng kênh báo cáo sự cố quốc gia phù hợp. Bài 13.7 giải thích sự khác biệt giữa khiếu nại và hành động giám sát cùng các hướng thủ tục liên quan.
Những việc không nên làm: không cài phần mềm “kiểm tra máy tính” do người gọi bất ngờ gửi, không cấp quyền truy cập từ xa và không nạp thêm tiền để “mở khóa rút tiền”. Mỗi yêu cầu đều báo hiệu khả năng đây là giai đoạn tiếp theo của cùng cuộc tấn công.
Danh sách này không bảo vệ khỏi lỗ giao dịch thị trường. Mục đích là giảm nguy cơ mất kiểm soát tài khoản vì nguyên nhân không liên quan thị trường, trong đó nhiều nguyên nhân có thể xử lý bằng cấu hình cẩn thận.
FAQ — An ninh mạng cho nhà giao dịch Forex
Chỉ dùng 2FA qua SMS có đủ để bảo vệ tài khoản tại nhà môi giới không?
Tôi nên làm gì nếu mất điện thoại chứa ứng dụng 2FA?
Tôi có nên dùng VPN để giao dịch không?
Tôi nên bảo vệ MT4/MT5 trên điện thoại như thế nào?
Tôi nên làm gì nếu nghi ngờ tài khoản bị truy cập trái phép?
EA có thể đánh cắp thông tin đăng nhập của tôi không?
Nguồn
- OWASP Foundation, “Credential Stuffing Prevention Cheat Sheet”, cheatsheetseries.owasp.org/cheatsheets/Credential_Stuffing_Prevention_Cheat_Sheet.html — định nghĩa việc thử các cặp tên đăng nhập/mật khẩu từ vụ rò rỉ của dịch vụ khác, và mô tả biện pháp phía dịch vụ gồm MFA, hạn chế IP, phát hiện thiết bị hoặc địa chỉ lạ. Nguồn không đo tỷ lệ chiếm đoạt tài khoản môi giới do phương thức này; ở đây không gán thống kê như vậy cho nguồn. Truy cập ngày 31 tháng 8 năm 2026.
- Viện Tiêu chuẩn và Công nghệ Quốc gia (NIST), “Digital Identity Guidelines — SP 800-63B-4”, pages.nist.gov/800-63-4/sp800-63b/authenticators/ — mục 3.1.1.2: ít nhất 15 ký tự khi mật khẩu là yếu tố duy nhất, hoặc 8 trong MFA; mục 3.1.3.3: xác thực qua mạng điện thoại công cộng, kể cả SMS, thuộc nhóm bị hạn chế, bắt buộc có phương án thay thế; mục 3.1.7 nói về bộ xác thực mật mã đa yếu tố. Bản SP 800-63B ngày 2 tháng 3 năm 2020 từng được dẫn ở đây đã được thay bằng SP 800-63B-4, hoàn tất ngày 31 tháng 7 năm 2025; cách đánh số mục phía trên theo bản này. Không rút gọn định danh thành “SP 800-63-4”: tài liệu tổng quát riêng đó thay SP 800-63-3, không phải SP 800-63B. Tình trạng tài liệu được kiểm tra tại csrc.nist.gov/pubs/sp/800/63/b/4/final. Truy cập ngày 1 tháng 9 năm 2026.
- Cơ quan Quản lý Tài chính (FCA), “PS26/2: Operational incident and third party reporting”, fca.org.uk/publications/policy-statements/ps26-2-operational-incident-third-party-reporting — tuyên bố chính sách công bố ngày 18 tháng 3 năm 2026: định nghĩa sự cố hoạt động, ngưỡng báo cáo và quy trình chuẩn hóa; riêng việc báo cáo thỏa thuận với bên thứ ba trọng yếu và sổ đăng ký hằng năm. Các quy tắc ban hành theo đó dự kiến áp dụng từ ngày 18 tháng 3 năm 2027. Nội dung thay cho tham chiếu lỗi thời trong bài trước vốn chỉ nói “đã công bố yêu cầu báo cáo sự cố”. Truy cập ngày 31 tháng 8 năm 2026.
- Ủy ban Truyền thông Liên bang (FCC), “Protecting Consumers from SIM Swap and Port-Out Fraud”, Report and Order and Further Notice of Proposed Rulemaking, FCC 23-95, WC Docket No. 21-341, docs.fcc.gov/public/attachments/FCC-23-95A1.pdf — được thông qua ngày 15 tháng 11 năm 2023 và công bố ngày 16 tháng 11 năm 2023. Khoảng 300 khiếu nại năm 2020, 400 năm 2021 và 500 năm 2022 về chiếm đoạt SIM và chuyển mạng giữ số trái phép lấy từ chú thích 13 và hồ sơ Trung tâm Khiếu nại Người tiêu dùng của Ủy ban. Truy cập ngày 31 tháng 8 năm 2026 (98 trang; văn bản được trích xuất cục bộ trong cuộc kiểm tra bản gốc tiếng Ba Lan).
- Vilius Petkauskas, Cybernews, “Mother of all breaches reveals 26 billion records: what we know so far”, cybernews.com/security/billions-passwords-credentials-leaked-mother-of-all-breaches/ — công bố ngày 22 tháng 1 năm 2024; nội dung đã cập nhật, với ngày 15 tháng 6 năm 2026 được ghi nhận là lần cập nhật mới nhất trong cuộc kiểm tra nguồn tiếng Ba Lan. Bộ dữ liệu 12 TB chứa hơn 26 tỷ bản ghi trong khoảng 3.800 thư mục, được mô tả có lẽ là bộ tổng hợp nhiều vụ rò rỉ (COMB) lớn nhất, với khả năng trùng lặp rất cao. Đây là tường thuật thứ cấp về các vụ rò rỉ gốc và được xử lý đúng như vậy: hỗ trợ mô tả bộ tổng hợp, không phải kết luận về từng vụ cấu thành. Truy cập ngày 31 tháng 8 năm 2026.
- Trung tâm An ninh mạng Quốc gia (NCSC UK), “Phishing attacks: defending your organisation”, ncsc.gov.uk/guidance/phishing — biện pháp chống giả mạo DMARC, SPF và DKIM, chính sách quarantine hoặc reject và kênh báo cáo thư đáng ngờ đơn giản, kịp thời. Cuộc kiểm tra gốc đã xác minh riêng phạm vi tài liệu: không bàn về tên miền gần giống, vì vậy nội dung đó không được gán cho tài liệu. Truy cập ngày 31 tháng 8 năm 2026.
- Trung tâm An ninh mạng Quốc gia (NCSC UK), “Recommended types of MFA”, trong “Multi-factor authentication for your corporate online services”, ncsc.gov.uk/collection/mfa-for-your-corporate-online-services/recommended-types-of-mfa — thứ tự ưu tiên: 1) thông tin xác thực FIDO2, 2) ứng dụng dựa trên yêu cầu xác thực, 3) công cụ tạo mã ứng dụng (TOTP), 4) công cụ tạo mã phần cứng, 5) mã gửi qua tin nhắn. Truy cập ngày 31 tháng 8 năm 2026.
- MetaQuotes, “The checks a trading robot must pass before publication in the Market”, mql5.com/en/articles/2555, ngày 1 tháng 8 năm 2016 — kiểm tra bắt buộc trước công bố trên MQL5 Market và cấm nhập DLL cùng EX4/EX5 đã biên dịch trong sản phẩm Market. Truy cập ngày 31 tháng 8 năm 2026.
- LastPass, “Notice of Security Incident”, blog.lastpass.com/posts/notice-of-recent-security-incident — thông báo ngày 22 tháng 12 năm 2022 xác nhận bản sao lưu dữ liệu khách hàng, gồm kho mật khẩu, đã bị sao chép. Trường nhạy cảm như tên đăng nhập, mật khẩu và ghi chú được mã hóa; một số siêu dữ liệu, kể cả URL trang web, không được mã hóa. Truy cập ngày 31 tháng 8 năm 2026; thông báo lịch sử gốc được xác minh lại ngày 9 tháng 10 năm 2026.
- Ngân hàng Quốc gia Thụy Sĩ, “Swiss National Bank discontinues minimum exchange rate and lowers interest rate to -0.75%”, snb.ch/en/publications/communication/press-releases/2015/pre_20150115, ngày 15 tháng 1 năm 2015 — nguồn về quyết định và ngày ban hành. Trang không nêu giờ công bố; thông cáo đầy đủ có thể tải dưới dạng PDF. Truy cập ngày 31 tháng 8 năm 2026.
- Quy định (EU) 2022/2554 của Nghị viện và Hội đồng châu Âu ngày 14 tháng 12 năm 2022 về khả năng chống chịu hoạt động số của ngành tài chính (DORA), CELEX 32022R2554, Công báo EU L 333, 27.12.2022 — quản lý rủi ro ICT và báo cáo sự cố ICT nghiêm trọng của tổ chức tài chính thuộc phạm vi điều chỉnh. Điều 2(1) chịu sự chi phối của khoản 3 và 4, bao gồm “công ty đầu tư” tại điểm (e); Điều 2(3)(d) miễn trừ các chủ thể thuộc diện miễn theo Điều 2 và 3 của Chỉ thị 2014/65/EU. Văn bản tiếng Ba Lan dùng trong cuộc kiểm tra gốc được lấy qua publications.europa.eu/resource/celex/32022R2554; đầu trang ghi “27.12.2022 PL Official Journal of the European Union L 333/1”. Điều khoản cuối quy định rõ áp dụng từ ngày 17 tháng 1 năm 2025 và có hiệu lực vào ngày thứ hai mươi sau khi đăng Công báo. Công bố ngày 27 tháng 12 năm 2022 vì vậy dẫn đến ngày 16 tháng 1 năm 2023; văn bản không ghi trực tiếp ngày sau này bằng số. Truy cập ngày 1 tháng 9 năm 2026.
- MetaQuotes, tài liệu MQL5 Reference, “FileOpen” (mql5.com/en/docs/files/fileopen) và “WebRequest” (mql5.com/en/docs/network/webrequest) — thao tác tệp bị giới hạn trong vùng giới hạn tệp, còn WebRequest yêu cầu nhập URL máy chủ vào danh sách URL được phép trong “Expert Advisors” ở “Options”. Tài liệu nêu: “Các tệp được thao tác bằng phương tiện MQL5 không được nằm ngoài vùng giới hạn tệp”. Truy cập ngày 31 tháng 8 năm 2026. Ngữ cảnh thực thi DLL còn được xác minh trong “About Dynamic-Link Libraries” của Microsoft, learn.microsoft.com/en-us/windows/win32/dlls/about-dynamic-link-libraries, ngày 9 tháng 10 năm 2026.
- Ủy ban Thương mại Liên bang (FTC), “Are Public Wi-Fi Networks Safe? What You Need To Know”, consumer.ftc.gov/articles/are-public-wi-fi-networks-safe-what-you-need-know, tháng 2 năm 2023 — mã hóa phổ biến thường khiến kết nối Wi-Fi công cộng an toàn, nhưng kẻ lừa đảo cũng có thể mã hóa trang giả. Chỉ riêng mã hóa không xác định ai nhận thông tin. Truy cập ngày 31 tháng 8 năm 2026.
- Ví dụ thực tế tại Ba Lan: CERT Polska hoạt động trong NASK, viện nghiên cứu quốc gia, và thực hiện nhiệm vụ CSIRT NASK với tư cách một trong ba đội ứng phó cấp quốc gia của Ba Lan (cert.pl/o-nas). Biểu mẫu sự cố tại incydent.cert.pl có tiêu đề “Zgłoś incydent | CERT.PL”. Nguồn chỉ được dẫn như một kênh báo cáo sự cố kỹ thuật: nguồn này không xác lập quy trình khiếu nại tài chính hay quyết định hoàn tiền. Ngoài Ba Lan, hãy dùng kênh báo cáo quốc gia phù hợp. Truy cập ngày 1 tháng 9 năm 2026.
