Generador de contraseñas en lote gratuito

Generación en lote de contraseñas

Esta herramienta genera varias contraseñas criptográficamente robustas en una sola operación. Perfecto para preparar listas para la incorporación de un equipo, la creación masiva de cuentas o la gestión de inventarios de contraseñas. Cada contraseña se produce mediante el generador aleatorio integrado del navegador.

Niveles de robustez

• Débil · 8-11 caracteres: protección básica, a evitar para cuentas sensibles
• Correcta · 12-15 caracteres: protección moderada, aceptable para muchos usos
• Buena · 16-19 caracteres: protección fuerte, recomendado para la mayoría de las cuentas
• Muy fuerte · 20 caracteres o más: protección máxima, ideal para sistemas críticos

Preguntas frecuentes

¿Estas contraseñas son realmente aleatorias?

Sí. Las contraseñas se generan con window.crypto.getRandomValues(), que proporciona valores aleatorios criptográficamente seguros, adecuados para usos de seguridad.

¿Puedo generar más de 100 contraseñas?

La herramienta limita la generación a 100 a la vez para evitar ralentizar el navegador. Genera varios lotes por separado si es necesario.

¿Cómo guardar el archivo descargado?

Conserva el archivo .txt en una ubicación segura, preferiblemente cifrada. Nunca lo confirmes a un repositorio de código ni lo compartas por canales no seguros. Elimínalo tras la distribución a los usuarios.

Where good random numbers come from

A computer is, by design, deterministic. Given the same inputs and the same code, it produces the same outputs every time. That's exactly the property you want from a CPU running a spreadsheet, and exactly the property you do not want from a password generator. If an attacker can reproduce the sequence of values the generator emitted, they can reproduce every password it ever issued.

So the generator collects "entropy" (unpredictable physical signal from outside the program) and uses it to seed an algorithm called a CSPRNG (Cryptographically Secure Pseudo-Random Number Generator). The "pseudo" is honest: bits are produced by an algorithm, not physics. The "cryptographically secure" means even an attacker who sees a long run of past outputs can't predict the next byte better than chance. Theodore Ts'o implemented /dev/random in the Linux kernel in 1994, and macOS, the BSDs, Solaris and Windows (with BCryptGenRandom) all adopted equivalent interfaces. Under the hood these mix every plausible source of physical jitter (disk-seek timing, network packet arrivals, keyboard and mouse input, hardware interrupts, RDRAND on Intel CPUs that have it) through a cryptographic hash, then continuously reseed.

In the browser, the W3C Web Cryptography API exposes this via window.crypto.getRandomValues(typedArray): hand it a typed array, the browser fills it with cryptographically strong random bytes. The maximum per call is 65,536 bytes (this tool stays well under). The API has been baseline-supported across Chrome, Firefox, Safari and Edge since July 2015: there's no realistic possibility of a user landing on this tool with a browser that lacks it.

Password entropy, the actual math

Password "strength," in the formal cryptographic sense, is measured in bits of entropy. The standard formula for a randomly generated password is:

Entropy = L × log₂(R)

where L is length in characters and R is the size of the character pool. Per-character entropy by charset:

• Digits only (0–9): 10 chars → 3.32 bits/char
• Lowercase only (a–z): 26 → 4.70 bits/char
• Lower + upper (A–Za–z): 52 → 5.70 bits/char
• Lower + upper + digits (alphanumeric): 62 → 5.95 bits/char
• All printable ASCII excluding space: 94 → 6.55 bits/char

The number 94 is worth pinning down: ASCII codes 32 through 126 are the printable characters (95 total); excluding the space leaves 94 visible non-space glyphs (26 lowercase + 26 uppercase + 10 digits + 32 punctuation/symbols). Plugging concrete numbers into the formula:

• 8 chars × 6.55 ≈ 52.4 bits: fast to brute-force on modern hardware
• 12 chars × 6.55 ≈ 78.6 bits: borderline, just under the 80-bit threshold
• 16 chars × 6.55 ≈ 104.8 bits: above 100, into ANSSI-acceptable territory
• 20 chars × 6.55 ≈ 131.0 bits: past the AES-128-equivalent threshold
• 32 chars × 6.55 ≈ 209.6 bits: overkill for any conceivable adversary

The cryptographic community has settled on three thresholds: 80 bits as the bare minimum (NIST's recommended floor until 2014), reached at ~13 characters with the full 94-char set; 100 bits required by ANSSI (the French equivalent of NSA) for passwords protecting encryption systems, reached at ~16 characters; and 128 bits matching the symmetric-key strength of AES-128, recommended for vault master passwords, reached at ~20 characters.

The huge caveat: this math only applies to random passwords. If a human picked the password, the effective entropy is much, much lower. The attacker isn't enumerating R^L strings alphabetically, they're running a guessing program seeded with leaked password lists, dictionary words, common substitutions (a→@, o→0, s→$), keyboard walks, and statistical models of how humans construct memorable strings. Joseph Bonneau's 2012 study of an anonymised corpus of 70 million Yahoo passwords (IEEE Symposium on Security and Privacy) found that user-chosen passwords give "fewer than 10 bits of security against an online trawling attack, and only about 20 bits against an optimal offline dictionary attack." Twenty bits is one million guesses. A modern GPU does that in microseconds.

NIST SP 800-63B, what changed in 2017 and again in 2025

For about thirty years, North American security policy on passwords descended from a 1985 NIST publication that recommended forced periodic rotation, mixed character classes and short minimum lengths. Bill Burr, author of the 2003 follow-up that codified the "uppercase + lowercase + digit + symbol, change every 90 days" rule, publicly recanted it in 2017, telling the Wall Street Journal that "much of what I did, I now regret." NIST formalised the reversal the same year.

NIST SP 800-63B Rev 3 (June 2017) made two generational changes. Section 5.1.1.2 reads: "Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically)", because forced rotations cause users to pick weaker, more predictable passwords. The same section: "Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types) for memorized secrets", because forcing a digit and a symbol pushes users toward Password1! rather than a longer passphrase. Rev 3 set the minimum subscriber-chosen length at 8 characters, required verifiers to accept up to 64, mandated checking new passwords against breach blocklists, and explicitly required password managers and clipboard pastes be permitted.

NIST SP 800-63B Rev 4 (finalised 31 July 2025) hardened the bar: single-factor passwords now require a 15-character minimum ("Verifiers and CSPs SHALL require passwords that are used as a single-factor authentication mechanism to be a minimum of 15 characters in length"). Multi-factor passwords stay at 8 characters because the second factor carries the security weight. Composition rules are still prohibited, and the wording shifted from Rev 3's "SHOULD NOT" to Rev 4's "SHALL NOT," making it a hard requirement rather than a recommendation. Rotation is still discouraged unless there's evidence of compromise.

The Absolutool tool defaults to 16 characters with all four character classes, giving roughly 104 bits of entropy and comfortably clearing both the 15-character Rev 4 minimum and the 80-bit symmetric-equivalence threshold. The tool's maximum of 128 characters sits at exactly twice the maximum length NIST mandates that verifiers must accept, there's no realistic case where a generated password would be too long for a server to accept.

RockYou, the disaster that still haunts 2026

In December 2009, the social games company RockYou was breached via textbook SQL injection. The breach exposed over 32 million user accounts including the passwords for those accounts in plaintext: RockYou had stored them unencrypted. The company's password policy at the time required only five characters and disallowed special characters, which had compounded the vulnerability.

The breached file, soon nicknamed rockyou.txt, was published openly and remains the single most-referenced password wordlist in the world. It ships by default with Kali Linux for penetration testers; every dictionary attack tool on the planet checks against it; commercial credential-stuffing services maintain it as a baseline. Sixteen years on, attackers still catch live accounts using passwords that first appeared in the 2009 leak. The lessons that propagated: servers should never see plaintext passwords (this tool generates client-side, so the server never sees them at all); stored passwords should be hashed with a slow, salted, memory-hard function like Argon2id or bcrypt, not a fast hash like MD5 or unsalted SHA-1; unique passwords per site are the only defence against the stolen-credentials replay attack that has dominated the past decade of breaches.

Have I Been Pwned and the breach corpus

Have I Been Pwned (HIBP), run by Microsoft Regional Director Troy Hunt, has become the standard authoritative source for "has this password appeared in a breach?" Hunt launched HIBP in 2013 as a searchable index of breached email addresses; he later added the Pwned Passwords corpus, a downloadable list of every password seen in a public breach, indexed by SHA-1 hash. Pwned Passwords V2 launched on 22 February 2018 and introduced the dataset's k-anonymity API (built with Cloudflare): a client sends only the first five characters of the SHA-1 hash; the server returns every full hash starting with those five characters along with the count of times observed; the client compares locally. The password (and even its full hash) never leaves the user's device.

For a bulk generator, the relevance is twofold. Any password already in HIBP is, by definition, not a useful new password, it'll be the first thing any credential-stuffing attacker tries. And because this tool generates with full CSPRNG randomness from a 94-character alphabet, the probability that a freshly generated 16-character password is already in HIBP is, for practical purposes, zero. (The total number of 16-character ASCII-symbol passwords is 94^16 ≈ 3.7 × 10³¹; HIBP contains roughly 10⁹ known passwords; collision probability ≈ 10⁻²².)

What "X bits of entropy" means in real time-to-crack

The number that gives concrete meaning to bits of entropy is "how long would a modern attacker need?", and the answer depends entirely on the hash algorithm. The community-published benchmark for hashcat v6.2.6 on a single Nvidia RTX 4090 records roughly 300 GH/s for NTLM hashes (Microsoft's old Windows hash) and 200 kH/s for bcrypt. The four-orders-of-magnitude gap between those two is the load-bearing fact: NTLM was designed for speed, bcrypt was designed to be slow.

The widely cited Hive Systems password tables turn the benchmarks into time-to-crack numbers. The 2025 version computed against MD5 hashes (nearly as fast as NTLM) gives ~59 minutes on one RTX 4090 to brute-force an 8-character password from the full charset. The same 8-character password against a bcrypt hash takes ~99 years on the same hardware. That four-orders-of-magnitude gap is the difference between "leaked yesterday, cracked by lunchtime" and "leaked yesterday, will outlive you."

The end user controls the password length and charset. They do not control the hash algorithm the server uses to store it. Most well-run modern services use bcrypt, scrypt or Argon2id, all deliberately slow. Older services and breached services frequently used MD5 or unsalted SHA-1, which is why old breach corpora can be cracked at the speeds quoted above. For a password generated by this tool: a 16-character random password is bcrypt-safe essentially forever and MD5-safe-ish for now; a 20-character password is overkill against either. There's no realistic threat model where 20+ characters of CSPRNG output is the weak link.

FIDO2, WebAuthn and the passkey transition

The longest-running prediction in the security industry is that passwords are going away. Since 2019 it's finally had a credible replacement: passkeys, the consumer-marketing name for credentials issued under the FIDO2 / WebAuthn standards. WebAuthn Level 1 became a W3C Recommendation on 4 March 2019; Level 2 followed on 8 April 2021. The cryptographic model is asymmetric: when a user registers, the authenticator generates a public/private keypair, sends the public key to the server, and stores the private key in secure local hardware. Authentication uses a challenge-response signed with the private key. The server never sees the secret, which means a server-side breach can't expose login credentials.

The major-platform rollouts moved in lockstep through 2022–2023: Apple demoed passkeys at WWDC on 6 June 2022 and shipped them publicly with iOS 16, iPadOS 16 and macOS Ventura in September 2022, sync via end-to-end encrypted iCloud Keychain. Google announced passkey support for Android and Chrome on 12 October 2022; stable Chrome support arrived in Chrome 108 in December 2022, syncing via Google Password Manager. Microsoft announced passkey management for Windows 11 on 21 September 2023, integrated with Windows Hello.

Passkeys solve the most painful classes of password failure (phishing, credential stuffing, server breach), but they haven't eliminated passwords because: many sites and most legacy systems still require one; passkeys are tied to a device or sync ecosystem (users without an Apple, Google or Microsoft account need an alternative); headless systems (IoT devices, server-side service accounts, batch-onboarding scenarios) can't rely on a biometric authenticator at the registration step; and many enterprise password policies, banking systems and government portals still mandate passwords. Bulk password generation is squarely in the second-and-third categories: a system administrator provisioning 50 new accounts can't ask each future user to enrol a passkey before the account exists.

Why client-side generation specifically matters

Imagine a competitor tool that POSTs the user's request to a server, the server runs the random generator, and returns the list as JSON. Even if everything works as advertised, the following parties can see the generated passwords in cleartext: the server's process memory while the request is being handled; the server's request logs (if logging is naive); any APM or error-tracking service the server is wired to; the TLS-terminating reverse proxy (Cloudflare, AWS load balancer, nginx); any debugging tool running on the server; any future attacker who gains access to any of those logs. The RockYou model, with all its consequences, applies.

When generation happens via window.crypto.getRandomValues() in the user's browser, none of that applies. The bytes are produced inside the browser process, on the user's machine, by code the user can audit (the page is viewable source). They never cross the network. Absolutool's server never sees them, never logs them, and can't leak them in a future breach because it never had them. The only entities that see the generated passwords are the user, anyone with access to the user's browser session (typically only the user), and any browser extensions running on the page. This is the same security model as a password manager's local generator, and stronger than the model of any web service that returns generated passwords from a server.

Mirai 2016, the negative example for IoT defaults

The textbook negative example for "let's just use the same default password on every unit" is the Mirai botnet. Mirai exploited a hardcoded list of about 62 manufacturer-default username/password combinations (admin/admin, root/root, root/xc3511, root/vizxv) to infect hundreds of thousands of IP cameras, DVRs and home routers in late 2016, then used them on 21 October 2016 to take down the major DNS provider Dyn, briefly knocking out Twitter, Reddit, Netflix and GitHub. A bulk password generator is exactly the right primitive for the alternative: produce a unique strong default per unit on the production line, print it on a sticker, ship it inside the box.

More questions

Why does NIST recommend length over complexity?

Because forcing complexity (a digit, a symbol, an uppercase letter) pushes users into predictable patterns the attacker has already modelled. Password1! mathematically has more entropy than password, but in practice every attacker's wordlist starts there. A 20-character all-lowercase string from a CSPRNG has ~94 bits of entropy and can't be guessed by any wordlist because it doesn't match a wordlist. NIST SP 800-63B Rev 4 (July 2025) makes prohibition of composition rules a hard SHALL NOT requirement.

Should I use passphrases instead?

For passwords you have to memorise, yes, that's what xkcd #936 (10 August 2011) was arguing. The Diceware method (Arnold Reinhold, 1995) gives 12.9 bits per word from a 7,776-word list; six words ≈ 77.5 bits is the modern recommendation. The EFF released updated diceware-compatible word lists in July 2016. But for the bulk-provisioning use case this tool serves (temporary tokens that get changed on first login) random ASCII is the right primitive because the user never needs to type it.

Is excluding ambiguous characters a security trade-off?

Yes, technically, dropping i, l, 1, L, O, 0, o shrinks the alphabet from 94 to 87, lowering per-character entropy from 6.55 bits to 6.44 bits. At 16 characters that's 103.0 bits instead of 104.8 bits, completely irrelevant. The trade-off pays off when humans have to read the password aloud or transcribe it from a printed sheet, which is the exact bulk-distribution scenario this tool serves.

What's the safest way to distribute a generated list?

Treat the generated list as a one-shot artifact. Distribute via a pre-arranged channel (encrypted email with PGP/GPG, secure file transfer, password manager import, in-person sneakernet for high-stakes contexts). Configure the systems to require a password change on first login. Delete the file after distribution. Never email plaintext lists, never commit them to version control, never paste them into chat. The generated passwords are intended as one-time tokens, the value is in the cryptographic randomness for the initial handover, not in long-term retention.

Herramientas relacionadas