Cómo asegurar a los usuarios que el sitio web y las contraseñas son seguras [cerrado]

15

En sitios web confiables siempre veo reclamos como "Todos los datos están encriptados" o "Todas las contraseñas están encriptadas usando encriptación de 128 bits", etc. Sin embargo, nunca me he encontrado con un reclamo como "Todas las contraseñas están cifradas".

En mi sitio web, almacenaré todas las contraseñas de los usuarios en una base de datos después de usar el hash SHA-512 (muy probablemente) con una sal aleatoria. Quiero agregar un fragmento que asegure a los usuarios que sus contraseñas son seguras para que no se les impida usar mi sitio web porque requiere una contraseña. Quiero que los usuarios se sientan seguros, pero no creo que todos sepan qué es el hashing.

MI PREGUNTA: ¿Está bien proporcionar un mensaje que diga que "Todas las contraseñas están encriptadas y seguras", ya que no creo que el usuario promedio sepa cuál es la diferencia entre el hash y el encriptado, y es más probable que se sienta seguro solo porque vea la palabra de confort "encriptación"? ¿O hay un mensaje alternativo que debería proporcionar?

En una nota al margen, soy nuevo en el cifrado y el hash de contraseñas y me preguntaba si esto sería lo suficientemente seguro por ahora cuando inicie mi sitio. No quiero decirles a los usuarios que es seguro si no lo es. Cualquier información sería muy apreciada. Gracias.

usuario2698818
fuente
77
Personalmente, no me preocuparía demasiado por la comunicación: escriba una descripción técnica de lo que hace, enterrado en algún lugar de las Preguntas frecuentes donde los expertos técnicos lo encontrarán. A nadie más realmente no le importa de todos modos. Más importante aún: asegúrese de hacer lo correcto (eso es difícil si es nuevo, ¡pero al menos lo está intentando!). No construyas tu propio hash, usa algo como bcrypt .
Joachim Sauer
44
Bueno, lo correcto es federar el inicio de sesión y no molestar a los usuarios con otro nombre de usuario y contraseña.
Jan Hudec
1
OpenID es bueno, pero el nombre de usuario / contraseña también está bien. No creo que su problema sea persuadir a los usuarios de que su sitio es seguro. Como no tienes experiencia, es como prometer algo que no tienes. Simplemente aplique estándares comunes: no evitará que vengan hackers profesionales, pero nadie puede culparlo tampoco.
Hoàng Long
3
@coredump De hecho. Usar SHA-512 para el hashing de contraseñas simplemente no es bueno. No está bien".
Thomas
3
Probablemente valdría la pena hacer cualquier pregunta de seguimiento sobre Seguridad de la Información para asegurarme de que obtenga el mejor consejo actualizado. (Eso no significa que esté recibiendo malos consejos aquí, solo que no somos necesariamente profesionales de seguridad).
ChrisF

Respuestas:

22
  1. A los usuarios no les importa.

    La única vez que les importa es cuando alguien retira el dinero de su cuenta bancaria y parece que tiene un enlace que unos días antes, alguien obtuvo acceso completo a su base de datos.

  2. En casi todos los casos que he visto tales mensajes, fueron engañosos. El más divertido fue en un sitio web con etiquetas de estilo "seguro de grado militar" en cada página. Hubo una alerta que decía que el certificado HTTP no es válido. Hubo una inyección SQL en el formulario de inicio de sesión. Unas semanas después, el sitio web fue pirateado y luego desapareció para siempre.

    Dejo de contar la cantidad de sitios web que afirman que mantienen la información segura, mientras tengo un formulario de "Recuperar mi contraseña", que en realidad envía la contraseña original por correo electrónico.

    Es como esas etiquetas de "W3C válido XHTML". ¿Por qué se suelen poner en sitios web donde incluso una página de inicio contiene al menos docenas de errores y códigos similares <DIV COLOR='red'>?

Si aún desea tranquilizar a los usuarios, puede poner algo como:

Sus contraseñas se mantienen seguras. Recuerde que no podemos ver su contraseña y nunca le enviaremos un correo electrónico pidiéndole que la proporcione.

Pero, francamente, el formulario "Restablecer mi contraseña" que reemplaza el "Olvidé mi contraseña; enviármelo por correo electrónico" es mucho más tranquilizador que cualquier palabra.

Sugerencias de los diferentes comentarios:

  • No reinventes la rueda: usa OpenID. De esta manera, ni siquiera almacena los hashes.

    Fuente: comentario de Jan Hudec .

  • Como eres estudiante, abre el código de tu proyecto. Dado que su preocupación es: "No quiero que los usuarios piensen que sus contraseñas no son seguras porque algún niño en la escuela lo diseñó"., no hay nada más tranquilizador que poder verificar, al leer el código fuente, que fue escrito por un desarrollador hábil que se preocupa por la seguridad.

    Fuente: comentario de Jan Doggen .

Arseni Mourzenko
fuente
Gracias por el aporte chicos. El problema es que soy un estudiante que diseña un servicio para mi universidad. No quiero que los usuarios piensen que sus contraseñas no son seguras porque algún niño en la escuela lo diseñó. He analizado varios métodos diferentes, incluido bcrypt, y no he decidido cuál usar. Supongo que ahora será lo suficientemente seguro y si mucha gente comienza a usarlo, puedo agregarlo si es necesario. Solo estoy trabajando para sacarlo por ahora. Gracias de nuevo.
user2698818
3
@ user2698818 Lo que debe hacer es diseñar la seguridad, luego publicar una pregunta describiéndola en detalle y preguntando 'es esto seguro (suficiente)'. La buena seguridad puede ser completamente pública.
Jan Doggen
@ usuario2698818: ok. Edité mi respuesta.
Arseni Mourzenko
66
@ JanDoggen: bueno, lo que debería estar haciendo es usar un sistema de seguridad existente que alguien más diseñó y preguntó "¿es lo suficientemente seguro?". Preferiblemente uno en el que esa pregunta se haya mantenido durante bastante tiempo y haya recibido la atención de varios expertos en los campos ;-)
Joachim Sauer
12

¡No almacene contraseñas en primer lugar! Siga el ejemplo de Stack Exchange y permita que los usuarios inicien sesión con su identidad en otro sitio que proporcione autenticación a través de OpenID . Las implementaciones están disponibles gratuitamente para los marcos web más comunes.

O posiblemente cualquier otro protocolo. Si es un proyecto interno para alguna institución (como sugiere su comentario sobre la otra respuesta), es casi seguro que ya haya un LDAP, Kerberos (Windows Active Directory también se basa en esos dos; Apache admite la autenticación HTTP contra ellos) o algunos dicho servicio para iniciar sesión en la computadora. Solo conéctate a eso.

Esto le ahorra el almacenamiento de información sensible (que lo más probable que todavía tiene que permisos de almacén, pero no es que crítico) y los usuarios de tener que recordar otro nombre de usuario y contraseña, por lo general de ganar-ganar.

Jan Hudec
fuente
1
Dígame qué sitios ha creado para poder evitarlos si considera que los permisos no son críticos para la seguridad.
orlp
1
¿Qué pasa si el requisito es almacenar contraseñas? Además, la pregunta se refiere específicamente a almacenarlos.
Piotr Kula
3
@ppumkin: Hay muchas preguntas del tipo "cómo uso X para hacer Y", donde la mejor respuesta es "usa Z". Si no está de acuerdo, simplemente proporcione una mejor respuesta ;-).
Jan Hudec
3
@ppumkin Para usar una analogía: "Estoy tratando de romper una piedra con el puño, ¿qué guantes debo usar?" Comprueba si conocen los cinceles antes de ofrecer 19º Guanteletes de Caballería Alemanes
deworde
1
Evitaría ser demasiado rápido para sugerir OpenID. Sí, es genial, pero generalmente funciona mejor si admite múltiples proveedores de OpenID / OAuth. Hay muchos foros de tecnología, blogs, preguntas y respuestas, etc., donde debe iniciar sesión a través del proveedor de OID de Facebook y no puede usar ningún otro. Estoy en una red de trabajo que bloquea los dominios de Facebook al por mayor, por lo que no puedo trabajar con esos sitios. Si va a admitir OID y solo va a utilizar uno por ahora, elija un proveedor que sea popular entre su público objetivo y que sea poco probable que un administrador de sistemas lo bloquee. Google y Windows Live son buenas opciones.
KeithS
2

Diciendo:

"Esto es seguro".

es un juicio personal que usted hace sobre ciertos hechos o procesos tecnológicos, y este juicio está limitado por lo que usted mismo sabe sobre la seguridad en ese momento. Pero, ¿puede garantizar sin lugar a dudas que su cifrado, método de almacenamiento, etc. resistirá cualquier tipo de ataque, incluso los que no conoce o aún no conoce?

Significado: Esta declaración está en peligro de estar desactualizada, tal vez incluso sin que usted sea consciente de ello.

Por lo tanto, tiendo a estar de acuerdo con el comentario anterior de @JoachimSauer: solo describa lo que hace, cómo guarda la información del usuario y les digo a los usuarios cómo se supone que esto hace que su servicio sea seguro. Luego, deje que los usuarios juzguen por sí mismos.

stakx
fuente
No, "Esto es seguro" no es una declaración "personal" o subjetiva, para no es como "es bonito" . En realidad es una declaración semánticamente vacía , sin especificar "en relación con qué" o "seguro de qué ataques" o "a qué nivel en qué contexto". Si su declaración completa consiste en "esto es seguro", no está actualizada antes de que termine de escribirla, y es muy probable que no se dé cuenta. Estoy de acuerdo, aunque en la última parte, se trata de detalles.
AviD
@AviD: Quizás leíste demasiado en mi elección específica de palabras. Sí, decir que algo "es seguro" sin dar más detalles no tiene sentido. Pero yo descanso convencido de que es también un criterio personal, porque no todos tienen exactamente el mismo sentido y demandas de "seguridad": Lo A encuentra lo suficientemente seguro como podría sentirse inseguro a B. Entonces, decir que algo "es seguro", sugiere que el persona que hace la declaración "lo encuentra seguro". Y ese no es un argumento con el mismo peso que dar a alguien los hechos relevantes y dejar que saquen su propia conclusión.
stakx
Correcto, "en relación con lo que" quise decir para qué requisitos, perfil de seguridad, riesgos, etc. Todavía no es un juicio personal, pero quizás lo que quiere decir con "personal" es lo que quiero decir con "contexto". "Seguro" es una métrica científica difícil, no un "sentimiento" suave y deslucido. Pero sí, como dices, no me digas que es "seguro", dime qué hiciste para que así sea.
AviD
@AviD: OK. No discutiré más el argumento, excepto por decir que la seguridad también es un sentimiento flojo. Por supuesto, es más que eso, pero cuando la pregunta se trata de "asegurar" a los usuarios (ver el título de la pregunta), al final, lo que cuenta es la sensación floja.
stakx
1

Realmente depende del contexto de su sitio web específico.

Por ejemplo, si este es un sitio web para consumidores, lo más probable es que a la mayoría de ellos solo les importen sus contraseñas (tal vez), información financiera / de salud (dependiendo) y su información privada como imágenes (jajaja, sí, claro ...) .

Si se trata de una aplicación empresarial, el nivel de seguridad de todo el sitio es relevante, no solo las contraseñas. Del mismo modo, depende de quiénes son sus usuarios objetivo: altamente técnicos / no tan técnicos, etc.

Todo este contexto define en gran medida lo que debe comunicar y qué nivel de seguridad se requiere.

Por ejemplo, para consumidores no técnicos, es suficiente tener algunos comentarios genéricos y simples, como:

Este sitio está construido utilizando técnicas de seguridad de vanguardia. Su contraseña siempre está encriptada, y nunca enviaremos sus fotos a la NSA.

(Y, como han dicho otros, es mejor que ni siquiera tenga contraseñas, use algún estándar como OpenId u OAuth).

Para negocios altamente técnicos, desearía tener una página completa de detalles técnicos y de procedimiento, tales como:

Hemos implementado un SDL (ciclo de vida de desarrollo seguro) completo en todo nuestro proceso de desarrollo e implementación.
...
Nuestra arquitectura de seguridad es ... Esto brinda los beneficios de ...
Aseguramos una codificación segura como ... por ... Realizamos estas y esas pruebas.
Nuestra criptografía incluye estos algoritmos ... y ... cumplimos con cualquier regulación de la industria que necesite, y estamos certificados para ...
Nuestra seguridad es verificada por este consultor externo independiente.
...
Para más detalles y para revisar nuestras políticas o para organizar una auditoría independiente, hable con el departamento de marketing.

Por supuesto, no desea dar demasiada información detallada, debe ser más sobre el proceso que las contraseñas en sí mismas ... Y, por supuesto, debe ser evidente que la realidad debería cumplir con lo que escriba allí , en cualquier contexto con el que esté tratando

Como se mencionó en una de las respuestas, a la mayoría de los usuarios no les importa, no entenderían lo que les diga, y aún así se registrarían de todos modos, incluso si usted dice que SI envía datos de usuario a la NSA.
Esto no es para ellos.
Estarían igualmente felices de no tener contraseñas, solo permítanme elegir mi nombre de usuario de la lista e iniciar sesión automáticamente.

Obviamente, esto es para el pequeño porcentaje que se preocupa : debe permitir que los usuarios inteligentes hagan lo correcto, brindarles la información que necesitan y otorgarles la educación que podrían pedir.
Si no lo hace, cuando eso salga mal, el otro 98% se despertará repentinamente y se enojará.
("Claro, sabía que no necesitaba una contraseña para ver mis fotos, ¡pero no pensé que nadie más pudiera verlas!")

Ávido
fuente
0

Si desea que su sistema sea seguro, la fortaleza del algoritmo de contraseña no tiene sentido: la mayoría de los piratas informáticos pueden descifrar las contraseñas en muy poco tiempo, especialmente si la contraseña elegida es pequeña o se compone de palabras genéricas que el pirata informático ya "descifró y almacenó". "usiong mesas de arcoiris y similares. Lea el artículo de ArsTechnica sobre descifrado de contraseñas para obtener más información.

Lo que debe hacer es asegurar a los usuarios que los malos no pueden llegar a sus problemas en primer lugar. Una empresa consciente de la seguridad para la que trabajaba tenía un sistema web de 3 niveles en el que los servidores web no estaban físicamente conectados a los servidores de la base de datos. Cuando mi jefe quería poner su sitio web y tener acceso directo al DB (código mal diseñado '', dijo nuff) le dijeron que no podía tenerlo, y cuando presionó ... le dijeron que no había cables entre ellos . Tuvo que diseñarlo para que pasara todas las solicitudes de datos a través de un servicio de nivel medio. Y esos servicios no solo estaban asegurados, sino que exponían una superficie mínima a los ataques y estaban bloqueados. Y el DB nunca expuso ninguna de sus tablas para leer, solo almacenó procedimientos que a su vez estaban bloqueados para que solo el servicio relevante tuviera acceso.

No fue tan malo codificar como podría pensar, una vez que conocía la arquitectura y la separación de cada nivel, fue bastante fácil codificarlo.

gbjbaanb
fuente
0

Puede desarrollar el sitio más seguro del planeta y tener una experiencia de usuario realmente pobre. Los usuarios asumirán que su sitio es inseguro.

Puedes construir el sitio menos seguro del planeta y tener una experiencia de usuario increíble. Los usuarios asumirán que su sitio es seguro. Al menos hasta que aparezca en las noticias de la tarde.

CodeART
fuente