Sugerencias sobre el almacenamiento de contraseñas en la base de datos

Question

Aquí está la situación: es un poco diferente de las otras preguntas sobre bases de datos / contraseñas en StackOverflow.com

Tengo dos conjuntos de usuarios. Uno es el "primario" usuarios. Los otros son los "secundarios". usuarios. Todos tienen un nombre de usuario / contraseña para mi sitio (diga mysite.com, eso no es importante).

Antecedentes: los usuarios principales tienen acceso a un tercer sitio (por ejemplo, www.something.com/PrimaryUser1). Cada usuario secundario '' pertenece '' a un usuario principal y desea acceder a una subparte de ese otro sitio (por ejemplo, www.something.com/PrimaryUser1/SecondaryUser1).

En mysite.com, los usuarios principales deben proporcionarme sus credenciales que utilizan para acceder a www.something.com/PrimaryUser1, y especifican qué "subpartes" los usuarios secundarios de su elección obtienen acceso.

Mysite.com ayuda a administrar el sub-acceso de los usuarios secundarios al sitio del usuario primario. Los usuarios secundarios no pueden " ver " la contraseña de su usuario principal, pero a través de mi sitio, pueden acceder a las "subpartes" del otro sitio, pero SOLO a su subparte restringida.

De manera cruda, estoy implementando OAuth (o algo así).

La pregunta aquí es: ¿cómo debo almacenar las credenciales del usuario principal en el otro sitio? El punto clave aquí es que mysite.com usa estas credenciales para proporcionar acceso a los usuarios secundarios, por lo que DEBE poder leerlo. Sin embargo, quiero almacenarlo de tal manera que los usuarios principales estén seguros de que yo (como propietario del sitio) no puedo leer sus credenciales.

Supongo que esta es más una pregunta de enfoque teórico. ¿Hay algo en el mundo de la criptografía que pueda ayudarme con esto?

---

Texto agregado:

Dado que a la mayoría de las personas les falta la pregunta por completo, aquí está el intento # 2 para explicarla.

PrimaryUser1 tiene un nombre de usuario / contraseña para www.something.com/PrimaryUser1Site

Él desea otorgar acceso secundario a dos personas: SecondaryUser1 y SecondaryUser2 a las carpetas: www.something.com/PrimaryUser1Site/SecondaryUser1 y www.something.com/PrimaryUser1Site/SecondaryUser2

Mysite.com se encarga de esta gestión de subusuario, por lo que PrimaryUser1 va allí y proporciona sus credenciales a Mysite.com. MySite.com utiliza internamente las credenciales proporcionadas por PrimaryUser1 para brindar a los usuarios acceso limitado. Ahora, SecondaryUser1 y SecondaryUser2 pueden acceder a sus carpetas respectivas en www.something.com/PrimaryUser1Site a través de MySite.com

AHORA, surge la pregunta, ¿cómo debo almacenar las credenciales que PrimaryUser1 ha proporcionado?

Answer 1

Depende del tipo de autenticación que acuerden su sitio primario y el sitio secundario. ¿Se trata de autenticación, HTTP Basic o HTTP Digest? Si se trata de formularios o básicos, entonces no tiene otra opción, debe debe almacenar la contraseña, por lo que su única opción es cifrarla. No puede almacenar un hash de contraseña, ya que debe presentar el texto claro durante la autenticación para ambos formularios y HTTP Basic. Los problemas que surgen del almacenamiento de la contraseña cifrada se deben al uso incorrecto de la criptografía (es decir, no usa un IV o sal o no usa correctamente un cifrado de flujo), pero lo más importante es que tendrá una administración de claves problemas (dónde almacenar la clave utilizada para cifrar las contraseñas y cómo acceder desde un servicio / demonio no interactivo).

Si el sitio de terceros acepta HTTP Digest, entonces tiene mejor suerte, puede almacenar el HA1 hash parte del resumen Hash (es decir, MD5 de username: realm: password ) porque puede construir la respuesta Digest comenzando directamente desde HA1.

No mencioné cómo el usuario aprovisiona las credenciales secundarias (es decir, cómo obtiene el nombre de usuario y la contraseña del sitio secundario en primer lugar), supongo que ha asegurado un canal protegido (es decir, HTTPS del cliente a su sitio principal) )

Por cierto, esto supone que la autenticación se produce entre su sitio primario y secundario y el contenido del sitio secundario se canaliza a través de una solicitud HTTP realizada en el sitio primario. Si ese no es el caso y se accede al sitio secundario directamente desde el navegador, entonces el sitio secundario debe admitir algún tipo de autorización basada en token previamente autenticada de terceros como OAuth. Confiar en la autenticación de credenciales y almacenar las credenciales en el sitio primario cuando el navegador realmente necesita las credenciales tiene tantos problemas que ni siquiera vale la pena hablar de ellos.

Answer 2

Primera regla: ¡Nunca, nunca almacene contraseñas! Segunda regla: calcule un hash sobre contraseña, con sal adicional, y guárdelo en su base de datos. Tercera regla: un nombre de usuario (en mayúsculas) podría usarse como sal, ¡pero preferiblemente agregue un poco más como sal! (Algún texto adicional, preferiblemente algo largo). Cuarta regla: no importa cuán seguro sea un algoritmo de hashing, todos serán pirateados tarde o temprano. ¡Todo lo que se necesita es tiempo! Quinta regla: la seguridad de su sitio depende del valor de lo que hay detrás de él. ¡Cuanto más valor tenga el contenido, más probabilidades hay de que te ataquen! Sexta regla: descubrirá, tarde o temprano, que su sitio está pirateado, pero no a través de una contraseña pirateada, sino a través de una laguna en algún otro lugar de su código. El mayor riesgo es esperar que su sitio sea seguro ahora que ha implementado una seguridad sólida. Séptima regla: se puede romper toda la seguridad, se pueden piratear todos los sitios, se pueden descubrir todos sus secretos, si solo las personas están dispuestas a invertir el tiempo suficiente para hacerlo.

La seguridad es una ilusión, pero mientras nadie la rompa, ¡puedes seguir soñando! Siempre prepárate para despertares bruscos que requerirán que reconstruyas tu ilusión nuevamente. (En otras palabras, ¡haga copias de seguridad periódicas! (Preferiblemente diariamente). No sobrescriba las copias de seguridad de la última semana y asegúrese de mantener al menos una copia de seguridad de cada semana, en caso de que descubra que su sitio fue pirateado hace meses y todo sus copias de seguridad desde entonces están infectadas!

Ahora, si realmente necesita almacenar contraseñas, use un hash sobre nombre de usuario más contraseña. Luego hash de nuevo con hash más sal! Mejor aún, cree una lista de sales (solo una lista de palabras) y cada vez que se cree una nueva cuenta de usuario, elija una palabra de sal al azar para usar para cambiar su nombre de usuario más contraseña. Almacene el índice de sal con la cuenta de usuario para saber cuál usar cada vez que vuelva a iniciar sesión.

Y: Octava regla: ¡use siempre HTTPS! ¡No es tan seguro como la mayoría de las personas, pero da una sensación de seguridad a sus usuarios!

---

Como ha agregado texto, agregaré más respuestas.

Dado que desea que el usuario1 otorgue acceso temporal al usuario 2, necesitará una tabla de usuario secundaria. (O expanda la tabla de usuario con una ID de usuario principal. También agregue una marca de tiempo para realizar un seguimiento de la antigüedad de la cuenta. El usuario 1 puede crear las credenciales y esto se hace de la manera normal. Simplemente almacene un hash con nombre de usuario y sal combinados. En en este caso, use el nombre de usuario del usuario 1 como sal adicional. Solo asegúrese de deshabilitar la cuenta del usuario 2 cuando el usuario 1 cierre la sesión o cuando haya transcurrido un cierto período de tiempo. Y permita que el usuario 1 vuelva a habilitar todas las cuentas que él creó, para que puedan reutilizar una cuenta en lugar de tener que crear nuevas todo el tiempo.

La seguridad no es un asunto que depende de los usuarios primarios o secundarios. En general, ¡trátalos de la misma manera! Los usuarios secundarios tienen una ventaja adicional de que puede usar la cuenta principal como sal adicional. El resto ya no tiene nada que ver con la autenticación. Es la autorización con la que estás tratando. Y aunque la autenticación y la autorización tienen una relación sólida, tenga en cuenta que debe tratarlas como dos técnicas diferentes e independientes.

Cuando el usuario 1 inicia sesión, se le otorga acceso al sitio principal. Cuando concede acceso al usuario 2, el usuario 2 obtiene un conjunto reducido de roles. Pero esto no tiene nada que ver con el almacenamiento de nombres de usuario o contraseñas. Solo tiene una ID de usuario que es miembro de ciertos roles o grupos. O no, pero sería inaccesible.

Ambos son solo usuarios, uno con más derechos que el otro.

Answer 3

¿Ha pensado en aceptar OpenID como lo hace Stack Overflow? De esa manera, usted no es responsable de almacenar contraseñas en absoluto.

Answer 4

Solo hay una forma de hacerlo, y probablemente sea demasiado divertido para los usuarios.

Puede cifrar la contraseña del usuario con una clave pública / privada, el usuario conserva su clave para que la contraseña no se pueda cifrar solo cuando la clave se devuelve a su servidor. La única forma de simplificar esto sería tener algunos complementos de navegador web que envíen automáticamente la información.

Y de cualquier manera, siempre puede oler paquetes de la comunicación hacia / desde el servidor, por lo que sigue siendo inútil.

Answer 5

tiene que haber una mejor manera de explicar esto :(

pero si solo quiere saber cómo almacenar las contraseñas de manera segura, haga esto:

nombre de usuario: juan, contraseña: pasar

key = '!! @ ijs09789 ** & amp; *';

md5 (username.password.key);

cuando inician sesión solo verifique si md5 (username.password.key) = es igual al de db; también puede usar sha1 y / o cualquier otro método de cifrado.

http://us.php.net/md5 & amp; http://us.php.net/sha1

Answer 6

Nunca almacene contraseñas en una base de datos, pero almacene una versión salada y hash de cada contraseña.

Verifique este artículo si esto es chino para ti.

Answer 7

Si desea almacenar la contraseña usted mismo, el mejor método es utilizar un algoritmo de hash unidireccional como MD5 o SHA-1. La ventaja de este enfoque es que usted no puede derivar la contraseña del valor hash.

Precisamente el algoritmo que elija depende de los productos precisos que esté utilizando. Algunas herramientas de front-end ofrecen estas funciones, al igual que algunos productos de bases de datos. De lo contrario, necesitará una biblioteca de terceros.

Editar

Los usuarios secundarios deben tener sus propias contraseñas. ¿Por qué no lo harían?

Answer 8

Lo estás haciendo demasiado complejo. Debe dejar de intentar mezclar autenticación y autorización.

Lo que desea hacer es establecer credenciales para todos, sin preocuparse en este momento si son "primarios". o "secundario" usuarios. Luego, en el sitio principal, donde administra los usuarios y las relaciones primarias / secundarias, puede hacer la lógica de qué usuarios son primarios o secundarios y almacenar todo eso en una tabla. Usted otorga o niega los derechos y sub-derechos que desee a cada usuario secundario cada vez que los usuarios principales actualicen sus relaciones con ellos. Cuando terminen, finalmente tendrá que replicar las credenciales de usuario apropiadas desde el sitio principal hacia los sitios secundarios.

Luego, cuando un usuario secundario quiere dirigirse a cualquier sitio en su granja, se autentican solo como ellos mismos, ¡nunca suplantan al usuario principal! Y solo tienen los derechos que usted les otorgó cuando los usuarios principales les dieron "secundarios". estado.

-

OK, ya que eliminó esa solución en el comentario, considere esto:

Primero, dudo que algo sea realmente seguro. Siempre puede recuperar el secreto si supervisa la actividad de los usuarios.

Ahora, esto está completamente fuera del alcance, y no lo he criptoanalizado, pero compruebe lo que se llama intercambio secreto . Almacene el " efectivo " o "real" contraseña de usuario principal del sitio principal como secreto compartido. Use el hash salado de la contraseña dada por el usuario principal como un secreto. Use el hash salado de la contraseña dada por el primer usuario secundario como otro secreto, y así sucesivamente para cada usuario secundario adicional. ¡No guardes los hash salados! Simplemente almacene la sal y el secreto compartido protegido.

Cuando un usuario ingresa su contraseña, usted recupera el secreto compartido protegido, usa la sal y el hash de su contraseña para producir el hash salado, descifra el secreto compartido protegido y ahora tiene la contraseña de usuario principal original.