Trình tạo mật khẩu hàng loạt miễn phí

Tạo nhiều mật khẩu mạnh cùng lúc. Tùy chỉnh số lượng, độ dài và ký tự, sau đó tải xuống dưới dạng tệp văn bản.

Mật khẩu được tạo cục bộ trên thiết bị của bạn
Nhấp « Tạo mật khẩu » để bắt đầu

    Tạo mật khẩu hàng loạt

    Công cụ này tạo nhiều mật khẩu mạnh về mặt mã hóa trong một lần thao tác. Hoàn hảo để chuẩn bị danh sách cho việc đào tạo nhân viên mới, tạo tài khoản hàng loạt hoặc quản lý kho mật khẩu. Mỗi mật khẩu được tạo qua bộ tạo ngẫu nhiên tích hợp của trình duyệt.

    Các mức độ mạnh

    Câu hỏi thường gặp

    Các mật khẩu này có thực sự ngẫu nhiên không?

    Có. Mật khẩu được tạo bằng window.crypto.getRandomValues(), cung cấp giá trị ngẫu nhiên an toàn về mặt mã hóa, phù hợp với mục đích bảo mật.

    Tôi có thể tạo hơn 100 mật khẩu không?

    Công cụ giới hạn việc tạo ở 100 mật khẩu mỗi lần để tránh làm chậm trình duyệt. Tạo nhiều lô riêng nếu cần.

    Làm thế nào để lưu trữ tệp đã tải xuống?

    Lưu tệp .txt ở vị trí an toàn, tốt nhất là được mã hóa. Không bao giờ commit nó vào kho mã hoặc chia sẻ qua các kênh không an toàn. Xóa nó sau khi phân phát cho người dùng.

    Số ngẫu nhiên tốt đến từ đâu

    Máy tính, theo thiết kế, là tất định. Với cùng đầu vào và cùng mã, nó luôn cho ra cùng đầu ra. Đó chính xác là tính chất bạn muốn từ CPU chạy bảng tính, và chính xác là tính chất bạn không muốn từ bộ tạo mật khẩu. Nếu kẻ tấn công có thể tái tạo chuỗi giá trị mà bộ tạo đã phát, họ có thể tái tạo mọi mật khẩu nó từng tạo ra.

    Vì vậy, bộ tạo thu thập «entropy» (tín hiệu vật lý không thể đoán trước từ bên ngoài chương trình) và dùng nó để gieo mầm cho thuật toán gọi là CSPRNG (Bộ tạo số giả ngẫu nhiên an toàn về mặt mật mã). Chữ «giả» là trung thực: các bit được tạo ra bởi thuật toán, không phải vật lý. «An toàn về mặt mật mã» có nghĩa là ngay cả kẻ tấn công xem một chuỗi dài đầu ra quá khứ cũng không thể đoán byte tiếp theo tốt hơn ngẫu nhiên. Theodore Ts'o đã triển khai /dev/random trong nhân Linux năm 1994, và macOS, BSD, Solaris và Windows (với BCryptGenRandom) đều áp dụng giao diện tương đương. Ẩn bên dưới, chúng kết hợp mọi nguồn jitter vật lý có thể (thời gian tìm kiếm đĩa, thời điểm đến của gói mạng, đầu vào bàn phím và chuột, ngắt phần cứng, RDRAND trên CPU Intel có tính năng này) qua hàm băm mật mã, rồi liên tục gieo lại.

    Trong trình duyệt, Web Cryptography API của W3C cung cấp điều này qua window.crypto.getRandomValues(typedArray): truyền cho nó một typed array, trình duyệt lấp đầy nó bằng các byte ngẫu nhiên mạnh về mặt mật mã. Tối đa mỗi lần gọi là 65.536 byte (công cụ này giữ xa dưới mức đó). API này đã được hỗ trợ cơ sở trên Chrome, Firefox, Safari và Edge từ tháng 7 năm 2015: không có khả năng thực tế nào mà người dùng truy cập công cụ này với trình duyệt thiếu tính năng đó.

    Entropy mật khẩu, phép toán thực tế

    Độ «mạnh» của mật khẩu, theo nghĩa mật mã học hình thức, được đo bằng số bit entropy. Công thức tiêu chuẩn cho mật khẩu được tạo ngẫu nhiên là:

    Entropy = L × log₂(R)

    trong đó L là độ dài tính bằng ký tự và R là kích thước bộ ký tự. Entropy mỗi ký tự theo bộ ký tự:

    Con số 94 đáng được làm rõ: mã ASCII 32 đến 126 là các ký tự in được (95 tổng); loại trừ dấu cách còn lại 94 glyph không phải dấu cách có thể nhìn thấy (26 chữ thường + 26 chữ hoa + 10 chữ số + 32 dấu câu/ký hiệu). Áp công thức với số cụ thể:

    Cộng đồng mật mã học đã thống nhất ba ngưỡng: 80 bit là mức tối thiểu (sàn khuyến nghị của NIST cho đến năm 2014), đạt được ở ~13 ký tự với bộ 94 ký tự đầy đủ; 100 bit theo yêu cầu của ANSSI (tương đương Pháp của NSA) cho mật khẩu bảo vệ hệ thống mã hóa, đạt được ở ~16 ký tự; và 128 bit khớp với độ mạnh khóa đối xứng của AES-128, được khuyến nghị cho mật khẩu chính của vault, đạt được ở ~20 ký tự.

    Lưu ý lớn: phép toán này chỉ áp dụng cho mật khẩu ngẫu nhiên. Nếu con người chọn mật khẩu, entropy hiệu quả thấp hơn rất nhiều. Kẻ tấn công không liệt kê R^L chuỗi theo thứ tự bảng chữ cái, họ chạy chương trình đoán được gieo bằng danh sách mật khẩu rò rỉ, từ điển, các thay thế phổ biến (a→@, o→0, s→$), đường đi bàn phím và các mô hình thống kê về cách con người xây dựng chuỗi dễ nhớ. Nghiên cứu năm 2012 của Joseph Bonneau trên corpus ẩn danh gồm 70 triệu mật khẩu Yahoo (Hội thảo IEEE về Bảo mật và Quyền riêng tư) phát hiện rằng mật khẩu do người dùng chọn cho «ít hơn 10 bit bảo mật trước cuộc tấn công quét trực tuyến, và chỉ khoảng 20 bit trước cuộc tấn công từ điển ngoại tuyến tối ưu.» Hai mươi bit là một triệu lượt đoán. GPU hiện đại làm điều đó trong vài microsecond.

    NIST SP 800-63B, những thay đổi năm 2017 và lại vào năm 2025

    Trong khoảng ba mươi năm, chính sách bảo mật Bắc Mỹ về mật khẩu xuất phát từ một ấn phẩm NIST năm 1985 khuyến nghị luân chuyển định kỳ bắt buộc, các lớp ký tự hỗn hợp và độ dài tối thiểu ngắn. Bill Burr, tác giả của tài liệu tiếp theo năm 2003 đã pháp điển hóa quy tắc «hoa + thường + chữ số + ký hiệu, đổi mỗi 90 ngày», đã công khai rút lại nó vào năm 2017, nói với Wall Street Journal rằng «phần lớn những gì tôi đã làm, tôi nay hối tiếc.» NIST đã chính thức hóa sự đảo ngược đó cùng năm.

    NIST SP 800-63B Rev 3 (tháng 6 năm 2017) thực hiện hai thay đổi thế hệ. Mục 5.1.1.2 ghi: «Các bên xác minh KHÔNG NÊN yêu cầu thay đổi bí mật đã ghi nhớ một cách tùy tiện (ví dụ: định kỳ)», vì luân chuyển bắt buộc khiến người dùng chọn mật khẩu yếu hơn, dễ đoán hơn. Cùng mục đó: «Các bên xác minh KHÔNG NÊN áp đặt các quy tắc cấu thành khác (ví dụ: yêu cầu hỗn hợp các loại ký tự) cho bí mật đã ghi nhớ», vì buộc có chữ số và ký hiệu đẩy người dùng về phía Password1! hơn là cụm mật khẩu dài hơn. Rev 3 đặt độ dài tối thiểu do người đăng ký chọn là 8 ký tự, yêu cầu các bên xác minh chấp nhận đến 64, bắt buộc kiểm tra mật khẩu mới với danh sách chặn vi phạm, và rõ ràng yêu cầu cho phép trình quản lý mật khẩu và dán từ clipboard.

    NIST SP 800-63B Rev 4 (hoàn thiện ngày 31 tháng 7 năm 2025) nâng cao tiêu chuẩn: mật khẩu một yếu tố nay yêu cầu tối thiểu 15 ký tự («Các bên xác minh và CSP PHẢI yêu cầu mật khẩu được sử dụng làm cơ chế xác thực một yếu tố có độ dài tối thiểu 15 ký tự»). Mật khẩu đa yếu tố giữ nguyên 8 ký tự vì yếu tố thứ hai mang trọng lượng bảo mật. Các quy tắc cấu thành vẫn bị cấm, và cách diễn đạt chuyển từ «KHÔNG NÊN» của Rev 3 thành «KHÔNG ĐƯỢC» của Rev 4, biến nó thành yêu cầu cứng chứ không phải khuyến nghị. Luân chuyển vẫn không được khuyến khích trừ khi có bằng chứng bị xâm phạm.

    Công cụ Absolutool mặc định là 16 ký tự với cả bốn lớp ký tự, cho khoảng 104 bit entropy và thoải mái vượt cả ngưỡng tối thiểu 15 ký tự của Rev 4 lẫn ngưỡng tương đương đối xứng 80 bit. Mức tối đa 128 ký tự của công cụ nằm chính xác gấp đôi độ dài tối đa mà NIST bắt buộc các bên xác minh phải chấp nhận, không có trường hợp thực tế nào mà mật khẩu được tạo sẽ quá dài để máy chủ chấp nhận.

    RockYou, thảm họa vẫn còn ám ảnh năm 2026

    Vào tháng 12 năm 2009, công ty trò chơi xã hội RockYou bị tấn công qua SQL injection kinh điển. Vụ vi phạm lộ ra hơn 32 triệu tài khoản người dùng bao gồm mật khẩu của những tài khoản đó dưới dạng văn bản thuần: RockYou đã lưu trữ chúng không mã hóa. Chính sách mật khẩu của công ty lúc đó chỉ yêu cầu năm ký tự và không cho phép ký tự đặc biệt, điều đó đã làm trầm trọng thêm lỗ hổng.

    Tệp bị vi phạm, sớm được đặt tên rockyou.txt, được công bố công khai và vẫn là danh sách từ mật khẩu được tham chiếu nhiều nhất thế giới. Nó được tích hợp mặc định với Kali Linux cho người kiểm tra thâm nhập; mọi công cụ tấn công từ điển đều kiểm tra với nó; các dịch vụ nhồi thông tin xác thực thương mại duy trì nó như đường cơ sở. Mười sáu năm sau, kẻ tấn công vẫn bắt được tài khoản đang hoạt động bằng mật khẩu xuất hiện lần đầu trong vụ rò rỉ năm 2009. Các bài học được truyền bá: máy chủ không bao giờ nên thấy mật khẩu văn bản thuần (công cụ này tạo phía khách, vì vậy máy chủ không bao giờ thấy chúng); mật khẩu đã lưu trữ nên được băm với hàm chậm, muối, tốn bộ nhớ như Argon2id hoặc bcrypt, không phải hàm băm nhanh như MD5 hoặc SHA-1 không muối; mật khẩu duy nhất mỗi trang là phòng thủ duy nhất chống lại cuộc tấn công phát lại thông tin xác thực bị đánh cắp đã thống trị thập kỷ vi phạm vừa qua.

    Have I Been Pwned và kho vi phạm

    Have I Been Pwned (HIBP), được điều hành bởi Giám đốc Vùng Microsoft Troy Hunt, đã trở thành nguồn có thẩm quyền tiêu chuẩn cho câu hỏi «mật khẩu này đã xuất hiện trong vi phạm chưa?» Hunt ra mắt HIBP năm 2013 như một chỉ mục có thể tìm kiếm của các địa chỉ email bị vi phạm; sau đó anh thêm kho Pwned Passwords, danh sách có thể tải xuống của mọi mật khẩu từng thấy trong vi phạm công khai, được đánh chỉ mục theo hàm băm SHA-1. Pwned Passwords V2 ra mắt ngày 22 tháng 2 năm 2018 và giới thiệu API k-ẩn danh của tập dữ liệu (được xây dựng với Cloudflare): máy khách chỉ gửi năm ký tự đầu của hàm băm SHA-1; máy chủ trả về mọi hàm băm đầy đủ bắt đầu bằng năm ký tự đó cùng số lần quan sát; máy khách so sánh cục bộ. Mật khẩu (và thậm chí hàm băm đầy đủ) không bao giờ rời thiết bị của người dùng.

    Đối với bộ tạo hàng loạt, sự liên quan là hai chiều. Bất kỳ mật khẩu nào đã có trong HIBP, theo định nghĩa, không phải mật khẩu mới hữu ích, nó sẽ là thứ đầu tiên bất kỳ kẻ tấn công nhồi thông tin xác thực nào thử. Và vì công cụ này tạo với đầy đủ tính ngẫu nhiên CSPRNG từ bảng chữ cái 94 ký tự, xác suất mật khẩu 16 ký tự vừa tạo đã có trong HIBP là, về mặt thực tế, bằng không. (Tổng số mật khẩu ký hiệu ASCII 16 ký tự là 94^16 ≈ 3,7 × 10³¹; HIBP chứa khoảng 10⁹ mật khẩu đã biết; xác suất va chạm ≈ 10⁻²².)

    Ý nghĩa thực tế của «X bit entropy» trong thời gian crack

    Con số mang lại ý nghĩa cụ thể cho bit entropy là «mức tấn công hiện đại cần bao lâu?», và câu trả lời phụ thuộc hoàn toàn vào thuật toán băm. Tiêu chuẩn được cộng đồng xuất bản cho hashcat v6.2.6 trên một Nvidia RTX 4090 ghi khoảng 300 GH/s cho hàm băm NTLM (hàm băm Windows cũ của Microsoft) và 200 kH/s cho bcrypt. Khoảng cách bốn bậc độ lớn giữa hai con số đó là thực tế quan trọng: NTLM được thiết kế để nhanh, bcrypt được thiết kế để chậm.

    Bảng mật khẩu Hive Systems được trích dẫn rộng rãi chuyển các tiêu chuẩn thành số thời gian crack. Phiên bản 2025 tính với hàm băm MD5 (gần nhanh bằng NTLM) cho ~59 phút trên một RTX 4090 để brute-force mật khẩu 8 ký tự từ bộ ký tự đầy đủ. Cùng mật khẩu 8 ký tự đó với hàm băm bcrypt mất ~99 năm trên cùng phần cứng. Khoảng cách bốn bậc độ lớn đó là sự khác biệt giữa «bị rò rỉ hôm qua, bị crack trước bữa trưa» và «bị rò rỉ hôm qua, sẽ tồn tại lâu hơn bạn.»

    Người dùng cuối kiểm soát độ dài và bộ ký tự mật khẩu. Họ không kiểm soát thuật toán băm mà máy chủ sử dụng để lưu trữ nó. Hầu hết các dịch vụ hiện đại được quản lý tốt sử dụng bcrypt, scrypt hoặc Argon2id, tất cả đều cố ý chậm. Các dịch vụ cũ hơn và bị vi phạm thường dùng MD5 hoặc SHA-1 không muối, đó là lý do tại sao các kho vi phạm cũ có thể bị crack ở tốc độ trích dẫn ở trên. Với mật khẩu được tạo bởi công cụ này: mật khẩu ngẫu nhiên 16 ký tự về cơ bản an toàn với bcrypt mãi mãi và tạm thời an toàn với MD5; mật khẩu 20 ký tự là quá mức cho cả hai. Không có mô hình mối đe dọa thực tế nào mà đầu ra CSPRNG 20+ ký tự là liên kết yếu.

    FIDO2, WebAuthn và quá trình chuyển đổi sang passkey

    Dự đoán tồn tại lâu nhất trong ngành bảo mật là mật khẩu sắp biến mất. Từ năm 2019 cuối cùng đã có sự thay thế đáng tin cậy: passkey, tên marketing dành cho người tiêu dùng cho thông tin xác thực được phát hành theo tiêu chuẩn FIDO2 / WebAuthn. WebAuthn Mức 1 trở thành Khuyến nghị W3C vào ngày 4 tháng 3 năm 2019; Mức 2 theo sau ngày 8 tháng 4 năm 2021. Mô hình mật mã là bất đối xứng: khi người dùng đăng ký, bộ xác thực tạo cặp khóa công khai/riêng tư, gửi khóa công khai cho máy chủ và lưu trữ khóa riêng tư trong phần cứng cục bộ an toàn. Xác thực sử dụng thách thức-phản hồi được ký bằng khóa riêng tư. Máy chủ không bao giờ thấy bí mật, nghĩa là vi phạm phía máy chủ không thể lộ thông tin xác thực đăng nhập.

    Việc triển khai trên các nền tảng lớn diễn ra đồng bộ trong năm 2022-2023: Apple demo passkey tại WWDC ngày 6 tháng 6 năm 2022 và phát hành công khai với iOS 16, iPadOS 16 và macOS Ventura vào tháng 9 năm 2022, đồng bộ qua iCloud Keychain mã hóa đầu-cuối. Google công bố hỗ trợ passkey cho Android và Chrome ngày 12 tháng 10 năm 2022; hỗ trợ Chrome ổn định có trong Chrome 108 vào tháng 12 năm 2022, đồng bộ qua Google Password Manager. Microsoft công bố quản lý passkey cho Windows 11 ngày 21 tháng 9 năm 2023, tích hợp với Windows Hello.

    Passkey giải quyết các lớp thất bại mật khẩu đau đớn nhất (lừa đảo, nhồi thông tin xác thực, vi phạm máy chủ), nhưng chưa loại bỏ mật khẩu vì: nhiều trang web và hầu hết hệ thống cũ vẫn yêu cầu mật khẩu; passkey gắn với thiết bị hoặc hệ sinh thái đồng bộ (người dùng không có tài khoản Apple, Google hay Microsoft cần phương án thay thế); các hệ thống không giao diện (thiết bị IoT, tài khoản dịch vụ phía máy chủ, tình huống onboarding hàng loạt) không thể dựa vào bộ xác thực sinh trắc học ở bước đăng ký; và nhiều chính sách mật khẩu doanh nghiệp, hệ thống ngân hàng và cổng thông tin chính phủ vẫn bắt buộc mật khẩu. Tạo mật khẩu hàng loạt nằm gọn trong nhóm hai và ba: quản trị viên hệ thống cấp phép 50 tài khoản mới không thể yêu cầu từng người dùng tương lai đăng ký passkey trước khi tài khoản tồn tại.

    Tại sao tạo mật khẩu phía khách quan trọng đặc biệt

    Hãy tưởng tượng một công cụ cạnh tranh POST yêu cầu của người dùng đến máy chủ, máy chủ chạy bộ tạo ngẫu nhiên và trả về danh sách dưới dạng JSON. Dù mọi thứ hoạt động đúng như quảng cáo, các bên sau có thể thấy mật khẩu được tạo dưới dạng văn bản thuần: bộ nhớ tiến trình máy chủ khi yêu cầu đang được xử lý; nhật ký yêu cầu máy chủ (nếu ghi nhật ký không cẩn thận); bất kỳ dịch vụ APM hay theo dõi lỗi nào máy chủ kết nối; reverse proxy kết thúc TLS (Cloudflare, load balancer AWS, nginx); bất kỳ công cụ gỡ lỗi nào chạy trên máy chủ; bất kỳ kẻ tấn công nào trong tương lai có quyền truy cập vào bất kỳ nhật ký đó. Mô hình RockYou, với mọi hệ quả của nó, áp dụng.

    Khi việc tạo diễn ra qua window.crypto.getRandomValues() trong trình duyệt của người dùng, không có gì trong số đó áp dụng. Các byte được tạo ra bên trong tiến trình trình duyệt, trên máy của người dùng, bởi mã người dùng có thể kiểm tra (trang có thể xem nguồn). Chúng không bao giờ đi qua mạng. Máy chủ của Absolutool không bao giờ thấy chúng, không bao giờ ghi lại chúng, và không thể rò rỉ chúng trong vi phạm tương lai vì nó không bao giờ có chúng. Thực thể duy nhất thấy mật khẩu được tạo là người dùng, bất kỳ ai có quyền truy cập vào phiên trình duyệt của người dùng (thường chỉ người dùng), và bất kỳ tiện ích mở rộng trình duyệt nào chạy trên trang. Đây là cùng mô hình bảo mật với bộ tạo cục bộ của trình quản lý mật khẩu, và mạnh hơn mô hình của bất kỳ dịch vụ web nào trả về mật khẩu được tạo từ máy chủ.

    Mirai 2016, ví dụ tiêu cực về mật khẩu mặc định IoT

    Ví dụ tiêu cực kinh điển về «hãy dùng cùng mật khẩu mặc định trên mỗi thiết bị» là botnet Mirai. Mirai khai thác danh sách cứng gồm khoảng 62 tổ hợp tên người dùng/mật khẩu mặc định của nhà sản xuất (admin/admin, root/root, root/xc3511, root/vizxv) để lây nhiễm hàng trăm nghìn camera IP, đầu ghi DVR và router gia đình vào cuối năm 2016, sau đó dùng chúng vào ngày 21 tháng 10 năm 2016 để hạ gục nhà cung cấp DNS lớn Dyn, tạm thời làm gián đoạn Twitter, Reddit, Netflix và GitHub. Bộ tạo mật khẩu hàng loạt chính xác là công cụ phù hợp cho giải pháp thay thế: tạo một mặc định mạnh duy nhất cho mỗi thiết bị trên dây chuyền sản xuất, in lên nhãn dán, đặt trong hộp.

    Câu hỏi thêm

    Tại sao NIST khuyến nghị độ dài hơn độ phức tạp?

    Vì ép buộc độ phức tạp (một chữ số, một ký hiệu, một chữ hoa) đẩy người dùng vào các mẫu có thể đoán trước mà kẻ tấn công đã lập mô hình. Password1! về mặt toán học có nhiều entropy hơn password, nhưng trên thực tế danh sách từ của mọi kẻ tấn công đều bắt đầu ở đó. Một chuỗi 20 ký tự toàn chữ thường từ CSPRNG có ~94 bit entropy và không thể đoán bởi bất kỳ danh sách từ nào vì nó không khớp với danh sách từ. NIST SP 800-63B Rev 4 (tháng 7 năm 2025) biến việc cấm các quy tắc cấu thành thành yêu cầu cứng KHÔNG ĐƯỢC.

    Tôi có nên dùng cụm mật khẩu thay thế không?

    Với mật khẩu cần ghi nhớ, đúng, đó là điều xkcd #936 (10 tháng 8 năm 2011) đã lập luận. Phương pháp Diceware (Arnold Reinhold, 1995) cho 12,9 bit mỗi từ từ danh sách 7.776 từ; sáu từ ≈ 77,5 bit là khuyến nghị hiện đại. EFF phát hành danh sách từ tương thích diceware cập nhật vào tháng 7 năm 2016. Nhưng với trường hợp sử dụng cấp phép hàng loạt mà công cụ này phục vụ (token tạm thời được đổi khi đăng nhập lần đầu) ASCII ngẫu nhiên là công cụ phù hợp vì người dùng không bao giờ cần gõ nó.

    Loại trừ ký tự mơ hồ có phải đánh đổi bảo mật không?

    Đúng về mặt kỹ thuật, bỏ i, l, 1, L, O, 0, o thu hẹp bảng chữ cái từ 94 xuống 87, giảm entropy mỗi ký tự từ 6,55 bit xuống 6,44 bit. Ở 16 ký tự đó là 103,0 bit thay vì 104,8 bit, hoàn toàn không đáng kể. Sự đánh đổi đáng giá khi con người phải đọc to mật khẩu hoặc ghi chép nó từ tờ in, đây chính xác là tình huống phân phối hàng loạt mà công cụ này phục vụ.

    Cách phân phối danh sách đã tạo an toàn nhất là gì?

    Xem danh sách đã tạo như một hiện vật dùng một lần. Phân phối qua kênh được sắp xếp trước (email mã hóa với PGP/GPG, truyền tệp an toàn, nhập trình quản lý mật khẩu, sneakernet trực tiếp cho các bối cảnh rủi ro cao). Cấu hình hệ thống để yêu cầu đổi mật khẩu khi đăng nhập lần đầu. Xóa tệp sau khi phân phối. Không bao giờ gửi email danh sách văn bản thuần, không bao giờ commit chúng vào kiểm soát phiên bản, không bao giờ dán chúng vào chat. Mật khẩu được tạo có ý định là token dùng một lần, giá trị nằm ở tính ngẫu nhiên mật mã cho giao dịch ban đầu, không phải ở việc lưu giữ lâu dài.

    Công cụ liên quan

    Trình tạo mật khẩu

    Tạo một mật khẩu ngẫu nhiên mạnh.

    Trình mã hóa Base64

    Mã hóa và giải mã Base64 tức thì.

    Trình tạo chuỗi ngẫu nhiên

    Tạo chuỗi ngẫu nhiên với mẫu tùy chỉnh.