¿Existe una razón importante para eliminar y eliminar las contraseñas cuando la reutilización de la contraseña no es un problema?

5

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:

  1. Un atacante puede obtener acceso a su base de datos.
  2. 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 ...
  3. 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.

    
pregunta lzam 18.09.2014 - 17:05
fuente

2 respuestas

2

Es una pregunta justa, hay consideraciones que quizás no hayas pensado:

  • Hay formas en que los atacantes pueden obtener acceso a partes de su base de datos sin acceder a todas, por lo que su punto 2 no es del todo correcto. Los errores de codificación pueden filtrar datos, al igual que las vulnerabilidades de SQL. Un atacante podría obtener un volcado de sus contraseñas y nada más
  • Si no está almacenando sus códigos de acceso con hash, es probable que los esté transmitiendo en el claro, en cuyo caso podrían ser detectados si no está usando SSL correctamente. Hashing esto proporcionaría una defensa en profundidad contra los ataques contra la transmisión
  • Las contraseñas almacenadas de Hashing muestran la debida diligencia y un compromiso con la seguridad. Si fue violado y se supo que no estaba eliminando sus contraseñas, se vería mal, incluso si su razonamiento fuera acertado. Si fueras auditado, se vería mal también

Mi consejo sería que hash tus contraseñas, es bastante fácil de hacer y el beneficio está ahí.

    
respondido por el GdD 18.09.2014 - 17:27
fuente
0

En realidad he reflexionado sobre este problema exacto antes. Si su clave de API se usa básicamente solo para la inserción, el problema real es la pérdida de información y los datos incorrectos que ingresan a la cuenta de un usuario. Parece que tiene controles de seguridad adecuados para lo que es verdaderamente importante: el acceso de los usuarios a los datos. No veo ninguna necesidad de hash estos necesariamente. Idealmente, cualquier credencial de autenticación (incluso de escritura solamente y no de lectura) debería estar oculta, pero como el sistema ya está construido, entiendo que puede requerir un gran esfuerzo cambiar. Simplemente me aseguraría de que los usuarios estén conscientes de que necesitan mantener sus claves de API en secreto y no compartirlas.

    
respondido por el theterribletrivium 18.09.2014 - 20:41
fuente

Lea otras preguntas en las etiquetas