Siete capas de seguridad
InfoCifrada no confía en una sola defensa. Por debajo de todo está el cifrado AES-256-GCM, pero por encima hay siete capas más, todas verificadas en el código y no solo declaradas en un folleto.
Capa 1 · Autenticación
Contraseñas de acceso con bcrypt y salt automático, verificación resistente a ataques de tiempo y mínimo de 8 caracteres validado en servidor. La verificación de email es obligatoria: una cuenta recién creada no entra hasta pulsar el enlace del correo. Y no hay registro público — las cuentas solo las crea un administrador, así que la superficie de alta masiva es cero. El mensaje de error es siempre el mismo, para no revelar qué cuentas existen.
Capa 2 · Limitación de intentos
Cinco intentos fallidos en una ventana de quince minutos bloquean el acceso. El recuento va por dirección de correo y por IP, así que no se esquiva cambiando de cuenta ni de usuario. Un acceso correcto limpia el contador, y cada bloqueo deja su propio registro de auditoría. Ambos parámetros son configurables.
Capa 3 · Sesiones
Cookie de sesión con nombre propio del proyecto, marcada httponly —JavaScript no puede leerla—, con samesite: Lax y con el atributo secure automático cuando hay HTTPS. En cada acceso correcto se regenera el identificador de sesión, que es lo que anula la fijación de sesión. El cierre vacía la sesión, expira la cookie y la destruye.
Capa 4 · Protección CSRF
Un token de 32 bytes aleatorios, con cuatro horas de vida y comparación resistente a ataques de tiempo. Todos los formularios del sistema lo llevan y todas las pantallas lo validan, comprobado uno por uno. Los puntos de acción rechazan cualquier método que no sea POST.
Capa 5 · Autorización
Cada pantalla y cada acción empieza exigiendo su permiso concreto; sin él, la respuesta es un 403 y se acabó. Los permisos se resuelven contra la base de datos en cada petición y no se cachean en la sesión, así que revocar un permiso tiene efecto inmediato sin esperar a que el usuario vuelva a entrar. Y la bóveda va más allá: todas sus consultas filtran por el usuario de la sesión, nunca por uno que venga del formulario.
Capa 6 · Entrada y salida
En base de datos, exclusivamente sentencias preparadas reales —no emuladas—, sin una sola concatenación de valores de usuario. En pantalla, todo el texto pasa por el escapado de HTML. La validación se hace siempre en servidor, nunca solo en el navegador: longitudes, formatos de correo, expresiones regulares para identificadores y comprobación de existencia real en base de datos para cada referencia. Hasta el asunto de los correos se limpia de saltos de línea, para impedir la inyección de cabeceras.
Capa 7 · Cabeceras y sistema de archivos
Se envían cabeceras de seguridad antes de cualquier salida, incluida una política de contenido que no admite JavaScript incrustado en el HTML: todos los manejadores viven en un fichero aparte. Eso neutraliza la mayoría de vectores de inyección aunque llegara a colarse contenido malicioso. En disco, las carpetas de código de servidor están bloqueadas al acceso web, igual que el listado de directorios, los métodos HTTP innecesarios, los ficheros sensibles y los sondeos típicos de bots.
El resumen, en una frase
Autenticación con bcrypt y verificación de correo · bloqueo por intentos fallidos · sesiones endurecidas · protección CSRF en cada formulario · permisos comprobados en cada pantalla · consultas preparadas y escapado total · cabeceras de política de contenido y bloqueo a nivel de sistema de archivos. Y por debajo de todo, AES-256-GCM.
Qué aporta ante una inspección
Conviene formularlo con precisión, porque es donde más se exagera en este sector: InfoCifrada aporta medidas técnicas que ayudan a demostrar cumplimiento. No es una certificación y no se vende como tal. Quien te diga que un software «te pone en cumplimiento del RGPD» te está vendiendo humo.
| Exigencia | Cómo responde InfoCifrada |
|---|---|
| RGPD art. 32 — cifrado de datos personales | AES-256-GCM sobre los campos sensibles |
| RGPD art. 32 — confidencialidad e integridad | Cifrado autenticado con detección de manipulación |
| RGPD art. 32 — capacidad de restaurar el acceso | Copias de seguridad más procedimiento documentado de custodia del salt |
| RGPD art. 30 — registro de actividades | Auditoría de solo lectura con usuario, IP y marca temporal |
| Principio de mínimo privilegio | Permisos granulares por rol, comprobados en cada pantalla |
| Trazabilidad de accesos | Registro de accesos correctos, fallidos y bloqueados |
| Soberanía del dato y no transferencia internacional | El dato no sale del servidor del cliente |
| Segregación de funciones | Perfil auditor: lee todo, no modifica nada y no accede a ninguna bóveda |
Y lo que hoy no hace
Un producto sin limitaciones declaradas no se lo cree nadie, y menos en seguridad. Estas son las carencias actuales, dichas por delante:
| Limitación | Qué significa en la práctica |
|---|---|
| Sin doble factor | El acceso depende solo de la contraseña. Lo compensan el bloqueo por intentos, la verificación de correo y que las cuentas solo las crea un administrador. Es lo primero del plan de desarrollo. |
| Sin caducidad de sesión por inactividad | La sesión dura lo que dure la cookie del navegador. También está en el plan. |
| Salt único por instalación, no por entrada | Dos usuarios con la misma contraseña de bóveda derivan la misma clave. Un atacante que tuviera a la vez la base de datos y el salt podría atacar por diccionario las contraseñas débiles. Hoy lo mitigan las 200.000 iteraciones y que el salt vive fuera del repositorio. |
| Sin recifrado masivo | Cambiar la contraseña de bóveda obliga a editar entrada por entrada. |
| Sin adjuntos | Solo texto: no se pueden custodiar certificados ni ficheros de clave. |
En la comparativa están también las columnas donde InfoCifrada pierde frente a un gestor comercial. Preferimos que lo sepas antes de comprar y no después.
¿Tienes un responsable de seguridad que quiera repasar esto?
Encantados. Es la conversación que mejor se nos da, y el código está para auditarlo.
Escríbenos