security - portable - ¿Un protocolo de inicio de sesión simple, seguro medio?
ssh secure shell client portable (5)
SASL es un mecanismo de autenticación segura. El soporte para SASL se proporciona en las bibliotecas estándar de Java para versiones 1.5+.
Pregunté aquí sobre un protocolo que se me pidió que implementara, y qué tan seguro era. Desde el principio, parecía claro que era una mierda. Siendo así, pregunto:
¿Pueden apuntarme a algún protocolo de inicio de sesión muy simple (soy nulo en los sistemas de criptografía)? Estoy desarrollando tanto el servidor como el lado cliente de la aplicación y tengo mi propio sistema de mensajería, por lo que tengo suficiente libertad.
Solo 2 características especiales para sus sugerencias.
Simple: la red que esta aplicación va a ejecutar no es especialmente insegura y solo quiero evitar el envío de la contraseña en texto plano
Si es posible, no un intercambio de mensajes demasiado largo. Cuanto más corto, mejor.
Si su protocolo se ejecuta en TCP, puede escribir la autenticación en claro y luego ajustar la comunicación con SSL. Por ejemplo, si está utilizando el puerto 1234 para su protocolo, puede cerrar ese puerto en el servidor y dejar que los clientes lo hagan con SSH. Esto se puede hacer mediante programación y es una solución muy común.
Si su protocolo se ejecuta a través de HTTP, puede hacerlo de forma estándar utilizando HTTPS. Por ejemplo, la Autenticación básica a través de HTTPS es lo suficientemente segura para las necesidades que especificó.
Por otro lado, si nunca desea enviar la contraseña por cable, debe realizar una autenticación de respuesta de desafío.
- El servidor envía una cadena aleatoria
- El cliente envía un hash de cadena aleatoria + contraseña
- El servidor verifica el hash.
Esto tiene la desventaja de que la contraseña va a estar disponible (encriptada en texto plano) en el servidor. Si no desea almacenar contraseñas en el servidor, debe volver a mi primer ejemplo.
Verifique la Autenticación de Respuesta al Desafío
- El servidor incluye una cadena de desafío aleatorio en el formulario de inicio de sesión
- Cuando inicia sesión, javascript modifica la contraseña y luego la combina con el desafío
- El servidor realiza entonces la misma comprobación (su base de datos debe almacenar las contraseñas hash, pero este método le impide usar efectivamente una sal para ese hash, ya que tendría que transmitir esto)
El protocolo de tres pasos sería útil. Básicamente, se reduce a:
- La persona A cifra su contraseña y la envía a la persona B.
- La persona B encripta la contraseña encriptada y la envía a la persona A.
- La persona A lo descifra y lo envía de vuelta.
- La persona B lo descifra y obtiene la contraseña en texto plano.
De esta forma, la contraseña nunca se envía en texto llano, como tampoco lo son las claves de cifrado. También es un protocolo relativamente rápido, ya que depende (presumiblemente) del cifrado simétrico, que es muy rápido.
Almacenar el hash de contraseña en la base de datos no es seguro de manera óptima en caso de que los contenidos de la base de datos entren en manos no autorizadas. No hay forma de revertir el hash directamente, pero hay dictinonaries en línea (como aquí ) para revertir palabras hash (pass).
En DB, debes almacenar algo como:
md5(login_name + domain_or_appname_salt + password);
La sal en el medio evita muchas formas de ataques de diccionario.
En el lado de los clientes (en el navegador) tendría un formulario de inicio de sesión con nombre de usuario y contraseña. Una pequeña porción de javascript calificaría el userame + app_salt_ y la contraseña, de modo que solo el nombre de usuario y el hash generado se envían al servidor.
Ahora, la contraseña de texto plano nunca se enviará al servidor en texto sin formato. Por lo tanto, no debería tener que confiar en HTTPS aquí.
La misma técnica se puede utilizar en el formulario de actualización de contraseña. Por lo tanto, el servidor nunca sabe la contraseña de texto simple.
Espero que hayas obtenido algo de inspiración de esta y otras respuestas.
Happy Hacking!
Huibert