Estoy usando HTTPS Everywhere en mi navegador para elegir versiones SSL de sitios web cuando están disponibles, pero muchos sitios no ofrecen una versión segura. ¿Es SSL la única opción viable para impedir la contraseña / borrar el rastreo de texto?
Si no desea enviar sus datos en texto sin formato, debe utilizar el cifrado, pero no siempre tiene que ser SSL. Por ejemplo, un sitio puede optar por realizar su propio cifrado en el nivel de la aplicación en lugar de simplemente usar SSL (aunque no puedo imaginar por qué alguien haría eso > _ <).
Sin embargo, si un sitio no ofrece este cifrado, no hay nada que pueda hacer para evitar enviar sus datos en texto sin formato. Después de todo, el sitio solo lo espera en texto plano. No puedes cambiar eso sin cambiar lo que el sitio espera.
Necesitas usar cifrado, incluso si no importa de qué tipo.
Hay otra cosa (probablemente bastante inútil) que puedes hacer que me viene a la mente, ya que me estás preguntando si hay otras opciones para defenderte contra el rastreo de contraseñas: las aplicaciones web podrían modificarse para que funcionen con hashes de contraseñas. que con las contraseñas de texto plano, como dijo @Oleksi. De esta forma, al menos, si ha rastreado una contraseña, tendrá que trabajar un poco antes de poder obtener la contraseña de texto sin formato.
Pero, por supuesto, usar el cifrado es mejor.
Es teóricamente posible obtener conexiones autenticadas por contraseña sin cifrado. Un protocolo putativo para eso comenzaría con un intercambio de claves autenticado por contraseña (como SRP ), que resulta en un secreto compartido, conocido por el cliente y el servidor, pero nadie más; y el cliente y el servidor se autenticarán mutuamente con respecto al conocimiento de la contraseña. El secreto compartido se usaría luego como clave en un algoritmo MAC , para mantener la integridad de los paquetes de datos intercambiados posteriormente. Y ahí está: autenticación de contraseña, pero sin cifrado, y aún está protegido contra ataques de diccionario en línea : no escuche nada sobre la contraseña, ni siquiera un valor de hash o equivalente que les permita probar contraseñas potenciales después; y esta propiedad se mantiene incluso cuando se enfrentan a atacantes activos , incluso a atacantes que se hacen pasar por el servidor o el cliente. Tal es la magia de los protocolos PAKE.
Por supuesto, ningún cifrado significa que los datos intercambiados posteriormente pueden ser inspeccionados por espías indiscretos; integridad se mantiene, no confidencialidad . Esto suele ser un problema por derecho propio.
(Sin embargo, no todos los problemas se resuelven con un protocolo de este tipo. Registro sería difícil de hacer sin filtrar a forasteros al menos una versión con hash de la contraseña.)
En la práctica , un protocolo criptográfico es "viable" solo en la medida en que sea implementado adecuadamente por todas las partes involucradas. La posibilidad teórica de un protocolo criptográfico que realiza la autenticación de contraseña sin cifrado no cambia el hecho de que, en este momento, los navegadores web no implementan eso. Los navegadores web implementan SSL (HTTPS). Por lo tanto, utilice SSL. Es la única forma razonablemente segura de manejar la autenticación de contraseña cuando el cliente es un navegador web que existe y se implementa ampliamente desde principios de 2013.
Lea otras preguntas en las etiquetas passwords encryption tls