1.Mã hóa đầu-cuối

• Dẫn xuất khóa trên thiết bị: từ mật khẩu chính, ứng dụng dẫn xuất khóa bằng PBKDF2-SHA256 với 600.000 vòng lặp. Mật khẩu chính không bao giờ được gửi đi.
• Khóa xác thực tách biệt: chỉ một "khóa xác thực" được dẫn xuất riêng được gửi tới máy chủ khi đăng nhập. Máy chủ lưu bản băm Argon2id của khóa này, nên ngay cả bản băm bị lộ cũng không giúp giải mã vault.
• Mã hóa vault: mọi mục vault — máy chủ, mật khẩu, khóa SSH riêng tư, snippet, cài đặt, quyết định known hosts, token tích hợp — được mã hóa bằng AES-256-GCM trước khi rời thiết bị. Khóa vault được lưu trên máy chủ dưới dạng khối đã mã hóa.
• Không có cửa hậu: khi đăng nhập nhanh tắt, chúng tôi không thể đọc, đặt lại hay khôi phục dữ liệu vault. Nếu mất cả mật khẩu chính và khóa khôi phục, dữ liệu không thể khôi phục.
• Đăng nhập nhanh (Google / Apple / Telegram / website): khi bật — mặc định — máy chủ giữ thêm một bản khóa vault của bạn, được mã hóa bằng một khóa riêng của máy chủ lưu ngoài cơ sở dữ liệu, để mở vault trên thiết bị mới mà không cần mật khẩu chính. Khi đó máy chủ có khả năng giải mã vault của bạn. Tắt trong ứng dụng (Cài đặt → Tài khoản → Đăng nhập nhanh) thì bản khóa này bị xóa ngay và chỉ mật khẩu chính mở được vault.
• Dữ liệu cục bộ: nội dung terminal, lịch sử lệnh, tệp SFTP và nhật ký kết nối không bao giờ được gửi lên máy chủ.

2.Bảo vệ đường truyền

• Mọi kết nối tới máy chủ dùng TLS.
• Bên trên TLS, nội dung yêu cầu và phản hồi API còn được mã hóa phong bì theo từng yêu cầu ở tầng ứng dụng: trao đổi khóa X25519 với khóa công khai của máy chủ và mã hóa AES-256-GCM. Nhờ đó dữ liệu vẫn được bảo vệ ngay cả khi có thiết bị trung gian chấm dứt TLS (proxy doanh nghiệp, CDN).
• Mỗi phong bì mang dấu thời gian và chỉ được chấp nhận một lần trong một khoảng thời gian ngắn, để chống phát lại (replay).

3.Tài khoản và xác thực

• Xác thực hai lớp (TOTP) với mã khôi phục; máy chủ chỉ lưu bản băm của mã khôi phục.
• Quản lý thiết bị: xem mọi thiết bị đã đăng nhập (tên, nền tảng, IP, lần hoạt động cuối) và thu hồi ngay lập tức. Refresh token chỉ được lưu dưới dạng băm.
• Giới hạn tần suất cho đăng nhập, đặt lại mật khẩu, lời mời và các điểm cuối nhạy cảm để chống dò mật khẩu và lạm dụng.
• Mã đặt lại mật khẩu dùng một lần, lưu dạng băm và hết hạn nhanh.
• Nhật ký bảo mật ghi lại đăng nhập, đăng nhập thất bại, thay đổi 2FA, thu hồi thiết bị và hoạt động team, kèm IP và thời điểm, lưu 12 tháng.
• Hỗ trợ khóa bảo mật FIDO2 cho xác thực SSH từ keychain.

4.Team, chia sẻ terminal và chuyển tiếp

• Team vault: mỗi thành viên có cặp khóa riêng; khóa team được niêm phong (mã hóa) cho khóa công khai của từng thành viên. Máy chủ chỉ lưu bản mã của mục team và khóa đã niêm phong.
• Multiplayer (chia sẻ terminal): khung dữ liệu được mã hóa đầu-cuối; khóa giải mã nằm trong phần fragment (#) của liên kết và không bao giờ gửi tới máy chủ. Máy chủ chỉ chuyển tiếp trong bộ nhớ, phòng hết hạn sau 12 giờ. Hãy chỉ gửi liên kết cho người bạn tin cậy — ai có liên kết đều xem được phiên.
• Ứng dụng web: SSH chạy ngay trong trình duyệt (WebAssembly). Máy chủ chỉ chuyển tiếp luồng byte SSH đã mã hóa tới máy đích; nó biết host:port, thời gian, số byte và IP, nhưng không thấy nội dung hay thông tin đăng nhập. Việc chuyển tiếp yêu cầu đăng nhập để chống lạm dụng. Vault của ứng dụng web lưu trong IndexedDB, mã hóa bằng mật khẩu chính.
• SSH ID: chỉ khóa công khai bạn chọn mới được công bố; khóa riêng tư không bao giờ rời vault.

5.Hạ tầng và vận hành

• Máy chủ chạy trong container với đặc quyền tối thiểu: ảnh tối giản và tiến trình chạy dưới một tài khoản hệ thống riêng, không phải root.
• Hạ tầng do [NHÀ CUNG CẤP HẠ TẦNG] cung cấp, dữ liệu đặt tại [QUỐC GIA / KHU VỰC ĐẶT MÁY CHỦ].
• Quyền truy cập quản trị hạ tầng chỉ cấp cho nhân sự cần thiết.
• Thư viện phụ thuộc được cập nhật thường xuyên để vá lỗ hổng đã biết.

6.Ứng phó sự cố và thông báo vi phạm

Khi phát hiện sự cố, chúng tôi khoanh vùng, khắc phục, điều tra nguyên nhân và lưu hồ sơ. Nếu sự cố ảnh hưởng tới dữ liệu cá nhân, chúng tôi thông báo cho Cục An ninh mạng và phòng, chống tội phạm sử dụng công nghệ cao (A05) – Bộ Công an trong vòng 72 giờ khi pháp luật yêu cầu, thông báo cho cơ quan giám sát khác theo luật áp dụng, và thông báo cho người dùng bị ảnh hưởng không chậm trễ bất hợp lý, kèm hướng dẫn cụ thể. Xem thêm Chính sách quyền riêng tư.

7.Báo cáo lỗ hổng

Chúng tôi hoan nghênh báo cáo từ cộng đồng nghiên cứu bảo mật. Gửi email tới [EMAIL BÁO CÁO LỖ HỔNG] (tiếng Việt hoặc tiếng Anh), bao gồm:

• mô tả lỗ hổng và thành phần bị ảnh hưởng (website, API, ứng dụng nào, phiên bản, nền tảng);
• các bước tái hiện chi tiết, bằng chứng khái niệm (PoC), ảnh chụp hoặc video nếu có;
• đánh giá tác động theo bạn (ví dụ điểm CVSS);
• thông tin liên hệ và tên bạn muốn được ghi nhận (nếu có).

Nếu cần gửi thông tin nhạy cảm, hãy đề nghị trong email đầu tiên để chúng tôi thống nhất kênh mã hóa. Vui lòng không công bố lỗ hổng trước khi chúng tôi phát hành bản sửa hoặc trước khi hết thời hạn công bố phối hợp ở mục 10.

8.Phạm vi

Trong phạm vi

• Website https://vnterm.com và các trang tài khoản, trang xem chia sẻ;
• API đồng bộ, máy chủ chuyển tiếp ứng dụng web và máy chủ Multiplayer;
• Ứng dụng VNTerm cho macOS, Windows, Linux, Android, iOS và ứng dụng web;
• Thiết kế mật mã: dẫn xuất khóa, mã hóa vault, mã hóa phong bì, niêm phong khóa team.

Ngoài phạm vi

• Tấn công từ chối dịch vụ (DoS/DDoS) hoặc kiểm thử tải;
• Tấn công phi kỹ thuật (social engineering, lừa đảo) nhằm vào nhân viên hoặc người dùng;
• Tấn công vật lý vào văn phòng, trung tâm dữ liệu hoặc thiết bị;
• Hệ thống của bên thứ ba (nhà cung cấp hạ tầng, email, CDN, DigitalOcean, máy chủ SSH của người dùng) — hãy báo trực tiếp cho họ;
• Báo cáo chỉ từ công cụ quét tự động mà không chứng minh được tác động; thiếu header bảo mật không gây rủi ro cụ thể; tự tấn công XSS (self-XSS); clickjacking trên trang không có thao tác nhạy cảm;
• Lỗ hổng chỉ khai thác được trên thiết bị đã bị chiếm quyền root/admin hoặc trình duyệt, hệ điều hành đã hết hỗ trợ.

9.Quy tắc nghiên cứu và bảo vệ pháp lý (safe harbour)

Khi nghiên cứu, vui lòng:

• chỉ sử dụng tài khoản của chính bạn hoặc tài khoản thử nghiệm bạn tạo; không truy cập, sửa đổi hay xóa dữ liệu của người khác;
• dừng lại và báo cho chúng tôi ngay khi tiếp cận được dữ liệu của người dùng khác, và không giữ lại dữ liệu đó;
• không làm suy giảm dịch vụ, không gửi spam lời mời, không lạm dụng máy chủ chuyển tiếp để tấn công hệ thống khác;
• giữ bí mật thông tin lỗ hổng cho tới khi được công bố phối hợp.

Nếu bạn tuân thủ chính sách này một cách thiện chí, chúng tôi coi hoạt động nghiên cứu của bạn là được phép, sẽ không khởi kiện hay yêu cầu cơ quan chức năng xử lý bạn vì hoạt động đó, và sẽ hỗ trợ giải thích nếu bên thứ ba khiếu nại. Chính sách này không thể cho phép bạn kiểm thử hệ thống của bên thứ ba và không ràng buộc cơ quan nhà nước; bạn vẫn phải tuân thủ pháp luật, bao gồm Luật An ninh mạng 2018.

Hiện chúng tôi chưa có chương trình thưởng tiền (bug bounty). Với sự đồng ý của bạn, chúng tôi sẽ ghi nhận đóng góp trong ghi chú phát hành.

10.Cam kết phản hồi

11.Lời khuyên cho người dùng

• Dùng mật khẩu chính dài, duy nhất; cất khóa khôi phục ở nơi an toàn ngoài thiết bị.
• Bật 2FA và định kỳ kiểm tra danh sách thiết bị; thu hồi thiết bị lạ hoặc bị mất.
• Ưu tiên khóa SSH (hoặc khóa FIDO2) thay vì mật khẩu; xác minh vân tay khóa máy chủ khi kết nối lần đầu.
• Chỉ gửi liên kết chia sẻ terminal cho người tin cậy, và kết thúc phiên chia sẻ khi xong.
• Xoay vòng khóa và mật khẩu khi một thành viên rời team.
• VNTerm sẽ không bao giờ hỏi mật khẩu chính hay khóa khôi phục của bạn.

12.Liên hệ

Xem thêm: Điều khoảnQuyền riêng tưCookie

Văn bản tiếng Việt là bản có giá trị ưu tiên áp dụng đối với người dùng tại Việt Nam. Bản tiếng Anh được cung cấp cho người dùng quốc tế và được ưu tiên áp dụng đối với họ, trừ khi pháp luật nơi họ cư trú quy định khác.

1.End-to-end encryption

• On-device key derivation: the app derives keys from your master password with PBKDF2-SHA256 at 600,000 iterations. The master password is never transmitted.
• Separate auth key: only a separately derived "auth key" is sent to the server at sign-in. The server stores an Argon2id hash of it, so even a leaked hash does not help decrypt your vault.
• Vault encryption: every vault item — hosts, passwords, SSH private keys, snippets, settings, known-host decisions, integration tokens — is encrypted with AES-256-GCM before it leaves your device. The vault key is stored on the server only as an encrypted blob.
• No back door: with quick sign-in off, we cannot read, reset or recover vault data. If you lose both your master password and your recovery key, the data cannot be recovered.
• Quick sign-in (Google / Apple / Telegram / the website): while it is on — the default — the server keeps an extra copy of your vault key, encrypted with a server key kept outside the database, so your vault opens on a new device without the master password. The server is then able to decrypt your vault. Turn it off in the app (Settings → Account → Quick sign-in) and this copy is deleted at once; only your master password opens your vault.
• Local-only data: terminal content, command history, SFTP files and connection logs are never sent to the server.

2.Transport protection

• All connections to our servers use TLS.
• On top of TLS, API request and response bodies are protected with per-request envelope encryption at the application layer: X25519 key agreement with the server's public key and AES-256-GCM encryption. Data stays protected even if a middlebox terminates TLS (corporate proxy, CDN).
• Each envelope is timestamped and accepted only once within a short time window, providing replay protection.

3.Accounts and authentication

• Two-factor authentication (TOTP) with recovery codes; the server stores only hashes of the recovery codes.
• Device management: see every signed-in device (name, platform, IP, last seen) and revoke it instantly. Refresh tokens are stored only as hashes.
• Rate limiting on sign-in, password reset, invitations and other sensitive endpoints to stop credential guessing and abuse.
• Password-reset codes are single-use, stored hashed and expire quickly.
• Security audit log records sign-ins, failed sign-ins, 2FA changes, device revocations and team activity with IP and timestamp, kept for 12 months.
• Support for FIDO2 security keys for SSH authentication from the keychain.

4.Teams, terminal sharing and relays

• Team vaults: each member has their own key pair; the team key is sealed (encrypted) to each member's public key. The server stores only team-item ciphertext and the sealed keys.
• Multiplayer (terminal sharing): frames are end-to-end encrypted; the decryption key lives in the link fragment (#) and is never sent to the server. The server relays in memory only and rooms expire after 12 hours. Share links only with people you trust — anyone with the link can watch the session.
• Web app: SSH runs inside your browser (WebAssembly). The server only relays the already-encrypted SSH byte stream to the destination; it learns host:port, timing, byte counts and your IP, never content or credentials. The relay requires sign-in to prevent abuse. The web app's vault is stored in IndexedDB, encrypted with your master password.
• SSH ID: only the public keys you choose are published; private keys never leave your vault.

5.Infrastructure and operations

• Servers run in least-privilege containers: a minimal image, with the process running as a dedicated non-root system user.
• Infrastructure is provided by [NHÀ CUNG CẤP HẠ TẦNG], with data located in [QUỐC GIA / KHU VỰC ĐẶT MÁY CHỦ].
• Administrative access to infrastructure is limited to necessary personnel.
• Dependencies are updated regularly to patch known vulnerabilities.

6.Incident response and breach notification

When we detect an incident we contain it, remediate, investigate the root cause and keep records. If personal data is affected, we notify the Department of Cybersecurity and High-Tech Crime Prevention (A05), Ministry of Public Security of Vietnam within 72 hours where the law requires, notify other supervisory authorities as applicable law requires, and inform affected users without undue delay with concrete guidance. See also the Privacy Policy.

7.Reporting a vulnerability

We welcome reports from the security community. Email [EMAIL BÁO CÁO LỖ HỔNG] (Vietnamese or English) and include:

• a description of the issue and the affected component (website, API, which app, version, platform);
• detailed reproduction steps, a proof of concept, screenshots or video if available;
• your assessment of the impact (for example a CVSS score);
• how to reach you and the name you would like credited (if any).

If you need to send sensitive details, say so in your first email and we will agree on an encrypted channel. Please do not disclose the issue publicly before a fix is released or the coordinated disclosure period in section 10 has passed.

8.Scope

In scope

• The website https://vnterm.com, including account pages and the share viewer;
• The sync API, the web-app relay and the Multiplayer server;
• The VNTerm apps for macOS, Windows, Linux, Android, iOS and the web app;
• The cryptographic design: key derivation, vault encryption, envelope encryption, team-key sealing.

Out of scope

• Denial-of-service (DoS/DDoS) attacks or load testing;
• Social engineering or phishing of staff or users;
• Physical attacks against offices, data centres or devices;
• Third-party systems (hosting, email, CDN, DigitalOcean, users' own SSH servers) — please report to them directly;
• Unverified automated-scanner output; missing security headers without a demonstrable risk; self-XSS; clickjacking on pages without sensitive actions;
• Issues exploitable only on rooted/jailbroken or already-compromised devices, or on unsupported browsers and operating systems.

9.Research rules and safe harbour

While researching, please:

• use only your own accounts or test accounts you create; never access, modify or delete other people's data;
• stop and tell us immediately if you reach another user's data, and do not keep it;
• avoid degrading the service, do not spam invitations, and do not use our relays to attack other systems;
• keep vulnerability details confidential until coordinated disclosure.

If you make a good-faith effort to follow this policy, we will consider your research authorized, will not take legal action or ask authorities to act against you for it, and will help explain your activity if a third party complains. This policy cannot authorize testing of third-party systems and does not bind government authorities; you must still comply with the law, including Vietnam's Law on Cybersecurity 2018.

We do not currently run a paid bug bounty. With your permission, we will credit your contribution in the release notes.

10.Response targets

11.Tips for users

• Use a long, unique master password and keep your recovery key somewhere safe off the device.
• Enable 2FA and review your device list regularly; revoke unknown or lost devices.
• Prefer SSH keys (or FIDO2 keys) over passwords, and verify host-key fingerprints on first connection.
• Send terminal-share links only to people you trust, and end the share when you are done.
• Rotate keys and passwords when a member leaves a team.
• VNTerm will never ask for your master password or recovery key.

12.Contact

See also: TermsPrivacyCookies

The Vietnamese version prevails for users in Vietnam. This English version is provided for international users and prevails for them unless the law of their country of residence provides otherwise.