Claves fuera del código y secretos que se reportan sin copiar

El informe de una revisión circula: lo leen el equipo de desarrollo, la gerencia y, a veces, un tercero. Si el informe copia el valor de la clave hallada, el propio informe se convierte en una fuga. La práctica es anotar el tipo de secreto (qué abre o qué firma), su ubicación exacta (archivo y línea, o nombre del recurso) y el alcance (qué permite hacer a quien lo tenga), y dejar el valor fuera. Quien corrige encuentra la fila sin necesidad del valor.

El equipo puede confirmar el valor en su repositorio; el informe no es el lugar donde se guarda.

Una clave simétrica escrita como constante en el código no está escondida: está repartida en cada instalación, y ofuscarla solo retrasa a quien la busque. Además, una clave ya publicada no se arregla borrándola de la versión siguiente: las versiones antiguas siguen circulando y siguen llevándola. Se da por comprometida, se rota y lo que protegía se vuelve a proteger con una clave que nazca en el dispositivo o en el servidor. Abre el laboratorio y lee el informe del barrido. Localiza dónde está la clave AES fija.

Un barrido marca todo lo que se parece a una credencial, y no todo lo marcado lo es. Una clave pública está hecha para repartirse: sirve para verificar firmas, no para firmar. Un identificador de cliente restringido al paquete de la aplicación y a la API que usa no permite a quien lo copie hacer nada propio. En cambio, una clave que factura a nombre de la empresa o que cifra datos de los usuarios sí es secreta. La pregunta de cada fila es qué puede hacer con ella quien la lea.

Hay secretos que no pertenecen a la aplicación en ningún caso: son del equipo que la construye. La contraseña del almacén de firma, por ejemplo, permite firmar versiones como si fueran de la empresa. Suelen colarse desde el entorno de compilación en un archivo de propiedades o de configuración que se empaqueta por descuido. Se reportan con la máxima prioridad y se rotan. Lee el informe del barrido y localiza ese archivo.

Cuando la clave debe salir de algo que el usuario escribe, se usa una función de derivación lenta y con sal: una sal aleatoria distinta por usuario y un costo (iteraciones o memoria) lo bastante alto para que probar contraseñas masivamente sea caro. Una sal fija para todos permite preparar una sola tabla de ataque que sirve contra todos; pocas iteraciones hacen cada intento barato. Los parámetros concretos se toman de las guías vigentes de almacenamiento de contraseñas y se revisan con el tiempo. El informe describe qué falla en la propuesta (la sal, el costo, la función) y qué se espera, sin inventar cifras.