Guías de seguridad
Contraseñas, MFA, dispositivos, Wi-Fi pública, servidores, dependencias, Git y entornos expuestos: guías prácticas y orientadas a objetivos sobre defensas que puedes aplicar hoy.
Cómo guardar contraseñas con seguridad — la forma correcta de aplicar hash y salt
Una guía práctica para guardar contraseñas con seguridad en el servidor. Entiende por qué el texto plano, el cifrado y los hashes simples fallan todos, y luego converge en una respuesta: un salt por usuario más un hash deliberadamente lento (Argon2id recomendado, bcrypt/scrypt como alternativas). No lo inventes tú — usa la función estándar, sube el coste con el tiempo y migra los hashes débiles re-hasheando al iniciar sesión.
Seguridad para la era de la IA: los fundamentos que blindar ya (lista de prioridades)
La IA sobre todo amplifica los ataques sobre debilidades EXISTENTES (CVE sin parchear, contraseñas reutilizadas, secretos expuestos) más que inventar nuevas — encontradas de forma automática, rápida y a escala. Así que la mejor preparación es blindar los fundamentos en el orden correcto: parcheo de CVE + monitoreo de dependencias, eliminar la reutilización + MFA, quitar secretos expuestos, mínimo privilegio, reducir la superficie pública, registros/IOC, copias de seguridad.
Qué funciona (y qué no) para la seguridad en la era de la IA — por qué también golpean a los sitios pequeños
Cuatro mitos de la era de la IA corregidos: (1) demasiado pequeño para ser objetivo → la automatización elimina «un humano te elige»; (2) necesita un control nuevo especial → los fundamentos siguen ganando; (3) un producto te hace seguro → diseño de prevención antes que detección; (4) el código de IA es rápido, así que es seguro → se despliega con vulnerabilidades, revisa antes de publicar. Lo que funciona son los aburridos fundamentos en el orden correcto.
¿Un correo de phishing falsificó tu propio dominio? Suplantación vs intrusión, y cómo detenerla
Un correo sospechoso que parece venir de tu propio dominio normalmente no es una intrusión — es un From falsificado, porque SMTP permite a cualquiera escribir la línea From. Leer las cabeceras (Authentication-Results, Received, Reply-To) distingue una intrusión de una falsificación. La razón principal de que llegue a tu bandeja de entrada es la falta de una política DMARC. Corrígelo con SPF → DKIM → DMARC (p=none → reject).
Fundamentos de copias de seguridad: la regla 3-2-1 y un plan de recuperación que sobrevive al ransomware
«Tengo una copia de seguridad» no basta — solo es real una copia que has verificado que puedes restaurar. Los fundamentos: la regla 3-2-1 (tres copias, dos tipos de medio, una fuera del sitio). Para el ransomware además necesitas al menos una copia «offline o inmutable» — una copia siempre conectada se cifra junto con el original. La sincronización en la nube no es una copia de seguridad (también replica borrados y cifrado). El versionado y una prueba de restauración periódica completan la práctica.
Detén los secretos antes de hacerles commit con gitleaks: atrapa fugas de claves de API antes del push
Los secretos no se pueden «borrar después de que se filtran». Una vez con commit, un secreto se queda en el historial de Git, y una vez con push debe tratarse como filtrado — la clave necesita revocarse/rotarse. gitleaks es una herramienta gratuita que escanea todo el repo y el historial de commits con regex/entropía para encontrar claves de API, claves privadas y tokens. El núcleo de la defensa son dos puertas: un hook de pre-commit que lo detiene localmente antes del push, y CI/cron que atrapa lo que se cuela. .gitignore solo evita el nuevo seguimiento — no puede detectar, así que aún necesitas un escáner.
Elegir bien la MFA: qué significa «resistente al phishing» y por qué el SMS es débil
La MFA es una segunda cerradura para que una contraseña filtrada por sí sola no permita entrar — pero lo que actives cambia su fortaleza en tres niveles. Los códigos por SMS/correo caen ante el phishing por relay y el SIM-swap; las apps de autenticación (TOTP) están en medio; las passkeys/llaves de seguridad (FIDO2) no pueden presentarse a un sitio falso en absoluto — eso es resistencia al phishing. Máxima prioridad: pon MFA resistente al phishing en las llaves del reino (correo, dominio, pagos). Guardar los códigos de recuperación y tener un factor de respaldo completan la configuración.
¿Sigues con Windows 10? Los riesgos de seguridad de usarlo tras el fin de soporte
Windows 10 llegó al fin de soporte el 14 de octubre de 2025. El riesgo central de quedarse es que los agujeros recién descubiertos nunca se parchean (forever-days) y se acumulan, haciendo de la máquina un objetivo predilecto. La ESU de consumo es un parche temporal de un año, solo de seguridad, hasta el 13 de octubre de 2026 (existen vías de inscripción gratuitas, pero el primer año gratis del EEE no aplica en la mayoría de las regiones). La solución real es pasar a Windows 11 o reemplazar el hardware — usa la ESU solo como puente hasta completar esa migración.
BitLocker vs «Cifrado de dispositivo» — la misma tecnología, versión completa vs versión ligera automática
BitLocker y el Cifrado de dispositivo comparten el mismo motor de cifrado. Cifrado de dispositivo = la versión automática y ligera que funciona en Home (se activa solo con una cuenta de Microsoft, la clave de recuperación se deposita automáticamente, opciones mínimas). BitLocker = la versión completa en Pro+ (PIN de inicio, cifrado de unidades externas con To Go, control fino). Para particulares, estar cifrado automáticamente más saber dónde está la clave de recuperación suele bastar. El estado importa más que el nombre.
Corregir CVE de dependencias de verdad: escanear, corregir, aislar y seguir vigilando
El trabajo de vulnerabilidades no termina cuando «lo corriges». Hecho = 1) escanear, 2) corregir, 3) aislar/delegar, 4) monitorear. Hasta que el monitoreo (detección diaria de cambios) esté en marcha, está incompleto — las dependencias vuelven a ser vulnerables mañana. Una corrección perfecta que el siguiente despliegue sobrescribe vale cero. Los equipos pequeños se mantienen seguros con dos disciplinas: detección automatizada de cambios y «local→push→deploy».
Proteger un portátil que llevas contigo — defensa contra robo, pérdida y miradas indiscretas
Llevar un portátil asume que lo perderás o te lo robarán. La defensa real se diseña para que una pérdida no filtre el contenido: cifrado de disco (BitLocker/FileVault), un inicio de sesión fuerte con bloqueo automático corto, y borrado/localización remotos. Con HTTPS en todas partes, el sniffing de Wi-Fi público es de menor prioridad; las amenazas reales son los puntos de acceso falsos, las miradas indiscretas y alejarse del equipo. No confíes en exceso en una VPN — endurece primero el dispositivo.
Instalar y usar osv-scanner: encuentra CVE en tus dependencias
osv-scanner escanea lockfiles y contenedores para sacar a la luz CVE en tus dependencias, gratis. Esto recorre la instalación, la ejecución y la integración en CI, además de cuándo usarlo frente a npm/pnpm audit y Dependabot. La visión de este sitio: la herramienta correcta la decide TU configuración — recurre a osv-scanner en proyectos multiecosistema o sin GitHub, y al pnpm audit incluido para un único árbol npm.
¿Son seguros los gestores de contraseñas? Cómo funcionan, nube vs local y cómo elegir
Un gestor de contraseñas es más seguro que reutilizar o guardar en texto plano. La clave es el cifrado de conocimiento cero: tu contraseña maestra descifra la bóveda solo en tu dispositivo, el proveedor solo guarda texto cifrado, así que una brecha del proveedor no expone tus contraseñas. El verdadero punto único es tu contraseña maestra más el MFA de la bóveda. Elige nube (Bitwarden/1Password) o local (KeePass) según el uso.
Los peligros del Wi-Fi público — el riesgo real no es el 'sniffing', son los gemelos malvados y las advertencias de certificado ignoradas
El 'sniffing' en Wi-Fi público está mayormente mitigado por HTTPS y ahora es de menor prioridad. Los riesgos reales son (1) conectarte tú mismo a un punto de acceso falso (gemelo malvado), (2) ignorar advertencias de certificado y (3) exponer tu dispositivo en la red compartida. La solución más fuerte es sorprendentemente simple — usa el anclaje a red móvil de tu teléfono, confía en HTTPS y en las advertencias de certificado, y no te unas automáticamente a SSID desconocidos. Una VPN es la siguiente capa.
¿Dejaste un archivo de secretos en un directorio público? Audita tu webroot
Cualquier cosa en tu webroot puede descargarse por URL por cualquiera. Un JSON de token/credenciales olvidado, un .env o una copia de seguridad significa exposición instantánea — y si vino de una plantilla compartida, todos los sitios tienen el mismo agujero. Solución: coloca en el directorio público solo cosas compartibles públicamente, mantén los secretos fuera del webroot con permisos 600, y una vez que encuentres uno, audita cada sitio y servidor.
La base de seguridad para desarrolladores independientes y pequeños operadores: el conjunto estándar completo
La base no es 'todo igual de importante'. El orden de prioridad de este sitio: 1) llaves del reino (MFA, dominio, correo), 2) secretos y código, 3) la propia app, 4) parchear, detectar, recuperar. Con tiempo finito, complétala de arriba abajo. La mayoría de las brechas graves no vienen de ataques novedosos sino de un hueco en esta base.
La base de seguridad para organizaciones medianas y grandes: el fundamento estándar para equipos
A escala, la base pasa de una 'lista de comprobación' a 'programas con responsables'. El orden de prioridad coincide con la versión independiente: 1) identidad, 2) secretos y cadena de suministro, 3) app e infraestructura, 4) detectar y responder, más una capa transversal de personas y gobernanza. El gran cambio: la principal causa de brechas pasa de los descuidos a las personas, los procesos, el acceso de exempleados y los terceros.
Inventario de seguridad — 7 comprobaciones que pasan por alto quienes operan varios servidores
Para operadores solos/pequeños, los incidentes vienen menos de controles ausentes que de estado sin seguimiento. La frontera es el PC que guarda tus claves. Escalona el 2FA por raíz de confianza, haz una matriz de tus claves SSH para eliminar duplicados/sin usar/huérfanas, quita las contraseñas en texto plano de la nube, remedia de forma reversible una a una, y mantén los secretos fuera del registro. Inventario antes de añadir herramientas.
Git autoalojado vs GitHub: ¿cuál es realmente más seguro?
Autoalojar Git no te hace 'más seguro' — reubica el riesgo. La clase de exposición pública accidental desaparece, pero parchear el servidor, las copias de seguridad y la detección de secretos pre-commit pasan a ti. La decisión correcta si pagas el precio; peor que GitHub si lo descuidas. La visión de este sitio: el autoalojamiento solo funciona acompañado de sus controles compensatorios.
Seguridad básica del smartphone — proteger el dispositivo que reúne tus claves, tu bóveda y tu identidad en uno
Un teléfono concentra el 2FA, el correo, la banca y la identidad en un único punto de fallo. La defensa real no es una app de seguridad: (1) un bloqueo fuerte + autobloqueo corto (el código es la clave de cifrado); (2) actualizaciones automáticas del SO/apps; (3) tienda oficial + revisión de permisos; (4) configurar de antemano el bloqueo/borrado remoto; (5) mantener un respaldo de tu 2FA. iOS/Android ya cifran y aíslan por defecto.
No des claves de root a entornos que pueden ser comprometidos: privilegio mínimo en claves SSH
Registrar una clave de root en producción desde un entorno efímero y comprometible (pod de GPU, runner de CI, VM desechable) significa que en el momento en que ese entorno se compromete, se toma producción con root. Solución: sin claves de root en entornos efímeros; quita las claves cuando no se usen; si se necesita de nuevo, usa un usuario no-root más una clave restringida a un comando que limite la clave a una sola operación. Una clave reutilizada es tu activo más crítico — nunca construyas un montaje de 'una fuga, todo'.
¿Es seguro guardar tus contraseñas en Google Drive? Cómo conservarlas correctamente
Guardar contraseñas en un Documento/Hoja de Google en texto plano es peligroso: una cuenta de Google se convierte en el punto único de fallo de cada contraseña — la toma de la cuenta, una app conectada maliciosa o el phishing las filtran todas de golpe. La solución es un gestor de contraseñas dedicado (el contenido sigue cifrado incluso al sincronizar). Si debes usar Drive, guarda solo un archivo de bóveda cifrado y pon MFA resistente al phishing en la cuenta.
Por qué se banea una cuenta de OpenAI: claves de API robadas y la política de destilación
Cuando una clave de API robada se abusa para 'destilación', hasta la cuenta de la víctima puede suspenderse automáticamente. Una guía defensiva y anonimizada sobre el mecanismo, la prevención y las apelaciones.
Qué es la suplantación de X-Forwarded-For (XFF) — la trampa de la configuración de proxy de confianza
XFF es un encabezado falsificable por el cliente. Un escáner ciego esconde sondeos de inyección en un XFF suplantado; 'confiar en todos los proxies (comodín)' lo deja pasar. Parche = sanear el encabezado de IP en el límite; solución raíz = confiar en los proxies correctos (o en ninguno). El impacto cero aun así dejó un ajuste por arreglar.
Código escrito por IA filtró una clave de API y generó cargos fraudulentos — la causa real era un CVSS 10.0 sin parchear
El pico en la factura fue un síntoma. La causa real era un RCE público CVSS 10.0 sin parchear. Un caso anonimizado, destilado en lecciones defensivas.
Fundamentos de seguridad: qué es lo realmente peligroso de .env y las claves de API
Empieza aquí. Entiende qué pasa cuando se filtran .env y las claves de API (copia de la llave → suplantación → facturación fraudulenta), luego adopta cuatro hábitos hoy: no exponerlas, no hacerles commit, rotar todo si se filtran, y autocomprobar.
El .env de apps Laravel era legible por todo el mundo — el error más común del hosting compartido
La causa: toda la app estaba bajo la raíz web; solo public/ debería ser visible. Corrige en tres pasos — primeros auxilios con .htaccess, rotar claves, reestructurar — y luego prevenlo con proceso.
Ejecutar Next.js de forma segura: no quedarse atrás con los CVE publicados
El mayor riesgo del framework son los CVE publicados descuidados. Defiende con cuatro pilares: juzgar por la versión en ejecución, monitorear con Dependabot/osv-scanner, actualizar rápido, y operar con mínimo privilegio. La visión de este sitio: los desarrolladores indie no pierden por conocimiento sino por continuidad operativa — gana con un sistema que no falla, no con velocidad.
Mantener el .env fuera de la web pública en hosting compartido
La solución real: el cuerpo de la app fuera del docroot, solo public/ expuesto. Frena la hemorragia con .htaccess, hazlo permanente reestructurando, luego autocomprueba. La visión de este sitio: esto no es el descuido de una persona sino un mal patrón estandarizado por el sector — arréglalo con proceso, no con vigilancia. bootstrap-redirect vence al symlink.