Once you invent a password, its fate depends not on you but on how the service is built. The same password can be safe on one site and sitting in plain text on another. It is worth understanding, if only because bad storage shows from the outside.
Un hash en lugar de la contraseña
A properly built service does not store your password. It stores a hash — the result of an irreversible transformation: getting a hash from a password is easy, getting the password back is not.
At login the service hashes what you typed and compares it with the stored value. A match lets you in. The password itself is not needed, and the service does not know it.
Hence the first practical conclusion. If a service can email you your own password — not a reset link but the password — it stores it in plain text or reversible encryption. That is a red flag: a breach leaks every password at once, ready to use.
Por eso las contraseñas usan funciones deliberadamente lentas: se ajustan para que una comprobación tarde una décima de segundo. El usuario no lo nota y el descifrado se ralentiza millones de veces.
Para qué sirve la sal
Hashing alone is not enough. Identical passwords produce identical hashes, so the database reveals who shares a password. Worse, ready-made tables exist where hashes for billions of popular passwords are precomputed.
A salt is a random string, unique per user, added to the password before hashing. It is stored next to the hash and is not a secret.
What it achieves: two identical passwords produce different hashes, precomputed tables become useless, and every password has to be attacked separately. Breaking a database of a million accounts now costs a million times more than breaking one.
Por qué una buena función es lenta
The counter-intuitive part. Ordinary hash functions such as SHA-256 were designed to be fast, which is needed for file checks and signatures. For passwords speed is harmful: a graphics card computes billions of SHA-256 per second, and guessing runs at the same rate.
So passwords use deliberately slow functions: bcrypt, scrypt, Argon2. They have a cost parameter that is raised as hardware improves. A single login costs the server a fraction of a second — unnoticeable to a human — while guessing slows down thousands of times.
Argon2 goes further and also demands a lot of memory. That hurts graphics cards: they have many cores but little memory per core, and their advantage disappears.
Qué se filtra en una brecha
Plain text. Every password leaks, ready to use. Yours is immediately tried on your email and your bank.
Fast hash, no salt. Practically the same: popular passwords are recovered instantly from tables.
Fast hash with salt. Noticeably better, but a graphics card tries billions per second. Weak passwords fall in hours.
Slow function with salt. Guessing becomes economically pointless for everything except the weakest passwords. Your sixteen-character random password will never be recovered.
Note that the last two rows depend on you. Good storage protects a strong password but does not save “Summer2026!”.
Cómo detectar un mal almacenamiento
It emails you the password at sign-up or recovery — plain text.
It caps the length at an odd number such as twelve. A hash is always the same length regardless of the password, so such a limit usually means the password goes into a fixed-size database column — that is, unhashed.
It forbids special characters. On its own not proof, but combined with the above it is a steady sign of old code.
It shows part of the password as a recovery hint — the server can read it.
The conclusion is simple: such services exist and you cannot fix them. What you can do is never reuse a password there and check your passwords against breach databases from time to time.