tiempo - ver variables en consola javascript

Impedir que el usuario encuentre la contraseña a través de Firebug/Chrome Dev Tools (12)

Absolutamente no. No puede impedir que el usuario final manipule el DOM desde las herramientas del desarrollador o firebug.

El uso de cualquier truco del lado del cliente no puede impedir que el usuario haga eso. Hasta o a menos que el navegador restrinja que el usuario haga eso.

Para el campo de entrada del pasaporte:

<input type="text" required="" tabindex="2" class="std_textbox" placeholder="Enter your account password." id="pass" name="pass">

Cuando <input type="password"> se cambia a <input type="text"> La contraseña se revela. Esto puede ser riesgoso en sistemas que tienen contraseñas guardadas o generadas por los administradores de contraseñas.

¿Se puede usar el cifrado del lado del cliente aquí? ¿Cómo se puede implementar?

Bueno, no puedes.

Pero entonces otra vez . Por supuesto, hay una forma de evitar que el usuario nunca lo vea usando la Consola de desarrollador: nunca muestre el campo ENTRADA que tiene la contraseña.

La alternativa sería emular el comportamiento del campo para que parezca estar allí, pero no lo está. No he encontrado una solución técnicamente sólida todavía, pero podría encontrar un ejemplo de cómo se puede hacer: (actualizado) http://jsfiddle.net/858kef4h/

En este ejemplo, la idea es crear un pseudocampo basado en DIV que se vea como ENTRADA de contraseña y escuche las pulsaciones de teclas del usuario y guarde el valor en una variable de JavaScript

<div class="pwField"> <div class="pwData"></div> <div class="cursor"><div class="tfarea"></div></div> </div>

Este simple truco solo tiene tres variables de estado para la contraseña, el estado de enfoque y el área de texto oculta

var pw = "", bHasFocus = false, tfArea;

La clase "cursor" se activa / desactiva usando JavaScript para emular el cursor real

setInterval( function() { $(".cursor").toggleClass("blink"); },600);

Cuando se hace clic en el div, crea un área de texto en el lugar del cursor y se enfoca en él.

$(".pwField").on("click", function() { // enable cursor and create element if needed $(".pwField").addClass("active"); if(tfArea) { // if already created, just focus to the field tfArea.focus(); bHasFocus = true; return; } tfArea = document.createElement("textarea"); tfArea.value=""; $(".tfarea").append(tfArea); tfArea.focus(); bHasFocus = true; $(tfArea).on("blur", function() { // disable cursor and exit $(".pwField").removeClass("active"); bHasFocus = false; }); });

Luego puedes escuchar keyup / keydown y grabar los valores

$(document).keydown(function( ) { if(!bHasFocus) return; pw = tfArea.value; // print asterisks $(".pwData").html( asterisks( pw.length ) ); });

Y cuando esté listo para iniciar sesión, el valor está en la variable "pw".

Este TEXTAREA creado dinámicamente puede pasar desapercibido por los administradores de contraseñas automáticos, porque no es el tipo de ENTRADA: el campo que los Administradores de contraseñas esperan ver.

El usuario que edita el campo puede naturalmente inspeccionar el valor de este elemento utilizando las herramientas de Chrome Developer, pero el punto aquí es, si el administrador de PW no considera ese campo como una contraseña, no la está llenando con la contraseña de Usuario anterior.

No recomiendo usar esto, esto solo fue hecho por curiosidad. La idea era mostrar que, aunque no puede evitar que el usuario vea los elementos, aún puede ocultar el resultado a los administradores de contraseñas. Pero como dice el viejo refrán, "puedes engañar a algunos de ellos algunas veces, pero no a todos ellos todo el tiempo" .

La experiencia del usuario no es la misma que con la entrada estándar, pero podría mejorarse. Un problema también es que, aunque quisiera evitar que se muestre la contraseña, eso es lo que los usuarios realmente quieren. Es posible que deseen utilizar el Administrador de contraseñas. Pero en este caso estás fuera de suerte de todos modos.

También puede haber problemas con el clic, el enfoque y el desenfoque con diferentes navegadores, es posible que no funcionen con los dispositivos móviles como espera. Si alguna vez se usa este tipo de pirateo, deberías probarlo cuidadosamente. Podría usarse, si sabe exactamente qué tipo de navegadores están utilizando los usuarios y sabe que tienen habilitado JavaScript.

EDITAR: Probé el enfoque con algunos dispositivos móviles y pareció funcionar un poco, pero con el iPad, y noté que al colocar el área de texto oculta se creará un cursor visible y se cambiará el zoom, por lo que ahora se coloca el área de texto oculta dentro del pseudocursor DIV y el zoom debe seguirlo.

Como es del lado del cliente, no hay una manera real de prevenir esto. En términos de un modelo de seguridad: no podemos confiar en el cliente. Por otra parte, sin embargo, no hay una manera real de implementar esto de manera diferente sin el uso de un dispositivo de terceros.

Si está dispuesto a pasar por la molestia de contar con la asistencia de un dispositivo de terceros en la autenticación: haga que el sitio web genere y muestre una semilla aleatoria, pida al dispositivo que solicite la semilla y la contraseña para generar un hash, y autentíquese en el sitio con el hash Por supuesto, el hash seguirá siendo visible si utiliza un depurador web, pero al menos no tiene sentido almacenarlo / leerlo, ya que el hash será diferente para cada sesión. Por cierto, esto tampoco es completamente seguro, ya que este método es propenso a un ataque de texto simple elegido.

Felicitaciones si estás dispuesto a pasar por todos estos problemas sin embargo. Supongo que podría escribir una aplicación para que esto tenga una función de teléfono inteligente como dispositivo de terceros.

Como ya se dijo, tener una contraseña en un elemento de entrada permitirá al usuario revelar la contraseña fácilmente.

... Y como @Elyasin pregunta, realmente debería informarnos cuál es su caso de uso.

Al no tener en cuenta su caso de uso, supongamos que tiene un sitio web al que los usuarios pueden suscribirse por una tarifa y que no desea que varios usuarios compartan el inicio de sesión de una persona para pagar su tarifa de suscripción.

Puede usar la autenticación de cookies para verificar que un usuario esté suscrito a su sitio.

Cuando un usuario nuevo se suscriba, envíeles un correo electrónico con un enlace a una página de registro especial en su sitio web.
Cuando el usuario siga ese enlace, coloque una cookie en la computadora del usuario indicando que es un suscriptor válido.
Crea una página de destino en tu sitio. Esta página de destino leerá la cookie de la computadora del usuario y autentificará que es un suscriptor válido.
Todas las demás páginas de su sitio deben redirigir a los usuarios a la página de destino si esos usuarios no tienen la cookie de validación.
Dado que los usuarios no suscritos pueden ser redirigidos a la página de destino, puede ofrecerles que se conviertan en suscriptores en la página de destino.
Si la suscripción de un usuario suscrito ha caducado, quita la cookie de la computadora del usuario (ahora no suscrito) la próxima vez que visite su sitio. Como cualquier usuario no suscrito, los redirecciona a la página de destino.

Si bien es cierto que las cookies pueden ser interceptadas o robadas, por lo general está más allá de la capacidad del usuario ocasional para hacerlo.

Si desea mayor seguridad con las cookies, puede capturar la dirección IP de un usuario cuando se suscriben inicialmente. Luego, puede verificar que el usuario tiene una cookie de validación y también está accediendo desde la misma dirección IP de la que se suscribieron originalmente. Por supuesto, esto limita la suscripción a usar solo su dirección IP original para acceder a su sitio.

Creo que el problema al que se enfrenta es a varias personas que usan la misma computadora, y si un usuario guarda su contraseña en su sitio, cualquier otra persona que visite el sitio en la misma PC podrá manipular el campo para revelar la contraseña.

Una forma de evitar que esto suceda es deshabilitar el autocompletar. autocomplete="off" Coloque este código en el elemento de entrada e incluso si se guarda la contraseña, no debería aparecer. <input autocomplete="off" type="text" required="" tabindex="2" class="std_textbox" placeholder="Enter your account password." id="pass" name="pass">

Pros
No tiene que preocuparse por los usuarios que comparten computadoras, y las contraseñas se revelan en su mayor parte.
Contras
Los usuarios pueden pensar que sus contraseñas están guardadas (y aún pueden guardarlas), pero cuando llegan a su sitio, no aparecerán.
NOTA Esta no es la forma completa de evitar que los usuarios manipulen el formulario y recuperen las contraseñas de otros usuarios.

Como nota al margen, si el sitio no se actualiza después de ingresar una contraseña y un nombre de usuario, el navegador web no le pedirá que guarde la contraseña. Por ejemplo, usar una llamada ajax en lugar de enviar un formulario.

Puede usar JavaScript para borrar el texto dentro del campo de contraseña cuando se carga la página. Un mejor estilo sería agregar el campo cuando la página se cargue con JavaScript así: var x = document.createElement ("INPUT"); x.setAttribute ("tipo", "contraseña");

Una alternativa a autocomplete = "off" alternativa de autocompletar Implica generar un nombre desde el backend y usarlo como el nombre de los campos para que el autocompletar nunca sepa dónde colocar los datos guardados por los usuarios.

La premisa de esta pregunta es que la computadora cliente está comprometida y está siendo utilizada por alguien que no debería tener acceso. Si se asume que se está utilizando un administrador de contraseñas (como el de Chrome) que no requiere una contraseña maestra antes de que se complete automáticamente cada formulario de inicio de sesión, no hay nada que pueda hacer para evitar que el atacante obtenga acceso a las cuentas.

Está intentando resolver un problema en el nivel de aplicación cuando el problema de acceso es más profundo que eso.

Supongamos que Bob se olvida de cerrar sesión en su computadora. Un atacante (Eve) se topa con su sesión abierta de Windows y quiere obtener acceso a su cuenta de PayPal. Bob usa un administrador de contraseñas para varias cuentas, incluidas sus cuentas de Gmail, Paypal y Reddit. Supongamos que PayPal tomó precauciones a nivel de aplicación para evitar que Eve aprendiera la contraseña de Bob del autocompletador de un administrador de contraseñas. Eve piensa que solo podrá tener el control de la cuenta de PayPal de Bob durante el tiempo que Bob deba devolver. Pero entonces, Eve se da cuenta de la función de enlace de restablecimiento de contraseña de PayPal. La cuenta de correo electrónico de Bob también está comprometida porque su contraseña también se encuentra en el administrador de contraseñas. Con acceso a la cuenta de correo electrónico de Bob, Eve puede restablecer cualquiera de las contraseñas de Bob que quiera. Ella podía mantener el acceso instalando un keylogger en la computadora de Bob.

En pocas palabras, las preocupaciones de seguridad que está tratando de resolver están más allá de su capacidad de abordar (suponiendo un modelo de contraseña de nombre de usuario convencional). Incluso sin asumir nada sobre su aplicación, Eve tiene acceso físico a la computadora de Bob, por lo que podría comprometerla de muchas maneras.

Si hace que sus usuarios utilicen la autenticación de dos factores (envíeles un código por mensaje de texto a través de Twilio), haga que lleven consigo una llave USB de hardware, etc ... aumentará la seguridad y evitará el problema del administrador de contraseñas.

Pero en última instancia, se enfrenta a una compensación de seguridad y usabilidad. Si Bob es demasiado perezoso / olvidadizo / apático / negligente para cerrar sesión en su PC, ninguna cantidad de JavaScript que escriba puede salvarlo.

Puede usar un código Javascript simple para almacenar el valor de la contraseña en una variable onblur y luego restaurarla en foque y / o onsubmit.

Mira el siguiente código de demostración y su demostración en línea here :

<!DOCTYPE html> <html> <head> <meta charset="utf-8"> <title>JS Bin</title> <script> password = ''''; function setPasswordBack(){ showPassword(); } function hidePassword(){ p = document.getElementById(''pass''); password = p.value; p.value = ''*********''; } function showPassword(){ p = document.getElementById(''pass''); p.type= "password"; p.value = password; } </script> </head> <body> <form action="" method="get" onsubmit="setPasswordBack()"> <input type="password" value="" name="password" id="pass" onblur="hidePassword()" onfocus="showPassword()" /> <input type="submit" /> </form> </body> </html>

Está claro que la solución es una solución dependiente de JavaScript, por lo que en el caso de deshabilitar javascript, puede usar noscript para solicitar un navegador habilitado para JavaScript.

Pues no es posible con la tecnología actual. Como han dicho otros, todavía puede inspeccionar todo el código del lado del cliente e intentar manipular el DOM.

La otra solución es implementar como login bancario. Aleatorizar la secuencia de contraseñas cada vez que inicie sesión. Por ejemplo, si la longitud de la contraseña es 10, proporcione al usuario tres campos de contraseña, pregunte la secuencia de contraseña, por ejemplo. 3º, 5º, 10º. Esto cambiará cada vez que el usuario intente iniciar sesión. Y en el lado del servidor los comparas.

Vi soluciones en diferentes respuestas. En todos ellos, es más difícil ver la contraseña, pero no impide que alguien la vea.

Nota : en el lado del cliente, los objetos de JavaScript se pueden manipular e inspeccionar. En las soluciones proporcionadas en otras respuestas, pude acceder fácilmente a la información de la contraseña.

Como han dicho otros, no puede evitar que el usuario vea la contraseña utilizando herramientas de desarrollador en el lado del cliente.

No pude pensar en un caso de uso, pero mencionó el rellenador automático de formularios y la opción Recordarme .

Rellenador automático de formularios , que yo sepa, están protegidos por contraseña maestra. Ellos deberían ser; No usaría uno si no pudiera encenderlo o apagarlo de manera segura. En este caso, es mi responsabilidad cerrar la sesión, siempre que esté en situación de compartir una computadora.

La opción "Recuérdeme" , como suele promocionarse en los sitios web, solo debe utilizarse cuando se trata de su computadora personal y usted no espera compartir su dispositivo con otra persona. No lo uses o asegúrate de que nadie más use tu cuenta. Una vez más, es su responsabilidad.

Ahora, todavía ves la necesidad de prevenir tal ataque . Todo lo que puedo hacer es lo siguiente:

No hay una solución viable en el lado del cliente. Así que su solución debe funcionar en el lado del servidor.
En el lado del servidor puede cifrar o hash la función. Por favor, vea esta pregunta para más detalles. Discutiré esto más adelante en el resto de esta respuesta. Puede optar por cualquiera de las soluciones, sin embargo la implementación difiere.

Si usas encriptación, entonces siempre puedes descifrar.

Eso podría ayudarlo en el siguiente escenario: Mantenga la contraseña siempre encriptada. Siempre deben coincidir. Sin embargo, cuando el usuario quiera cambiar su contraseña, será un texto claro. El usuario no puede escribirlo en forma cifrada. Tienes que resolver eso. Hay soluciones. Estoy seguro de que entiendes eso.

Si usa hashing (encriptado) , es muy difícil de descifrar . No puedes descifrarlo.

Esto podría ayudarlo en el siguiente escenario: el servidor envía solo la versión hash. De esta manera ningún atacante puede usar esta información. Debes diseñarlo en consecuencia, pero me imagino que también lo descubrirás.

Dicho esto, realmente no veo un caso de uso aceptable para su requerimiento.

Déjame explicarte por qué. Desea evitar que un atacante vea la contraseña en caso de que un usuario recuerde las contraseñas o use un rellenador automático de formularios. Bueno, si un atacante puede acceder a la computadora de un usuario, simplemente podría iniciar sesión, ¿por qué molestarse en ver la contraseña?

Hay una razón por la cual compañías como Google o Facebook no trajeron una solución para su caso de uso. Recorrieron otro camino e intentaron impulsar una mayor seguridad mediante la autenticación de 2 factores.

Si puedes usar eso, hazlo. No resuelve el problema completamente, pero puede esperar que aumente la seguridad. En particular es más difícil para un atacante.

No puedes, y no deberías . Este no es un problema de seguridad que deba abordar en su sitio web. Depende del usuario mantener sus contraseñas seguras. Si tengo la capacidad de usar la consola dev o inyectar javascript en tu página, no importa lo que hagas, las contraseñas del usuario aún estarán en peligro.

Si un usuario elige guardar sus contraseñas en su navegador, entonces depende de ellos evitar que caigan en manos equivocadas, y no hay absolutamente nada que pueda hacer al respecto en su sitio. De hecho, si está utilizando Chrome y tiene las contraseñas guardadas, navegue a chrome: // settings / passwords y haga clic en algunos campos de contraseña.

Otras respuestas hablan de contraseñas de hash, etc. Eso es algo que definitivamente debería hacer, pero en su servidor. Por supuesto, puede hacer un hash o cifrar una contraseña antes de enviarla a su servidor (y también debería usar https), pero ese es un problema completamente diferente.

Nota: creo que deberías evitar hacer esto, ya que romperá la funcionalidad básica del navegador.

Pero si insiste, podría hacer más difícil que alguien revele la contraseña "delegando" la escritura en otro campo de entrada y rellenando el campo de la contraseña con caracteres aleatorios.

A continuación se muestra un ejemplo de una manera de hacerlo. Tenga en cuenta que de ninguna manera impide que alguien recupere la contraseña del cuerpo de la solicitud directamente o si encuentra el elemento delegado "oculto".

Ahora tiene la opción de volver a completar la entrada de su contraseña con la contraseña correcta en el envío del formulario, o simplemente hacer que su servidor espere que la contraseña llegue del campo delegado.

Si te apetece, puedes agregar el estilo apropiado al campo de contraseña cuando el campo de delegado está enfocado y así dar al usuario la impresión de que aún están enfocados en el campo de contraseña en sí.

Pero no lo hagas

Respuesta corta: no se puede prevenir, lamentablemente. Esto se debe a que todo el código del lado del cliente (JavaScript) es modificable por el propio cliente, lo que hace que un sistema de seguridad basado en el cliente sea vulnerable.

La única solución viable que se me ocurre es almacenar una representación hash de la contraseña, en lugar de la contraseña sin procesar. Esto (si no tiene en cuenta los ataques hash-bruteforce) mantendrá la contraseña en bruto segura.

Un hash es una representación del texto original y no es reversible. Es decir, la cadena de caracteres original no puede ser recuperada por ningún algoritmo, usando solo el hash. Ejemplos de hash ''son MD5 y SHA. Esta técnica se usa comúnmente en enrutadores, donde la contraseña a menudo se almacena en el navegador.

Aclaración : nunca almacene sus contraseñas en texto sin formato, y si desea adoptar esta técnica de contraseña previamente ingresada; el hashing y / o el cifrado deben ocurrir en el lado del servidor.