Pigu_ing

Por qué tu contraseña "segura" no lo es (y cómo realmente te hackean en 2026)

Fri, 17 Apr 2026 00:00:00 GMT

Si estás leyendo esto, probablemente ya sabés lo básico: usar mayúsculas, números, símbolos…

Y aún así, hay una alta probabilidad de que tus contraseñas sean vulnerables.

No porque sean "malas". Sino porque los ataques cambiaron… y la forma de defenderse también.

🧠 El problema no es tu contraseña (es el modelo mental)

La mayoría imagina al atacante así:

alguien intentando adivinar tu contraseña manualmente.

Pero la realidad es otra.

Hoy, los ataques funcionan así:

Se filtra una base de datos (millones de usuarios)
Se automatizan intentos de login
Se prueban combinaciones a escala masiva

No sos un objetivo. Sos parte de un sistema.

🔓 Cómo se rompen contraseñas hoy (lo que nadie te explica)

1. Ataques de diccionario (no son lo que pensás)

No usan solo palabras comunes.

Usan listas como:

Password123
Admin2024
Bienvenido1

Y también combinaciones con:

símbolos
mayúsculas
números

👉 Es decir: "cumplir las reglas" ya no te salva.

2. Credential stuffing (el ataque más subestimado)

Este es el más importante.

Funciona así:

Un sitio es hackeado
Se filtran emails + contraseñas
Esas credenciales se prueban automáticamente en otros servicios

Resultado: 👉 si reutilizás contraseñas, un solo leak compromete todo

3. Fuerza bruta moderna

No es alguien probando combinaciones lentas.

Son sistemas capaces de:

probar millones de combinaciones por segundo
usar GPUs
optimizar intentos según patrones humanos

👉 Las contraseñas cortas no tienen chance.

⚠️ El gran mito: "uso una contraseña compleja, estoy seguro"

Ejemplo:

P4ssw0rd!2024

Parece segura.

Pero:

sigue un patrón conocido
está en bases de datos reales
es fácilmente predecible

👉 Complejidad ≠ seguridad

🧩 La clave real: ENTROPÍA

Este es el concepto que casi nadie explica.

La seguridad de una contraseña no depende solo de los caracteres… sino de cuántas combinaciones posibles existen.

Más:

longitud
aleatoriedad

= más entropía = más seguridad

🔐 Entonces… ¿qué funciona realmente?

✔ Passphrases (pero bien usadas)

Ejemplo:

Perro!Azul_Come#Sandía99

Esto funciona porque:

es larga
mezcla caracteres
no sigue patrones comunes

Pero ojo:

"IloveYou123!" ❌ Sigue siendo predecible.

✔ Contraseñas únicas SIEMPRE

Esto es más importante que cualquier otra regla.

Porque evita: 👉 el efecto dominó de los leaks

✔ Gestores de contraseñas (la solución real)

Herramientas como Bitwarden, 1Password o KeePass cambian completamente el juego:

generan contraseñas realmente aleatorias
eliminan la reutilización
reducen el error humano

👉 Pasás de "recordar contraseñas" a "gestionar acceso"

✔ 2FA (tu red de seguridad)

Incluso si todo falla:

phishing
filtraciones
errores humanos

El doble factor puede detener el acceso.

🧠 Pensá como atacante (y ganás)

Un atacante no piensa:

"¿cómo entro a esta persona?"

Piensa:

"¿qué error masivo puedo explotar?"

Por eso:

reutilización = oro
patrones = ventaja
contraseñas cortas = trivial

⚡ Experimento mental (probá esto)

Respondé honestamente:

¿Tu contraseña más importante…

la usás en más de un sitio?
tiene menos de 12 caracteres?
sigue un patrón lógico?

Si respondiste "sí" a alguna: 👉 ya sos vulnerable a ataques automatizados

🧠 Conclusión

La seguridad no se trata de hacer una contraseña "más complicada".

Se trata de:

eliminar patrones
evitar reutilización
aumentar entropía
reducir el error humano

🚀 Si aplicás solo esto:

Usá contraseñas largas (16+)
No las reutilices
Usá un gestor
Activá 2FA

Ya estás en el top de usuarios en seguridad.

La mayoría de los ataques no requieren habilidad avanzada.

Solo requieren que alguien cometa los errores de siempre.

La diferencia está en entenderlos… y no repetirlos.

</div>

If you're reading this, you probably already know the basics: uppercase letters, numbers, symbols…

And yet, there's a high chance your passwords are still vulnerable.

Not because they're "bad". But because attacks changed… and so did the way to defend against them.

🧠 The problem isn't your password (it's the mental model)

Most people picture the attacker like this:

someone trying to guess your password manually.

But the reality is different.

Today, attacks work like this:

A database gets leaked (millions of users)
Login attempts are automated
Combinations are tested at massive scale

You're not a target. You're part of a system.

🔓 How passwords are cracked today (what nobody explains)

1. Dictionary attacks (not what you think)

They don't just use common words.

They use lists like:

Password123
Admin2024
Welcome1

And also combinations with:

symbols
uppercase letters
numbers

👉 In other words: "following the rules" no longer saves you.

2. Credential stuffing (the most underrated attack)

This is the most important one.

It works like this:

A site gets hacked
Emails + passwords are leaked
Those credentials are automatically tested on other services

Result: 👉 if you reuse passwords, a single leak compromises everything

3. Modern brute force

It's not someone slowly trying combinations.

These are systems capable of:

testing millions of combinations per second
using GPUs
optimizing attempts based on human patterns

👉 Short passwords have no chance.

⚠️ The big myth: "I use a complex password, I'm safe"

Example:

P4ssw0rd!2024

Looks secure.

But:

it follows a known pattern
it's in real databases
it's easily predictable

👉 Complexity ≠ security

🧩 The real key: ENTROPY

This is the concept almost nobody explains.

A password's security doesn't depend only on its characters… but on how many possible combinations exist.

length
randomness

= more entropy = more security

🔐 So… what actually works?

✔ Passphrases (but used correctly)

Example:

Blue!Dog_Eats#Watermelon99

This works because:

it's long
it mixes characters
it doesn't follow common patterns

But watch out:

"IloveYou123!" ❌ Still predictable.

✔ Unique passwords ALWAYS

This is more important than any other rule.

Because it prevents: 👉 the domino effect of leaks

✔ Password managers (the real solution)

Tools like Bitwarden, 1Password or KeePass completely change the game:

they generate truly random passwords
they eliminate reuse
they reduce human error

👉 You go from "remembering passwords" to "managing access"

✔ 2FA (your safety net)

Even if everything else fails:

phishing
leaks
human errors

The second factor can stop unauthorized access.

🧠 Think like an attacker (and win)

An attacker doesn't think:

"how do I get into this person's account?"

They think:

"what massive mistake can I exploit?"

That's why:

reuse = gold
patterns = advantage
short passwords = trivial

⚡ Mental experiment (try this)

Answer honestly:

Your most important password…

do you use it on more than one site?
does it have fewer than 12 characters?
does it follow a logical pattern?

If you answered "yes" to any of those: 👉 you're already vulnerable to automated attacks

🧠 Conclusion

Security isn't about making a password "more complicated".

It's about:

eliminating patterns
avoiding reuse
increasing entropy
reducing human error

🚀 If you do just this:

Use long passwords (16+)
Don't reuse them
Use a password manager
Enable 2FA

You're already in the top tier of security-conscious users.

Most attacks don't require advanced skills.

They only require someone to make the same old mistakes.

The difference is in understanding them… and not repeating them.

</div>

Ciphie: por qué construí mi propio gestor de secretos

Wed, 01 Apr 2026 00:00:00 GMT

Hay un archivo que muchos developers tienen y nadie admite. Se llama keys.txt, o env_backup.txt, o simplemente temp — y adentro hay API keys, tokens, contraseñas de bases de datos. Sin cifrar. Sin contraseña. Ahí nomás, en el escritorio.

Yo lo tuve durante dos años.

No por ignorancia. Sabía que era mala práctica. Pero los gestores de contraseñas comerciales no están pensados para developers: mezclan credenciales web con tokens de producción, no tienen campos para variables de entorno, y tarde o temprano terminan mandando tus datos a una nube que no controlás.

Así que un día borré el archivo y empecé a construir algo propio.

Qué es Ciphie

Ciphie es un gestor de secretos que corre completamente en tu máquina. Sin servidor, sin cuenta, sin suscripción. Lo abrís, guardás tus API keys, tokens y contraseñas, y eso es todo. Por defecto, nada sale de tu computadora — las únicas conexiones de red opcionales son el email de verificación de cuenta y el 2FA por SMS, ambas desactivadas si no las configurás en el .env.

Tiene interfaz de escritorio con tema oscuro, soporte para varios tipos de secretos con campos específicos por categoría, y segundo factor de autenticación con cuatro métodos distintos para elegir al momento del login.

Todavía no está publicado — estoy terminando algunos detalles antes de soltar la primera versión. Pero quería contar la historia antes de eso.

El problema con las alternativas

Antes de construir algo, siempre conviene ver qué existe. En mi caso, las opciones eran:

Gestores comerciales (1Password, Bitwarden, Dashlane): buenos productos, pero orientados a contraseñas web. Para un developer que maneja decenas de API keys con campos como endpoint, región, scope o environment, la experiencia es torpe. Y dependen de la nube.

Soluciones de infraestructura (HashiCorp Vault, AWS Secrets Manager): excelentes para equipos y producción, completamente sobredimensionados para un developer individual que quiere guardar sus keys de forma segura durante el desarrollo.

Variables de entorno del sistema: válido, pero sin interfaz, sin organización y sin cifrado en reposo.

Lo que quería era simple: una app de escritorio, local, cifrada, pensada para developers. No encontré exactamente eso, así que lo construí.

Las decisiones que importan

Construir algo de seguridad obliga a tomar decisiones que en otros proyectos son opcionales. Acá están las que más me marcaron.

Una dependencia obligatoria, el resto opcional

La primera decisión fue de filosofía: mantener el stack al mínimo absoluto. Ciphie tiene una sola dependencia obligatoria — cryptography, el paquete de la Python Cryptographic Authority. Todo lo demás que podría necesitar (QR codes para TOTP, SMS vía Twilio, Touch ID en macOS) son extras opcionales que se instalan solo si los querés usar:

pip install ciphie        # solo lo esencial
pip install ciphie[qr]    # agrega QR codes para el 2FA con app
pip install ciphie[sms]   # agrega 2FA por SMS vía Twilio
pip install ciphie[all]   # todo junto

La interfaz, la base de datos y el hashing de contraseñas usan módulos que vienen con Python: tkinter, sqlite3, hashlib. Cada dependencia adicional es una superficie de ataque. En un proyecto de seguridad, eso pesa más que la comodidad de una librería extra.

Cifrado real, no teatro de seguridad

Cada secreto se cifra con AES-256-GCM antes de guardarse. No es solo una decisión de algoritmo — es un modo que importa.

GCM (Galois/Counter Mode) hace dos cosas: cifra el dato y lo autentica. Si alguien modifica el archivo de la base de datos directamente, el descifrado no devuelve basura silenciosamente: falla con un error explícito. Eso es la diferencia entre un sistema que detecta manipulación y uno que no.

def cifrar(valor: str) -> str:
    clave = _get_clave_aes()
    nonce = os.urandom(12)  # 96 bits — tamaño recomendado para GCM
    aesgcm = AESGCM(clave)
    cifrado = aesgcm.encrypt(nonce, valor.encode("utf-8"), None)
    return base64.urlsafe_b64encode(nonce + cifrado).decode("utf-8")

Lo otro que importa es el nonce: 12 bytes generados aleatoriamente para cada cifrado individual. Sin eso, dos secretos con el mismo contenido producen el mismo resultado cifrado — y eso rompe la seguridad del esquema completo. Con el nonce aleatorio, cada cifrado es único aunque el contenido sea idéntico.

Las contraseñas no se guardan

Las contraseñas de los usuarios se hashean con PBKDF2-HMAC-SHA256 con 310.000 iteraciones — la recomendación de OWASP para 2023. Cada iteración extra multiplica el tiempo que le lleva a un atacante probar contraseñas en un ataque offline. Con esta configuración, una GPU moderna tardaría meses en fuerza bruta, no segundos.

_ITERATIONS = 310_000

def _hash_password(password: str) -> str:
    salt = os.urandom(16)
    clave = hashlib.pbkdf2_hmac(
        "sha256", password.encode("utf-8"), salt, _ITERATIONS, dklen=64
    )
    return salt.hex() + ":" + clave.hex()

Un detalle que casi ignoro: la comparación del hash usa hmac.compare_digest en lugar del operador == de Python. La diferencia es que == puede terminar antes si los primeros bytes no coinciden, lo que permite medir tiempos y deducir información sobre el hash real. compare_digest siempre tarda exactamente lo mismo, sin importar el resultado.

# ❌ vulnerable a timing attacks
if hash_calculado == hash_guardado:

# ✅ tiempo constante, sin importar cuántos bytes coincidan
if hmac.compare_digest(hash_calculado, hash_guardado):

SQLite es suficiente

No necesité un servidor de base de datos. SQLite corre en proceso, el archivo vive localmente con permisos restringidos — solo el usuario dueño puede leerlo —, y es más que suficiente para este caso de uso. A veces la solución correcta es la más simple.

Lo que sorprende cuando construís algo de seguridad

Hay una diferencia enorme entre saber que algo existe y tener que implementarlo correctamente.

Los timing attacks son un buen ejemplo. Sabía que existían. Pero fue distinto tener que pensar: "si uso == acá, ¿estoy filtrando información?" y tener que buscar la alternativa correcta. La seguridad está llena de esos momentos: detalles pequeños con consecuencias grandes.

Lo mismo con los nonces. O con la diferencia entre cifrado autenticado y no autenticado. O con la cantidad de iteraciones del hash. Ninguno de esos detalles aparece en un tutorial introductorio, pero todos importan en producción.

Construir Ciphie fue, entre otras cosas, un ejercicio de ir más allá de la superficie de cada concepto.

Lo que viene

Antes de publicar la primera versión, estoy terminando algunos ajustes. Cuando esté lista, va a estar disponible en GitHub bajo licencia MIT. Una sola línea para instalar, otra para abrirlo.

Si manejás secretos como developer y te interesa probarlo cuando esté disponible, seguime acá — voy a publicar el lanzamiento en cuanto esté listo.

Y si tenés un keys.txt en el escritorio, borralo ya. No esperés a que salga Ciphie.

Ciphie está construido con Python 3.11+, SQLite, Tkinter y la librería cryptography. El código va a estar disponible en GitHub bajo licencia MIT.

</div>

There's a file many developers have and nobody admits to. It's called keys.txt, or env_backup.txt, or just temp — and inside there are API keys, tokens, database passwords. Unencrypted. No password. Just sitting there on the desktop.

I had one for two years.

Not out of ignorance. I knew it was bad practice. But commercial password managers aren't built for developers: they mix web credentials with production tokens, have no fields for environment variables, and sooner or later end up sending your data to a cloud you don't control.

So one day I deleted the file and started building something of my own.

What is Ciphie

Ciphie is a secrets manager that runs entirely on your machine. No server, no account, no subscription. You open it, save your API keys, tokens and passwords, and that's it. By default, nothing leaves your computer — the only optional network connections are account verification email and 2FA via SMS, both disabled unless you configure them in the .env.

It has a desktop UI with dark theme, support for multiple secret types with category-specific fields, and two-factor authentication with four different methods to choose from at login.

It's not published yet — I'm finishing some details before releasing the first version. But I wanted to tell the story before that.

The problem with alternatives

Before building something, it's always worth seeing what exists. In my case, the options were:

Commercial managers (1Password, Bitwarden, Dashlane): good products, but oriented toward web passwords. For a developer managing dozens of API keys with fields like endpoint, region, scope or environment, the experience is clunky. And they depend on the cloud.

Infrastructure solutions (HashiCorp Vault, AWS Secrets Manager): excellent for teams and production, completely oversized for an individual developer who wants to store their keys securely during development.

System environment variables: valid, but no UI, no organization and no encryption at rest.

What I wanted was simple: a desktop app, local, encrypted, built for developers. I didn't find exactly that, so I built it.

The decisions that matter

Building something security-related forces you to make decisions that are optional in other projects. Here are the ones that impacted me the most.

One mandatory dependency, the rest optional

The first decision was philosophical: keep the stack to the absolute minimum. Ciphie has one mandatory dependency — cryptography, the Python Cryptographic Authority package. Everything else it might need (QR codes for TOTP, SMS via Twilio, Touch ID on macOS) are optional extras installed only if you want them:

pip install ciphie        # just the essentials
pip install ciphie[qr]    # adds QR codes for app-based 2FA
pip install ciphie[sms]   # adds 2FA via SMS through Twilio
pip install ciphie[all]   # everything together

The UI, database and password hashing use modules that ship with Python: tkinter, sqlite3, hashlib. Every additional dependency is an attack surface. In a security project, that weighs more than the convenience of an extra library.

Real encryption, not security theater

Each secret is encrypted with AES-256-GCM before being stored. It's not just an algorithm choice — it's a mode that matters.

GCM (Galois/Counter Mode) does two things: it encrypts the data and authenticates it. If someone modifies the database file directly, decryption doesn't silently return garbage: it fails with an explicit error. That's the difference between a system that detects tampering and one that doesn't.

def encrypt(value: str) -> str:
    key = _get_aes_key()
    nonce = os.urandom(12)  # 96 bits — recommended size for GCM
    aesgcm = AESGCM(key)
    encrypted = aesgcm.encrypt(nonce, value.encode("utf-8"), None)
    return base64.urlsafe_b64encode(nonce + encrypted).decode("utf-8")

The other thing that matters is the nonce: 12 randomly generated bytes for each individual encryption. Without it, two secrets with the same content produce the same encrypted result — and that breaks the security of the entire scheme. With the random nonce, each encryption is unique even if the content is identical.

Passwords are never stored

User passwords are hashed with PBKDF2-HMAC-SHA256 with 310,000 iterations — OWASP's recommendation for 2023. Each extra iteration multiplies the time it takes an attacker to try passwords in an offline attack. With this configuration, a modern GPU would take months to brute-force, not seconds.

_ITERATIONS = 310_000

def _hash_password(password: str) -> str:
    salt = os.urandom(16)
    key = hashlib.pbkdf2_hmac(
        "sha256", password.encode("utf-8"), salt, _ITERATIONS, dklen=64
    )
    return salt.hex() + ":" + key.hex()

A detail I almost overlooked: hash comparison uses hmac.compare_digest instead of Python's == operator. The difference is that == can terminate early if the first bytes don't match, which allows timing measurement and leaking information about the real hash. compare_digest always takes exactly the same time, regardless of the result.

# ❌ vulnerable to timing attacks
if calculated_hash == stored_hash:

# ✅ constant time, regardless of how many bytes match
if hmac.compare_digest(calculated_hash, stored_hash):

SQLite is enough

I didn't need a database server. SQLite runs in-process, the file lives locally with restricted permissions — only the owner can read it —, and it's more than enough for this use case. Sometimes the right solution is the simplest one.

What surprises you when building something security-related

There's a huge difference between knowing something exists and having to implement it correctly.

Timing attacks are a good example. I knew they existed. But it was different to have to think: "if I use == here, am I leaking information?" and have to find the correct alternative. Security is full of those moments: small details with large consequences.

Same with nonces. Or with the difference between authenticated and unauthenticated encryption. Or with the number of hash iterations. None of those details appear in an introductory tutorial, but all of them matter in production.

Building Ciphie was, among other things, an exercise in going beyond the surface of each concept.

What's next

Before publishing the first version, I'm finishing some adjustments. When it's ready, it will be available on GitHub under MIT license. One line to install, another to open it.

If you manage secrets as a developer and are interested in trying it when it's available, follow me here — I'll publish the launch as soon as it's ready.

And if you have a keys.txt on your desktop, delete it now. Don't wait for Ciphie.

Ciphie is built with Python 3.11+, SQLite, Tkinter and the cryptography library. The code will be available on GitHub under MIT license.

</div>

Le pedí a Claude que escribiera mi endpoint de login. Estaba roto de cuatro maneras distintas.

Wed, 18 Mar 2026 00:00:00 GMT

Le pedí a Claude que escribiera mi endpoint de login. Estaba roto de cuatro maneras distintas.

No era obvio. El código se veía limpio, estaba bien formateado, tenía comentarios útiles. Pero tenía SQL injection, JWT sin verificar, y las contraseñas hasheadas con MD5. Construí Parley para que eso no le pase a nadie más.

Fue en un proyecto de lado, un sábado a la tarde. Necesitaba un endpoint de autenticación rápido en Python. Le pasé el contexto a Claude, me devolvió 80 líneas prolijas, lo copié, lo pegué, funcionó en el primer intento.

Tres días después, mirando el código más despacio antes de hacer el deploy, noté algo raro en la query. El modelo había armado el SQL concatenando strings. Directamente. Sin prepared statements. El tipo de error que cualquier tutorial de seguridad web menciona en el primer capítulo.

Lo peor no fue encontrar eso. Lo peor fue que, si no lo buscaba activamente, nunca lo hubiera visto. El código era prolijo, estaba bien indentado, tenía nombres de variables descriptivos. Transmitía confianza. Y esa confianza era el problema real.

El problema no es que la IA sea mala generando código. El problema es que fue entrenada con millones de líneas de código histórico — y ese código histórico está lleno de vulnerabilidades que en su momento nadie cuestionó. El modelo aprendió los patrones incorrectos con la misma confianza con la que aprendió los correctos. No distingue entre código seguro y código que simplemente funciona.

Busqué herramientas para auditarlo sistemáticamente. Snyk requería cuenta en la nube y estaba pensado para integrar en pipelines de CI de equipos medianos. Semgrep era potente pero genérico, con una curva de configuración que no tenía sentido para un proyecto chico. Ninguna herramienta estaba especializada en los patrones específicos que producen los LLMs — porque hasta hace poco ese no era un problema que existiera a esta escala.

Así nació Parley.

Qué es

Parley es un CLI que actúa como tu equipo de seguridad personal para código generado con IA. La idea es simple: generás código con Claude, ChatGPT o Copilot, lo pegás en tu proyecto, y antes de hacer commit corrés Parley. Él te dice si hay problemas de seguridad, sin mandar nada a internet, sin cuentas, sin configuración previa.

$ parley scan auth.py

[CRITICAL] SQL injection — línea 34
[HIGH]     JWT sin verificar — línea 67
[HIGH]     Hash inseguro (MD5) — línea 89
[INFO]     Error expuesto al cliente — línea 102

4 findings en 1 archivo (2 críticos, 2 altos, 0 medios)

Treinta segundos. Sin fricción. Sin tener que recordar un checklist mental cada vez que copiás código de un chat.

Cómo funciona por dentro

Tiene dos capas que se activan en orden:

Capa 1 — Análisis estático (siempre activa, instantánea)

24 reglas en YAML comparan el código contra patrones conocidos de vulnerabilidades. Es como un corrector ortográfico pero para seguridad. No necesita internet ni modelos de IA para funcionar — corre en milisegundos.

Capa 2 — Análisis con LLM local (opcional, --llm)

Usa un modelo corriendo en tu propia máquina via Ollama para entender el contexto de cada finding y explicarte exactamente por qué es peligroso y cómo arreglarlo. Esta capa agrega el "por qué" que el análisis estático no puede dar.

La decisión de usar un modelo local para la capa 2 fue deliberada. Si el código que estás auditando es código propietario o de autenticación, mandarlo a un servidor externo para analizarlo introduce exactamente el tipo de riesgo que querés evitar. Con Ollama todo queda en tu máquina.

Las 24 reglas, agrupadas en 8 categorías

Definimos las reglas cubriendo los patrones más frecuentes que aparecen en código AI-generado, no vulnerabilidades en abstracto:

Categoría	Reglas
Inyección	3
Validación de entrada	3
Secretos hardcodeados	3
Memoria y buffers	3
Deserialización	3
Manejo de errores	3
Autenticación	3
Config insegura	3

Cada regla es un archivo YAML simple y legible. No hace falta entender el motor en Go para contribuir una nueva — alcanza con conocer el patrón de vulnerabilidad que querés cubrir.

Así se ven los findings en detalle

Una decisión de diseño importante: Parley es conservador con los falsos positivos. Preferimos avisarte de menos cosas con alta confianza que llenarte de alertas que no son reales. Si hay duda, el finding se marca como INFO en lugar de HIGH. La idea es que cuando Parley dice CRITICAL, vos lo tratés como crítico de verdad.

CRITICAL SQL injection por concatenación de strings

auth.py:34 — La query arma el WHERE pegando directamente el valor del parámetro username. Un atacante puede cerrar la query e inyectar cualquier SQL arbitrario, incluyendo lecturas de otras tablas o eliminación de datos. Usá prepared statements: cursor.execute("SELECT * FROM users WHERE username = %s", (username,))

HIGH JWT aceptado sin verificar la firma

auth.py:67 — El token se decodifica con verify=False. Esto significa que cualquier persona puede construir un token con el payload que quiera — por ejemplo, con role: admin — y el sistema lo va a aceptar. Siempre verificá la firma con tu clave secreta antes de confiar en el contenido del token.

HIGH Contraseña hasheada con MD5

auth.py:89 — MD5 fue roto hace décadas y existen tablas rainbow que permiten revertir hashes comunes en segundos. Para passwords usá bcrypt, argon2 o scrypt, que están diseñados específicamente para ser lentos y resistentes a fuerza bruta.

INFO Stack trace expuesto al cliente

auth.py:102 — El bloque except devuelve str(e) directamente en la respuesta HTTP. Dependiendo del error, eso puede filtrar rutas internas del servidor, nombres de tablas de la base de datos o strings de conexión. Loggeá el detalle internamente y devolvé un mensaje genérico al cliente.

Por qué open source y sin telemetría

El código que Parley escanea puede ser código propietario, puede tener lógica de negocio sensible, puede ser exactamente el código de autenticación que no querés que salga de tu entorno. La decisión de no mandar nada a ningún servidor externo no es un feature — es el punto de partida.

El motor está escrito en Go porque compila en un solo binario ejecutable sin dependencias. Instalación en segundos, funciona igual en Mac, Linux y Windows. Las reglas están en YAML para que sean legibles y fáciles de contribuir. Python aparece únicamente en el módulo de integración con Ollama, porque es el entorno más natural para ese tipo de integración.

El código es público en GitHub bajo licencia MIT. Sin telemetría, sin analytics, sin ningún tipo de comunicación con servidores externos.

Qué sigue y cómo podés ayudar

Parley está en etapa de prueba de concepto. Las 24 reglas cubren los patrones más comunes que encontramos en código AI-generado, pero el espacio es mucho más amplio. Cada lenguaje tiene sus propios antipatrones. Cada framework tiene sus propias trampas. Y los modelos evolucionan — los patrones que generan hoy no son exactamente los mismos que generaban hace un año.

Hay tres formas concretas de contribuir:

Nuevas reglas YAML — si encontrás un patrón de vulnerabilidad que Parley no detecta, podés abrir un issue describiendo el patrón o mandar directamente una PR con la regla. No hace falta tocar Go.

Testing en proyectos reales — si tenés proyectos con código AI-generado, corré Parley y contanos qué encontró, qué se perdió y qué generó falsos positivos. Ese feedback es lo más valioso que podemos recibir ahora mismo.

Soporte para más lenguajes — las reglas actuales cubren Python y Go principalmente. Hay mucho trabajo por hacer en JavaScript, TypeScript, Java y Rust.

Si usás IA para escribir código — y en 2025 casi todos lo hacemos — Parley es esa segunda mirada que deberías darle antes de hacer deploy. No reemplaza una auditoría de seguridad seria. Pero sí reemplaza el "seguro que está bien, lo generó la IA". Y eso, resulta, es bastante.

</div>

Ethical Hacking y Ciberseguridad: entendiendo cómo se protege el mundo digital hoy

Mon, 02 Mar 2026 00:00:00 GMT

Cuando se habla de ciberseguridad, muchas veces se la presenta como algo técnico, lejano o incluso complicado. Firewalls, cifrado, ataques, sistemas… todo suena bastante abstracto.

Pero si lo bajamos a algo simple, la idea central es esta:

todo sistema digital puede fallar, y alguien puede intentar aprovecharlo

Y a partir de eso aparece una necesidad bastante lógica: no solo proteger, sino también anticiparse.

Este enfoque es justamente el que explora el paper "Ethical Hacking and Cybersecurity: Evaluating Best Practices, Challenges and Synergies", analizando cómo la seguridad moderna ya no puede ser solo defensiva, sino que necesita incorporar prácticas activas como el ethical hacking.

🔐 La ciberseguridad ya no alcanza por sí sola

Tradicionalmente, la ciberseguridad se enfocó en construir barreras:

sistemas de autenticación
firewalls
monitoreo de actividad
cifrado de datos

Todo esto sigue siendo fundamental. Pero el problema es que estos mecanismos parten de una lógica bastante clara: reaccionar o prevenir dentro de ciertos límites conocidos.

El contexto actual rompe un poco esa lógica.

Hoy los sistemas:

están más conectados que nunca
dependen unos de otros
manejan grandes volúmenes de datos
evolucionan constantemente

Y eso genera algo inevitable: más puntos de entrada posibles.

El paper destaca que, en este escenario, los atacantes no solo buscan vulnerabilidades, sino que desarrollan estrategias cada vez más sofisticadas para encontrarlas.

Por eso, quedarse únicamente en una postura defensiva deja un espacio peligroso: el de las fallas que todavía no fueron descubiertas.

🧑‍💻 Ethical Hacking: de reaccionar a anticiparse

Acá es donde entra el ethical hacking, que cambia la lógica de seguridad.

En lugar de esperar a que ocurra un ataque, propone algo distinto:

simular esos ataques de forma controlada para descubrir vulnerabilidades antes

Es importante entender que no se trata de un enfoque improvisado ni caótico. El ethical hacking sigue metodologías bastante estructuradas que permiten evaluar un sistema de forma ordenada y segura.

Estas metodologías incluyen desde la recolección de información inicial hasta la explotación controlada de vulnerabilidades y, finalmente, la elaboración de informes detallados.

Este último punto es clave: el objetivo no es "romper" el sistema, sino entender cómo mejorarlo.

🤝 La relación entre ambos enfoques

Uno de los aportes más interesantes del paper es mostrar que la ciberseguridad y el ethical hacking no son enfoques opuestos, sino complementarios.

Podríamos pensarlo así:

la ciberseguridad construye y protege
el ethical hacking prueba y desafía

Cuando ambos trabajan juntos, el resultado es un sistema más robusto.

El paper señala que muchas organizaciones ya están integrando estas prácticas dentro de sus estrategias de seguridad, especialmente en áreas como:

gestión de incidentes
evaluación de riesgos
planificación de contingencias

Este cambio refleja una transición importante: pasar de una seguridad reactiva a una seguridad proactiva.

⚖️ Los desafíos: no todo es técnico

Aunque gran parte del tema parece técnico, el paper hace bastante énfasis en algo que a veces se pasa por alto: los aspectos éticos y legales.

El ethical hacking solo es válido cuando:

existe autorización explícita
hay un alcance definido
se respetan límites claros

Esto es fundamental porque, en muchos casos, las pruebas implican acceder a sistemas sensibles o información crítica.

Además, también existen riesgos operativos. Una prueba mal ejecutada puede generar interrupciones o incluso daños en el sistema.

Por eso, el paper insiste en la necesidad de combinar habilidades técnicas con criterio profesional y responsabilidad.

🧠 Capacitación y profesionalización

Otro punto relevante es el crecimiento del campo profesional.

A medida que aumenta la complejidad de los sistemas, también lo hace la demanda de personas capacitadas en estas áreas. El paper menciona la importancia de la formación continua y certificaciones específicas, que ayudan a estandarizar conocimientos y prácticas.

Pero más allá de las certificaciones, hay una idea que atraviesa todo:

la ciberseguridad es un campo en constante cambio

Esto implica que el aprendizaje no es algo puntual, sino continuo.

🚀 Nuevas tecnologías, nuevos desafíos

El paper también aborda cómo ciertas tecnologías emergentes están redefiniendo el panorama de la seguridad.

Entre ellas se destacan:

el uso de inteligencia artificial para detectar amenazas
la expansión de dispositivos IoT (Internet of Things)
la migración hacia servicios en la nube
la automatización de procesos de ataque y defensa

Estas tecnologías no solo mejoran la seguridad, sino que también abren nuevas superficies de ataque, lo que vuelve aún más importante el enfoque proactivo.

🧠 Una forma distinta de pensar la seguridad

Más allá de lo técnico, lo que deja este análisis es un cambio de perspectiva.

La seguridad ya no puede pensarse como algo estático o definitivo. No existe un sistema completamente seguro, sino sistemas que se adaptan, se prueban y se mejoran constantemente.

El ethical hacking, en este sentido, no es solo una herramienta, sino una forma de pensar:

cuestionar lo que parece seguro
asumir que puede haber fallas
buscar esas fallas activamente
aprender de ellas

💬 Conclusión

El paper muestra con bastante claridad que la ciberseguridad moderna necesita evolucionar junto con las amenazas que enfrenta.

Integrar el ethical hacking dentro de las estrategias de seguridad permite a las organizaciones anticiparse, detectar vulnerabilidades y fortalecer sus sistemas de forma continua.

Pero también deja una enseñanza más general:

la seguridad no se trata de evitar todos los errores, sino de detectarlos y corregirlos a tiempo

En un entorno digital que cambia constantemente, esa capacidad de adaptación es, probablemente, la herramienta más importante de todas.

Link al paper

</div>

Antes de escribir código, dibujé Ciphie en papel

Fri, 13 Feb 2026 00:00:00 GMT

Hay una tentación enorme cuando tenés una idea: abrir el editor y empezar a escribir código. La adrenalina de ver algo funcionar rápido es difícil de resistir.

Con Ciphie no lo hice.

No porque tenga una disciplina especial. Sino porque me di cuenta de que no sabía exactamente qué quería construir. Tenía una dirección — un gestor de secretos local, cifrado, sin dependencias de la nube — pero no tenía claridad sobre cómo las piezas encajaban entre sí. Y en un proyecto de seguridad, empezar a codear sin esa claridad es una forma segura de construir algo con agujeros que no vas a ver hasta que sea tarde.

Así que antes de escribir una sola línea, me senté con papel y dibujé el sistema.

La pregunta que ordenó todo

El primer ejercicio fue simple: escribir en una sola oración qué hacía Ciphie.

"Un gestor de secretos que cifra cada entrada individualmente, corre sin servidor central y requiere autenticación para acceder."

Esa frase parece obvia. Pero escribirla me obligó a tomar tres decisiones que no había tomado todavía: cifrado por entrada (no del archivo completo), sin servidor central (toda la lógica y los datos viven en la máquina del usuario), y autenticación (usuarios, contraseñas, sesiones). Ciphie sí puede hacer llamadas de red para features opcionales — verificación de cuenta por email, SMS via Twilio, TOTP — pero ninguna de esas integraciones es requerida para que el núcleo funcione.

Cada una de esas palabras abría preguntas nuevas. ¿Cómo se deriva la clave de cifrado? ¿Dónde vive la base de datos? ¿Qué pasa si alguien falla el login cinco veces seguidas?

Antes de tocar el teclado, tenía una página llena de preguntas.

Dibujar el flujo, no el código

Lo primero que dibujé no fue una arquitectura técnica. Fue el recorrido de un usuario hipotético a través de la aplicación.

Alguien abre Ciphie. Ingresa su contraseña. Pasa el segundo factor. Ve su lista de secretos. Agrega uno nuevo. Lo recupera cuando lo necesita. Cierra la app.

Ese flujo parece trivial. Pero cuando lo dibujás paso a paso, aparecen las preguntas que importan: ¿qué pasa si la contraseña es incorrecta? ¿Cuántas veces puede fallar antes de bloquearse? ¿Cómo se maneja una sesión? ¿Qué sucede si la app queda abierta sin actividad?

Cada bifurcación en el flujo era una decisión de diseño. Y es mucho más fácil tomar esas decisiones en papel, donde borrar y rehacer no cuesta nada, que en código, donde cada cambio arrastra consecuencias.

Las tres capas que aparecieron solas

Cuando terminé de dibujar el flujo, algo interesante pasó: el sistema se organizó naturalmente en tres capas sin que yo lo planeara explícitamente.

La capa de autenticación. Todo lo que tiene que ver con usuarios: registro, login, hashing de contraseñas, segundo factor, bloqueo por intentos fallidos, cierre de sesión automático. Esta capa no sabe nada de secretos — solo sabe quién está adentro y quién no.

La capa de datos. Todo lo que tiene que ver con secretos: guardarlos, cifrarlos, recuperarlos, organizarlos por categoría, asociarlos a un usuario. Esta capa no sabe nada de autenticación — recibe un usuario ya verificado y opera sobre sus datos.

La capa de interfaz. Todo lo visual: la ventana, los campos, los botones, los mensajes de error. Esta capa no sabe nada de cifrado ni de autenticación — recibe información para mostrar y devuelve acciones del usuario.

Esa separación no fue una decisión arquitectónica deliberada. Emergió de dibujar el flujo y preguntarme: ¿quién sabe qué acá?

Lo que el papel reveló que el código hubiera ocultado

Hubo un momento específico en el diseño que me alegra haber resuelto antes de codear.

Estaba dibujando el flujo de cifrado y me pregunté: ¿la clave de cifrado viene de la contraseña del usuario o de una clave maestra separada?

Si viene de la contraseña, cambiar la contraseña implica recifrar todos los secretos. Si viene de una clave maestra, esa clave necesita estar guardada en algún lugar — y ese lugar se convierte en el punto más sensible del sistema.

Ninguna de las dos opciones es perfecta. Pero es un trade-off que necesitaba entender antes de empezar a construir, porque afecta toda la arquitectura. Si hubiera empezado a codear sin pensar en esto, hubiera tomado una decisión implícita sin darme cuenta — probablemente la más conveniente en ese momento, no la más correcta.

En papel, pude ver el trade-off completo antes de comprometerme con una dirección.

Cuándo el papel se termina

Hay un punto en el que seguir diseñando en papel se convierte en una forma de no empezar. Ese punto llegó cuando las preguntas que quedaban solo podían responderse escribiendo código.

¿Cómo se va a sentir el flujo de login? ¿El segundo factor va a ser lo suficientemente fluido? ¿La interfaz va a comunicar bien el estado del sistema?

Esas preguntas no tienen respuesta en papel. Solo se responden cuando hay algo corriendo.

El diseño previo no reemplaza la experimentación — la hace más eficiente. Llegás al editor sabiendo qué estás construyendo, con las decisiones grandes ya tomadas, y podés concentrarte en las preguntas que solo el código puede responder.

Lo que me llevaría a cualquier proyecto nuevo

Si tuviera que resumir lo que aprendí de este proceso en algo concreto, sería esto:

Antes de abrir el editor, escribí en una sola oración qué hace el proyecto. Después dibujá el recorrido completo de un usuario. Después preguntate, en cada paso: ¿quién sabe qué acá?

Esas tres cosas no garantizan un buen proyecto. Pero garantizan que cuando escribas la primera línea de código, sabés por qué la estás escribiendo.

Ciphie todavía no está publicado — estoy terminando los últimos detalles antes de la primera versión.

</div>

There's an enormous temptation when you have an idea: open the editor and start writing code. The adrenaline of seeing something work quickly is hard to resist.

With Ciphie I didn't do that.

Not because I have special discipline. But because I realized I didn't know exactly what I wanted to build. I had a direction — a local secrets manager, encrypted, with no cloud dependencies — but I didn't have clarity on how the pieces fit together. And in a security project, starting to code without that clarity is a sure way to build something with holes you won't see until it's too late.

So before writing a single line, I sat down with paper and drew the system.

The question that organized everything

The first exercise was simple: write in a single sentence what Ciphie did.

"A secrets manager that encrypts each entry individually, runs without a central server, and requires authentication to access."

That sentence seems obvious. But writing it forced me to make three decisions I hadn't made yet: per-entry encryption (not the whole file), no central server (all logic and data live on the user's machine), and authentication (users, passwords, sessions). Ciphie can make network calls for optional features — email account verification, SMS via Twilio, TOTP — but none of those integrations are required for the core to work.

Each of those words opened new questions. How is the encryption key derived? Where does the database live? What happens if someone fails the login five times in a row?

Before touching the keyboard, I had a page full of questions.

Drawing the flow, not the code

The first thing I drew wasn't a technical architecture. It was the journey of a hypothetical user through the application.

Someone opens Ciphie. Enters their password. Passes the second factor. Sees their list of secrets. Adds a new one. Retrieves it when needed. Closes the app.

That flow seems trivial. But when you draw it step by step, the questions that matter appear: what happens if the password is wrong? How many times can it fail before locking? How is a session managed? What happens if the app is left open without activity?

Every branch in the flow was a design decision. And it's much easier to make those decisions on paper, where erasing and redoing costs nothing, than in code, where every change drags consequences.

The three layers that appeared on their own

When I finished drawing the flow, something interesting happened: the system naturally organized itself into three layers without me explicitly planning it.

The authentication layer. Everything related to users: registration, login, password hashing, second factor, lockout on failed attempts, automatic session logout. This layer knows nothing about secrets — it only knows who's in and who's not.

The data layer. Everything related to secrets: storing them, encrypting them, retrieving them, organizing them by category, associating them with a user. This layer knows nothing about authentication — it receives an already-verified user and operates on their data.

The interface layer. Everything visual: the window, the fields, the buttons, the error messages. This layer knows nothing about encryption or authentication — it receives information to display and returns user actions.

That separation wasn't a deliberate architectural decision. It emerged from drawing the flow and asking myself: who knows what here?

What the paper revealed that the code would have hidden

There was a specific moment in the design that I'm glad I resolved before coding.

I was drawing the encryption flow and asked myself: does the encryption key come from the user's password or from a separate master key?

If it comes from the password, changing the password means re-encrypting all secrets. If it comes from a master key, that key needs to be stored somewhere — and that place becomes the most sensitive point in the system.

Neither option is perfect. But it's a trade-off I needed to understand before starting to build, because it affects the entire architecture. If I had started coding without thinking about this, I would have made an implicit decision without realizing it — probably the most convenient one at the time, not the most correct.

On paper, I could see the complete trade-off before committing to a direction.

When the paper runs out

There's a point where continuing to design on paper becomes a way of not starting. That point came when the remaining questions could only be answered by writing code.

How will the login flow feel? Will the second factor be smooth enough? Will the interface communicate the system's state well?

Those questions have no answer on paper. They're only answered when something is running.

Prior design doesn't replace experimentation — it makes it more efficient. You arrive at the editor knowing what you're building, with the big decisions already made, and you can focus on the questions that only code can answer.

What I'd take to any new project

If I had to summarize what I learned from this process into something concrete, it would be this:

Before opening the editor, write in a single sentence what the project does. Then draw the complete journey of a user. Then ask yourself, at every step: who knows what here?

Those three things don't guarantee a good project. But they guarantee that when you write the first line of code, you know why you're writing it.

Ciphie isn't published yet — I'm finishing the last details before the first version.

</div>