2011-02-23 15 views
6

He leído muchas cosas sobre la autenticación en CouchDB, especialmente con respecto a la Autenticación de cookies. todavía estoy haciendo algunas pruebas y todo parece funcionar bien, por ejemplo con este comando:Autenticación de CouchDB

rizo -VX POSTAL $ HOST/_SESSION -H 'aplicación urlencoded x-www-form /' -d ' name = foo & password = bar '

obtengo una cookie que puedo usar. Pero mi punto es que cada vez que veo una especie de muestra en la Web, el nombre de usuario y la contraseña siempre se envían en texto sin formato.

Soy realmente nuevo en seguridad pero, ¿cuál es el interés del método Cookie Auth si primero tengo que enviar mis credenciales en claro?

¿Hay alguna forma de enviar al menos la contraseña hash? Con algo así IDK:

rizo -VX POSTAL $ HOST/_SESSION -H 'application/x-www-form-urlencoded' -d 'name = foo & hashed_password = hashed_bar'

Saludos

Arnaud

Respuesta

11

Si envía su contraseña con algoritmo hash que todo el atacante necesita saber es el hash de la contraseña por lo que no resolvería el problema de enviar la contraseña en texto plano - ahora que lo haría ja hay un problema al enviar su hash en texto claro.

Recuerde también que, incluso si eso resolviera el problema, aún estaría enviando su cookie en texto sin formato vulnerable al secuestro de la sesión.

(También está el HTTP Digest autenticación de acceso, pero no sin sus propios problemas -. Pero CouchDB no apoyaron la última vez que revisé todos modos)

Lo que debe hacer es utilizar siempre HTTPS para cualquier CouchDB autenticado acceso con cualquier red involucrada, excepto tal vez la red 127.0.0.0.

(Y sí, casi todos los ejemplos en la web y en los libros muestran el uso de la autenticación básica o una galleta a través de HTTP que en mi opinión es un desastre a punto de ocurrir.)

+0

Gracias, me dedico a usar HTTPS y para pequeñas aplicaciones donde la seguridad no es un gran problema Supongo que administrar mis administradores de base de datos y mis lectores (lectores) para que nunca se usen las credenciales de administración del servidor es una buena solución ? – Arnaud

2

partir de la versión 1.1 , CouchDB, admite el acceso API a través de HTTPS. En lugar de usar un proxy HTTPS, puede usar HTTPS directamente, protegiendo las contraseñas transmitidas a través del cable. Consulte el Feature Guide para 1.1.

2

Usar Https es la respuesta correcta.

Agregaré una aclaración sobre la importancia de calcular un hash en el lado del servidor. El hash es una función unidireccional que transforma la entrada en el valor clave almacenado en el servidor. Si alguien piratea el servidor y obtiene la entrada hash (valor clave), no podrá deducir el valor de entrada para suplantarlo.

Si calcula el valor de la clave en el lado del cliente y no se realiza ninguna transformación en el servidor, es equivalente a almacenar las contraseñas en texto sin cifrar. Alguien que logró obtener una copia del valor clave almacenado en el servidor puede suplantarlo fácilmente simplemente enviando el valor clave.

Por lo tanto, para proteger la base de datos de contraseñas se requiere una función de una vía criptográficamente segura (por ejemplo, shasha256) con una semilla sal/aleatoria en la contraseña enviada.

Ofuscar la contraseña enviada al hash, además de hash en el lado del servidor, no ayudará a silenciar si el valor hash enviado es siempre el mismo. Sin embargo, espiar los datos enviados a través de una conexión SSL no es trivial.

Sin embargo, hay un beneficio significativo para la contraseña hash en el lado del cliente. Un ataque de fuerza bruta en el servidor tratando de adivinar la contraseña usando un diccionario de contraseñas común sería inútil porque el hashing en el lado del cliente aleatorizó la contraseña.

Podemos agregar algo de sal al hash para evitar el uso del diccionario de contraseñas hash. Cuando el usuario escribió su identificación de usuario, solicite el valor de sal específico del usuario al servidor. A continuación, utilice el valor devuelto sal o semilla de hash para generar la contraseña hash en el lado del cliente.

La adivinación de contraseñas de fuerza bruta puede verse obstaculizada en el lado del servidor al aumentar el intervalo de tiempo entre reintentos. Pero esto generalmente funciona para una conexión específica. El atacante puede volver a conectarse después de cada dos intentos. Luego se requiere realizar un seguimiento de las direcciones IP para reconocer ese tipo de ataques.