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.
Respuestas:
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.
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:
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 .
fuente
¡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.
fuente
Diciendo:
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.
fuente
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:
(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:
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!")
fuente
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.
fuente
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.
fuente