Estoy tratando con un sistema (en desarrollo) que usa cadenas generadas aleatoriamente (no proporcionadas por el usuario), únicas para autenticar los servicios que consumirán una API. En este momento, estas cadenas se almacenan en la base de datos en texto sin formato.
Me gustaría entender si hay una razón sólida para volver a diseñar este sistema, de modo que estas cadenas estén saladas y picadas.
Mi comprensión de las razones para almacenar contraseñas solo como hash con sal es la siguiente:
- Un atacante puede obtener acceso a su base de datos.
- En este punto, no le queda mucho por perder, el atacante ya puede ya acceder a los datos de su cliente y hacer casi lo que quiera. Las contraseñas de los usuarios son un punto discutible. SIN EMBARGO ...
- Sus usuarios pueden usar la misma contraseña para otras cosas. Si no lo hace correctamente, el atacante puede usar las credenciales robadas para obtener el control de otros recursos que no tienen nada que ver con su sistema (además de compartir los mismos usuarios, con malos hábitos de contraseña).
En otras palabras, el punto de las contraseñas de salado y hash es proteger a los usuarios de las consecuencias de la reutilización de la contraseña. En mi caso, sin embargo, la reutilización de la contraseña no debería ser un factor.
¿Todavía hay una razón importante para modificar el sistema para saltear y trocear estas "contraseñas" también?
Editar:
Al menos algunas de estas claves de API terminarán integradas en aplicaciones ampliamente distribuidas de todos modos. La clave API solo no será suficiente para acceder a toda la información confidencial. También se requerirá un nombre de usuario y contraseña regulares en la mayoría de los casos. Ciertos usuarios de API con privilegios especiales estarán restringidos por la dirección IP.