¿Cómo garantizar que la contraseña esté oculta en el servidor?

Usted plantea varios problemas.

Confianza del servidor

Nunca sabes qué hará el servidor con tu contraseña una vez que la envíes

Reutilización de contraseña

usted puede evitar la reutilización de la contraseña: no use la misma contraseña en varios lugares.

Hashing

Si tuviera que descifrar la contraseña antes de enviarla al servidor, la contraseña se convertiría en la contraseña. Si el servidor almacenara eso y fuera leído por un atacante, podría iniciar sesión con él. No necesita la contraseña original, ya que el servidor comprueba el hash. Evitaría el uso de la contraseña en diferentes sitios web, pero la mejor medida contra eso es no reutilizar las contraseñas.

Un protocolo que funcionará en esta situación es un esquema de desafío-respuesta. El servidor podría enviar un desafío al cliente, el cliente podría hacer frente al desafío con un protocolo de hashing con clave (como HMAC + SHA1) y enviarlo al servidor. Sin embargo, el servidor todavía necesita la contraseña para verificar el hash, por lo que debe almacenarse.

Si desea un esquema en el que no haya un secreto compartido entre el cliente y el servidor, busque el cifrado asimétrico. Podría darle al servidor su clave pública, y pedirle que verifique quién es usted cifrando un nonce con la clave privada. Puede usar SSL para esto, con certificados de cliente.

A menos que el proveedor de servicios le permita ver la base de datos, no, no hay forma de garantizarla. Esto ha demostrado ser un riesgo en el pasado y, sin duda, lo volverá a hacer.

No puede hacer mucho en este escenario antes de que el servidor realice una pre-hash de su contraseña, ya que básicamente hace que su contraseña pre-hash sea el objetivo de que su contraseña esté en un entorno en el que no se haya realizado la hash previa. Su enlace a la pregunta del lado del servidor / del lado del cliente responde bastante bien a esto.

En su lugar, concéntrese menos en una solución técnica y más en una contractual: exija a los proveedores que usen las contraseñas de hash e incluya cláusulas de penalización. El derecho a auditar es un requisito útil.

No creo que haya una forma práctica de probar un servidor para saber que solo almacena hashes de tu contraseña, pero puedo pensar en una teórica:

Dadas las colisiones de hash conocidas para los algoritmos de hash comunes (MD5, SHA1), puedes probar un servidor para almacenar contraseñas de hash si te autentica usando cualquiera de un par en una colisión de hash.

Ejemplo: Digamos que "abc" y "xyz" tienen hashes MD5 0123456789ABCDEF (obviamente eso no es cierto). Puede verificar que el servidor utiliza hashes MD5 si puede iniciar sesión con "abc" y "xyz" como contraseñas.

Pero esto es inútil en la práctica por varias razones:

• Fallaría la prueba si el servidor elimina correctamente sus hashes (es decir, hash ("abc") = hash ("xyz") pero hash ("abc" + sal)! = hash ("xyz" + sal)
• AFAIK no hay colisiones de hash conocidas para SHA1, que es de uso común.
• Sería aún más difícil obtener una colisión de hash para los valores que cumplen con las restricciones de contraseña comunes (por ejemplo, las contraseñas solo pueden tener números y letras y tienen una longitud máxima)
• Incluso si el servidor almacena un hash de su contraseña para la autenticación, no confirma que el servidor tampoco esté almacenando su contraseña en texto plano en otro lugar (he visto que las contraseñas aparecen en los archivos de registro del sistema y web, base de datos registros de replicación, archivos de datos de sesión, etc.).

En la práctica, debe asumir que los sitios web lo están haciendo mal y, por lo tanto, no debe usar la misma contraseña para diferentes sitios web.

No puedes. El servidor puede hacer lo que quiera con los datos que le envíe. Incluso si se establece que los datos están seguros con él, no se puede decir si eso es realmente cierto. Entonces, o confías en el servidor que maneja tu contraseña de manera apropiada. O puede hacer sus propios arreglos y usar una contraseña diferente para cada sitio.

En el mejor de los casos, las contraseñas también son completamente diferentes entre sí, de modo que no se pueden extrapolar de una a otra (es decir, no hay prefijos / sufijos obvios). Puede usar un administrador de contraseñas para generar y recordar esas contraseñas. Y como muchos de ellos están integrados en los navegadores, también ayudan a evitar el phishing, ya que las contraseñas almacenadas están asociadas a ciertos sitios / URL.

Si utiliza contraseñas diferentes para diferentes sitios web y / o un administrador de contraseñas para generar / recordar esas contraseñas, depende de su propia percepción de riesgo.

Personalmente uso un administrador de contraseñas y, por lo tanto, tengo una contraseña diferente para cada sitio. El inconveniente obvio es que solo puedo iniciar sesión en un par de sitios sin él, e. sol. cuando no estoy en mi máquina Pero como uno de ellos también es un proveedor de OpenID, me complace poder iniciar sesión en la Red de Intercambio de Pila también.

Sé que esta no es una respuesta que buscó, pero del usuario POV no tiene muchas opciones, ¿iniciar sesión o no iniciar sesión? Sin embargo, ¿por qué no usar una contraseña única en cada sitio y almacenarlas en la aplicación de llavero?

Recordar la contraseña para cada inicio de sesión es, seamos serios, no es realmente una opción hoy (casi todos los sitios requieren registro y registro). Sin embargo, si usa una aplicación de llavero, solo necesita recordar la contraseña maestra. El inconveniente es, por supuesto, un único punto de falla (pero, por supuesto, lo mismo se aplica al uso de la misma contraseña una y otra vez en todas partes).

Una de estas aplicaciones es keepass

¿Cómo realiza un seguimiento de todas sus contraseñas? - Q en SU.stackexchange

Una forma de determinar cómo un proveedor almacena su contraseña es "olvidar" su contraseña. En un sitio correctamente configurado, incluso el administrador no debería poder descubrir su contraseña, ya que lo único que se almacena es el hash de la contraseña.

Casi todos los sitios que permiten a los usuarios crear una cuenta ofrecen un mecanismo para recuperar el acceso a esas cuentas en caso de que un usuario pierda u olvide su contraseña. Un sitio web correctamente configurado lo desafiará a responder preguntas de seguridad y luego restablecer su contraseña, mientras que un sitio definitivamente dañado le dirá su contraseña.

No 100% a prueba de errores, muchos falsos negativos pero cero falsos positivos.

No puede, y es por eso que OpenID existe, porque como usuario solo tiene dos opciones si va a utilizar sitios que requieren iniciar sesión sin él: 1) confíe en ellos, 2) use una contraseña única para cada sitio.

No puede estar seguro de que el servidor tenga la contraseña antes de almacenarla. @Rory señala que es un requisito razonable que puede intentar cumplir por medios no informáticos, pero no es realista creer que todos los servidores harán las cosas correctamente. La solución es no usar la misma contraseña (o contraseñas que se pueden adivinar entre sí) para dos sitios distintos.

Las contraseñas "distintas" se pueden generar a partir de una "contraseña maestra" con una función criptográfica hash (p. ej., hash la concatenación del nombre del sitio y la contraseña maestra; hay formas de fallar, pero el principio es correcto) . El software existe para eso. O puede almacenar contraseñas generadas aleatoriamente en un archivo, cifradas simétricamente con una contraseña maestra. El software también existe para eso. Podría tomar varias formas (un archivo cifrado, una conexión SSH a un servidor que aloja el archivo de contraseña, una extensión del navegador que utiliza una función de cifrado criptográfico, ...).

De cualquier manera, es difícil hacerlo solo en tu cabeza (¡maldita ese cerebro biológico!), porque requiere hacer cálculos extensos y / o recordar muchos elementos aleatorios.

Sin embargo, afirmo que el escenario "hazlo en tu cerebro" es no realista . ¿Por qué querrías calcular todo en tu cerebro? Esto se debe a que la máquina local en la que está a punto de escribir la contraseña no tiene instalado el software necesario; Esa es una máquina aleatoria en, digamos, un cibercafé. Hey, espera ! ¿Está a punto de escribir su contraseña en una máquina de cibercafé ? ¿Una máquina que podría estar llena de registradores clave y otros programas maliciosos? Ahora es una mala idea. No es necesario un servidor mal escrito, en estas condiciones: usted es muy bueno haciendo cosas inseguras por usted mismo.

Por lo tanto, la necesidad de un esquema de almacenamiento / derivación de contraseña que pueda ejecutarse "en su cerebro" es en realidad una necesidad de poder hacer algo que es bastante estúpido, desde el punto de vista de la seguridad. Así que no lo hagas. Si no puede acceder a un almacenamiento seguro o generador para las contraseñas por sitio, entonces no está en un contexto en el que pueda usar dicha contraseña de manera segura.

Si entiendo su pregunta correctamente, entonces:

1. No hay manera de garantizarlo. Supongo que podría escribir una extensión de navegador del lado del cliente (¿quizás una inyección de javascript?) Que podría modificar el valor de cada cuadro de texto de contraseña justo antes de enviarlo. Todavía puedo ver formas en que podría tener problemas. Pero sería un comienzo.
2. Hay una solución más sencilla que empleé: no usar una contraseña diferente para cada sitio, pero usar una contraseña diferente para ... ¿cómo colocarla ... el nivel de seguridad de un sitio? Es decir, use la misma contraseña para todos los sitios en los que no le importa si se la roban (como blogs, tal vez una red de intercambio, etc.), pero use contraseñas individuales para los sitios que realmente son sensibles a la seguridad (como sitios web de bancos, PayPal) , etc.). De esa manera, aún tiene varias contraseñas para recordar, pero debe ser una cantidad manejable, y se puede hacer aún más fácil de recordar mediante el uso de frases de contraseña.

  

utilizado en otros sitios.

Utilice una contraseña única por sitio, el problema resuelto diría.

El mejor método que he visto para proteger contraseñas de diferentes sitios es simplemente usar un administrador de contraseñas con una contraseña generada.

Otro método que he visto es recordar una sola contraseña y codificarla con el dominio del sitio como la sal. El hash se puede hacer con una amplia variedad de servicios en línea, solo elija uno que admita el uso de una sal y, preferiblemente, que no use MD5. La mayoría de la gente pensaría que estabas usando una contraseña generada al azar antes de molestarte en romper el hash.

Si bien generalmente es imposible saber si una contraseña está almacenada en texto sin formato o no, verificar el método de recuperación de la contraseña puede darle algunas pistas. Si es posible recuperar su contraseña anterior en un correo electrónico, entonces su contraseña se almacenará en texto sin formato (o un cifrado reversible).

el cifrado o el hashing del lado del cliente generalmente no es efectivo porque el código del lado del cliente y los secretos que utiliza están disponibles para que cualquiera pueda inspeccionarlos: un atacante puede ver la fuente, pasar el Javascript con Firebug, etc.

No puedes saber qué hace el servidor con las contraseñas y si las hasheado correctamente, por lo que vale la pena estar paranoico con tus contraseñas. Recomendaría escribir sus secretos importantes y guardarlos en su billetera (sugerencias de Bruce Schneier - [1]) o usar una aplicación móvil como 1Passwd.

[1] enlace