Si creo un inicio de sesión para una aplicación que tiene un riesgo de seguridad medio a bajo (en otras palabras, no es una aplicación bancaria ni nada), ¿es aceptable para mí verificar una contraseña ingresada por el usuario simplemente diciendo algo como:

if(enteredPassword == verifiedPassword)
     SendToRestrictedArea();
else
     DisplayPasswordUnknownMessage();

Parece fácil ser efectivo, pero ciertamente no me importaría si eso fuera todo lo que se requería. ¿Es suficiente una simple verificación del combo de nombre de usuario / contraseña?

Actualización: el proyecto en particular es un servicio web, la verificación es completamente del lado del servidor y no es de código abierto. ¿El dominio cambia cómo tratarías esto?

No sin SSL

Esto no es seguro si la contraseña se envía a través de la red en texto sin formato. Hashing la contraseña en el lado del servidor tampoco es seguro si la contraseña se envía a través de la red en texto sin formato.

Dado que la <input type="password"/>etiqueta HTML envía su contenido en texto plano, esto será un problema sin importar cómo almacene la contraseña en el servidor, a menos que su sitio web use SSL para transmitir la contraseña.

(La autenticación HTTP, que aparece un cuadro de diálogo en el navegador que solicita una contraseña, puede o no ser texto claro, dependiendo de los mecanismos de autenticación que el servidor y el navegador tengan en común. De modo que podría ser una forma de evitar esto sin usar SSL.)

No si los administradores del sitio son sospechosos

Ahora, suponiendo que esté utilizando HTTPS para hacer el sitio web, esto podría ser seguro si confía en los administradores de su sitio (que pueden leer contraseñas de texto sin formato) y otras personas que tienen acceso a la máquina para comportarse correctamente. Ahora, puede ser obvio que pueden hacer lo que quieran con su sitio web (ya que lo administran), pero si pueden leer la contraseña, también pueden usar los pares de inicio de sesión / contraseña robados en los sitios de otras personas.

Una forma que mantiene las contraseñas seguras del administrador

Una forma segura de almacenar y verificar contraseñas es la siguiente:

def change_password user, new_password
  salt = random(65536).to_s(16) #will be 4 characters long
  password_hash = salt + hash(salt + new_password)
  store(user,password_hash)
end

def does_password_match? user, entered_password
  correct_password_hash = retrieve(user)
  salt = correct_password_hash[0...4]
  entered_password_hash = salt + hash(salt + entered_password)
  return correct_password_hash == entered_password_hash
end

Para la función hash, intente usar algo fuerte y algo que todavía no tenga buenas tablas de arco iris en la naturaleza. Puede cambiar la longitud de la sal si es necesario trabajar alrededor de las mesas de arcoiris.

Dependiendo del entorno en el que se encuentre, la variabilidad en la latencia de su red y si los nombres de usuario deben ser conocidos públicamente, es posible que desee tener otro cálculo de ruta de código hash('0000'+entered_password)si el usuario no existe, para evitar que los atacantes determinar qué nombres de usuario son válidos en función del tiempo que lleva determinar que la contraseña es incorrecta.

Eso sugeriría que mantiene las contraseñas en texto abierto, lo cual es un no-no, incluso en escenarios de baja seguridad.

Deberías tener:

if(hash(enteredPassword) == storedHash)

Puede usar hash simple como, por ejemplo, MD5

Estoy de acuerdo con aquellos que sugieren el hash, pero también hay una rueda que estás reinventando aquí. Dependiendo de la plataforma, probablemente pueda encontrar una herramienta de gestión de roles / usuarios que cubra todas las cosas de gestión de usuarios de manera segura sin necesidad de mucha intervención de su parte.

La seguridad es un tema muy delicado, particularmente porque debe haber un equilibrio entre incomodar a sus usuarios y asegurarse de que su información esté segura. Por lo general, la fórmula de cuánta seguridad necesita depende de la importancia de los datos. En breve:

isSecuritySufficient = effortToBreak > rewardForBreaking

Un malentendido común sobre las personas que hacen cosas malas es lo que buscan. La mayoría de ellos están fuera para destruir la confianza . Siempre debe hacer todo lo posible para proteger la confianza de sus usuarios. Parte de eso es hacer su debida diligencia para asegurarse de que su identidad esté segura. Puede que les importen menos los datos que almacenan, pero les importa su identidad, incluso en el umbral de seguridad más bajo.

Hay varias opciones de bajo costo (para implementar e impactar al usuario) disponibles. Uno de ellos es descifrar la contraseña como mínimo. Cualquier servicio que almacene algo tan sensible como una contraseña en texto sin formato merece la vergüenza de ser pirateado.

Principios generales para la protección de contraseña

• Nunca almacene contraseñas en texto plano
• Hash utilizando una función de hash segura como SHA-1 o incluso SHA-512 (incluso MD5 es demasiado fácil de encontrar un hash coincidente)
• Use una aplicación de valor de sal. La sal es bytes aleatorios, ya sea agregados a una contraseña para que sea más difícil de adivinar. La sal debe generarse en tiempo de ejecución y usar información sobre la máquina como valor de semilla en lugar de almacenarse y referenciarse de alguna manera.
• Use un valor de sal específico del usuario. Use esto junto con su aplicación de sal.
• Cifre todas las solicitudes de autenticación que pasan por una red. Eso significa usar SSL para aplicaciones web.

Dado que usaría SSL para la autenticación, como mínimo desea cifrar todas las páginas que se ocupan también de la cuenta del usuario. Esto permite que se proteja la mayor parte de la identidad del usuario como sea posible.

Una nota sobre la administración de contraseñas : los usuarios olvidarán su contraseña de vez en cuando. Lo peor que puede hacer es enviarles su contraseña en un correo electrónico. Si implementa los principios descritos anteriormente, no podrá hacerlo de todos modos. Es mucho mejor proporcionar una forma de restablecer su contraseña utilizando un enlace enviado a su dirección de correo electrónico registrada. Ese enlace de reinicio tendrá un código de uso único para garantizar que la persona que accede a la página sea ella.

Eso está bien a menos que la contraseña se use para otra cosa. Todavía existe el riesgo de que el usuario decida que puede reutilizar la contraseña, por lo que sería aún mejor con:

if(hash(enteredPassword) == hashOfValidPassword)

Si es para usted o para alguien que sabe que la contraseña está almacenada en texto plano, entonces está bien.

¿Está disponible el código fuente? Incluso si no, estoy bastante seguro de que la contraseña se puede encontrar en las instrucciones de la máquina en caso de que el binario esté disponible. Recomendaría hacer una suma de comprobación y comparar eso en su lugar.

Nunca pase por alto la seguridad, incluso si no es muy importante en su opinión.

Absolutamente no. Eche un vistazo a esto , describe cómo los hackers piratearon un sitio web de seguridad. Tu plan te tendría como el eslabón más débil de la cadena.

Se ha observado en un par de respuestas que no debe almacenar la contraseña en sí, sino un hash, y debe usar SSL.

Usted puede decir, ¿cuál es el gran problema? Si mi aplicación es pirateada, eso es de poca preocupación. Bueno, es un patrón bastante común para los usuarios reutilizar la misma contraseña en todos los sitios. Si un hacker piratea su sitio y obtiene acceso a las contraseñas de los usuarios, el hacker podría hacerse pasar por muchos de esos usuarios en otros sitios de mayor importancia para esos usuarios. Por lo tanto, piratear su sitio podría ser el primer paso para que un hacker obtenga acceso a la información bancaria de los usuarios.

Y simplemente descifrar la contraseña no es suficiente. Necesitas picadillo con sal. Los hackers tienen tablas de búsqueda de hash inverso, por lo que para un hash determinado, pueden encontrar una contraseña coincidente.

Si elige no implementar esta función, debe informar a los usuarios de esta falta de seguridad, alentándolos a que no usen la misma contraseña que usan en otros lugares.

Mientras este sea el lado del servidor ... Entonces sí.

Si desea un poco más de seguridad, vaya a https y cifre \ hash la contraseña en la base de datos.