Deshabilitar la funcionalidad de ‘Guardar contraseña’ del navegador

Una de las alegrías de trabajar para una agencia de salud del gobierno es lidiar con toda la paranoia sobre el manejo de la PHI (Información de salud protegida). No me malinterpreten, estoy a favor de hacer todo lo posible para proteger la información personal de las personas (salud, finanzas, hábitos de navegación, etc.), pero a veces las personas se ponen un poco nerviosas.

Un ejemplo: uno de nuestros clientes estatales descubrió recientemente que el navegador proporciona la función útil para guardar su contraseña. Todos sabemos que ha estado allí por un tiempo y es completamente opcional y depende del usuario final decidir si es o no una decisión inteligente de usar o no. Sin embargo, hay un poco de alboroto en este momento y se nos exige encontrar una forma de desactivar esa funcionalidad para nuestro sitio.

Pregunta : ¿Hay alguna manera de que un sitio le diga al navegador que no ofrezca recordar las contraseñas? He estado trabajando en el desarrollo web desde hace mucho tiempo, pero no sé si ya lo he encontrado antes.

Cualquier ayuda es apreciada.

No estoy seguro de si funcionará en todos los navegadores, pero debería intentar configurar autocomplete = “off” en el formulario.

La forma más sencilla y sencilla de deshabilitar las solicitudes de almacenamiento de Formulario y Contraseña y evitar que los datos del formulario se guarden en la memoria caché en el historial de la sesión es usar el atributo de elemento de formulario de autocompletar con el valor “desactivado”.

De http://developer.mozilla.org/En/How_to_Turn_Off_Form_Autocompletion

Algunas investigaciones menores muestran que esto funciona en IE pero no dejaré ninguna garantía;)

@ Joseph : Si es un requisito estricto para pasar la validación XHTML con el marcado real (no sé por qué sería así) en teoría podría agregar este atributo con javascript después, pero luego los usuarios con js desactivados (probablemente una cantidad neglizable de su base de usuarios) o cero si su sitio requiere js) aún se guardarán sus contraseñas.

Ejemplo con jQuery:

 $('#loginForm').attr('autocomplete', 'off'); 

He estado luchando con este problema por un tiempo, con un giro único al problema. Los usuarios privilegiados no pueden tener las contraseñas guardadas para ellos, pero los usuarios normales lo necesitan. Esto significaba que los usuarios con privilegios tenían que iniciar sesión dos veces, y la segunda vez no aplicar contraseñas guardadas.

Con este requisito, el método estándar de autocomplete="off" no funciona en todos los navegadores, ya que la contraseña puede haberse guardado desde el primer inicio de sesión. Un colega encontró una solución para reemplazar el campo de contraseña cuando se centró con un nuevo campo de contraseña, y luego se enfoca en el nuevo campo de contraseña (luego conecta el mismo controlador de eventos). Esto funcionó (excepto que causó un bucle infinito en IE6). Tal vez había una forma de evitarlo, pero me estaba causando una migraña.

Finalmente, traté de tener el nombre de usuario y la contraseña fuera del formulario. Para mi sorpresa, ¡funcionó! Funcionó en IE6, y las versiones actuales de Firefox y Chrome en Linux. No lo he probado más, pero sospecho que funciona en la mayoría de los navegadores, si no en todos (pero no me sorprendería si hubiera un navegador que no le importara si no hubiera forma).

Aquí hay un código de muestra, junto con algunos jQuery para que funcione:

   

Solo usa

readonly onfocus = “this.removeAttribute (‘readonly’);”

además de

autocompletar = “apagado”

a la (s) entrada (s) que no desea recordar de los datos ( username , password , etc.) como se muestra a continuación:

   

Probado en las últimas versiones de los principales navegadores, es decir, Google Chrome , Mozilla Firefox , Microsoft Edge , etc., y funciona como un encanto. Espero que esto ayude…

Bueno, es una publicación muy antigua, pero aún así daré mi solución, que mi equipo había estado tratando de lograr por mucho tiempo. Acabamos de agregar un nuevo campo tipo de entrada = “contraseña” dentro del formulario y lo envolvemos en div e hicimos el div oculto. Se aseguró de que este div esté antes de la entrada de contraseña real. Esto funcionó para nosotros y no dio ninguna opción de Guardar contraseña

Plunk – http://plnkr.co/edit/xmBR31NQMUgUhYHBiZSg?p=preview

HTML:

 

CSS:

 .hidden {display:none;} 

Puede evitar que el navegador haga coincidir los formularios aleatorizando el nombre utilizado para el campo de contraseña en cada espectáculo. Luego, el navegador ve una contraseña para la misma URL, pero no puede estar seguro de que sea la misma contraseña . Tal vez está controlando algo más.

Actualización: tenga en cuenta que esto debe ser adicional al uso de autocompletar u otras tácticas, no un reemplazo para ellas, por las razones indicadas por otros.

También tenga en cuenta que esto solo evitará que el navegador complete automáticamente la contraseña. No impedirá que almacene la contraseña en cualquier nivel de seguridad arbitraria que el navegador decida usar.

Utilice la autenticación real de dos factores para evitar la única dependencia de las contraseñas que podrían almacenarse en muchos más lugares que la memoria caché del navegador del usuario.

He probado que agregar autocompletar = “apagado” en la etiqueta del formulario en todos los navegadores principales. De hecho, la mayoría de los pueblos de EE. UU. Usan IE8 hasta ahora.

  1. IE8, IE9, IE10, Firefox, Safari funcionan bien.

    El navegador no pregunta “guardar contraseña”. Además, el nombre de usuario y la contraseña previamente guardados no se completaron.

  2. Chrome e IE 11 no son compatibles con la función autocompletar = “apagado”
  3. FF apoya el autocompletar = “off”. pero a veces las credenciales guardadas existentes se completan.

Actualizado el 11 de junio de 2014

Finalmente, a continuación se muestra una solución de navegador cruzado que utiliza JavaScript y está funcionando bien en todos los navegadores.

Necesita eliminar la etiqueta “formulario” en el formulario de inicio de sesión. Después de la validación del lado del cliente, ponga esas credenciales en forma oculta y envíela.

Además, agregue dos métodos. uno para la validación “validateLogin ()” y otro para escuchar el evento enter mientras se hace clic en ingresar en el cuadro de texto / contraseña / botón “checkAndSubmit ()”. porque ahora el formulario de inicio de sesión no tiene una etiqueta de formulario, así que ingrese el evento que no funciona aquí.

HTML

 
Username: Password:

Javascript

 //For validation- you can modify as you like function validateAndLogin(){ var username = document.getElementById("username"); var password = document.getElementById("password"); if(username && username.value == ''){ alert("Please enter username!"); return false; } if(password && password.value == ''){ alert("Please enter password!"); return false; } document.getElementById("hidden_username").value = username.value; document.getElementById("hidden_password").value = password.value; document.getElementById("HiddenLoginForm").submit(); } //For enter event function checkAndSubmit(e) { if (e.keyCode == 13) { validateAndLogin(); } } 

¡¡¡Buena suerte!!!

La forma más limpia es utilizar el atributo de etiqueta autocomplete="off" pero Firefox no lo obedece cuando se cambian los campos con Tab.

La única forma en que puede detener esto es agregar un campo de contraseña oculta falso que engaña al navegador para que allí ingrese la contraseña.

    

Es un hack feo, porque cambias el comportamiento del navegador, lo que debería considerarse una mala práctica. Úselo solo si realmente lo necesita.

Nota: esto detendrá efectivamente el autocompletado de contraseñas, porque FF “guardará” el valor de #prevent_autofill (que está vacío) e intentará rellenar las contraseñas guardadas allí, ya que siempre usa la primera entrada type="password" que encuentra en DOM después de la entrada respectiva de “nombre de usuario”.

En realidad, no; lo único que puedes hacer de forma realista es ofrecer consejos en el sitio; tal vez, antes de la primera vez que inicien sesión, les muestre un formulario con información que indique que no se recomienda que permitan que el navegador almacene la contraseña.

Luego, el usuario seguirá inmediatamente el consejo, escribirá la contraseña en una nota de post-it y la pegará en su monitor.

Lo que he estado haciendo es una combinación de autocompletar = “off” y borrar campos de contraseña usando un javascript / jQuery.

jQuery Ejemplo:

 $(function() { $('#PasswordEdit').attr("autocomplete", "off"); setTimeout('$("#PasswordEdit").val("");', 50); }); 

Al usar setTimeout() puede esperar que el navegador complete el campo antes de borrarlo, de lo contrario, el navegador siempre se autocompletará una vez que haya despejado el campo.

si autocomplete = “off” no funciona … elimine la etiqueta del formulario y use una etiqueta div en su lugar, luego pase los valores del formulario usando jquery al servidor. Esto funcionó para mí.

Debido a que autocomplete = “off” no funciona para los campos de contraseña, uno debe confiar en javascript. Aquí hay una solución simple basada en las respuestas que se encuentran aquí.

Agregue el atributo data-password-autocomplete = “off” a su campo de contraseña:

  

Incluye los siguientes JS:

 $(function(){ $('[data-password-autocomplete="off"]').each(function() { $(this).prop('type', 'text'); $('').hide().insertBefore(this); $(this).focus(function() { $(this).prop('type', 'password'); }); }); }); 

Esta solución funciona tanto para Chrome como para FF.

Para que la gente se dé cuenta, el atributo ‘autocompletar’ funciona la mayor parte del tiempo, pero los usuarios avanzados pueden sortearlo usando un bookmarklet.

Tener un navegador que guarde sus contraseñas en realidad aumenta la protección contra el registro de teclas, por lo que posiblemente la opción más segura sea guardar contraseñas en el navegador, pero protegerlas con una contraseña maestra (al menos en Firefox).

Tengo un trabajo alrededor, lo que puede ayudar.

Podría hacer un truco de fuente personalizado. Por lo tanto, cree una fuente personalizada, con todos los caracteres como un punto / círculo / estrella, por ejemplo. Use esto como una fuente personalizada para su sitio web. Compruebe cómo hacerlo en inkscape: cómo crear su propia fuente

Luego, en su formulario de inicio de sesión use:

 

Luego agrega tu css:

 @font-face { font-family: 'myCustomfont'; src: url('myCustomfont.eot'); src: url('myCustomfont?#iefix') format('embedded-opentype'), url('myCustomfont.woff') format('woff'), url('myCustomfont.ttf') format('truetype'), url('myCustomfont.svg#myCustomfont') format('svg'); font-weight: normal; font-style: normal; } .password { font-family:'myCustomfont'; } 

Bastante cross browser compatible. He intentado IE6 +, FF, Safari y Chrome. Solo asegúrate de que la fuente oet que conviertas no se corrompa. ¿Espero eso ayude?

Markus planteó un gran punto. Decidí buscar el atributo autocomplete y obtuve lo siguiente:

La única desventaja de usar este atributo es que no es estándar (funciona en los navegadores IE y Mozilla), y haría que la validación XHTML fallara. Creo que este es un caso donde es razonable romper la validación sin embargo. ( fuente )

Así que tendría que decir que, aunque no funciona al 100% en todos los ámbitos, se maneja en los principales navegadores, por lo que es una gran solución.

La forma más sencilla de resolver este problema es colocar los campos INPUT fuera de la etiqueta FORM y agregar dos campos ocultos dentro de la etiqueta FORM. Luego, en un oyente de eventos de envío antes de que los datos de formulario sean enviados a los valores de copia del servidor desde la entrada visible a los invisibles.

Aquí hay un ejemplo (no puede ejecutarlo aquí, ya que la acción del formulario no está configurada en un script de inicio de sesión real):

 < !doctype html>   Login & Save password test        

Mi solución js (jquery) es cambiar el tipo de ingreso de contraseña al texto en el envío de formulario . La contraseña podría hacerse visible por un segundo, así que también escondo la entrada justo antes de eso. Preferiría no utilizar esto para los formularios de inicio de sesión , pero es útil (junto con autocompletar = “apagado”), por ejemplo, dentro de la parte de administración del sitio web.

Intente poner esto dentro de una consola (con jquery), antes de enviar el formulario.

 $('form').submit(function(event) { $(this).find('input[type=password]').css('visibility', 'hidden').attr('type', 'text'); }); 

Probado en Chrome 44.0.2403.157 (64 bits).

Intenté arriba autocomplete="off" y aún algo exitoso. si está utilizando js angulares, mi recomendación es ir con el botón y hacer clic ng.

  

Esto ya tiene una respuesta aceptada y agrego esto si alguien no puede resolver el problema con la respuesta aceptada, puede ir con mi mecanismo.

Gracias por la pregunta y las respuestas.

Probé muchas soluciones. Nombre de campo de contraseña dinámica, campos de contraseña múltiples (invisible para los falsos), cambiar el tipo de entrada de “texto” a “contraseña”, autocompletar = “apagado”, autocompletar = “nueva-contraseña”, … pero nada lo resolvió con reciente navegador.

Para deshacerse de la contraseña, recuerde, finalmente traté la contraseña como campo de entrada y “desenfoque” el texto escrito.

Es menos “seguro” que un campo de contraseña nativo ya que al seleccionar el texto escrito se mostrará como texto claro, pero no se recuerda la contraseña. También depende de tener Javascript activado.

Deberá estimar el riesgo de utilizar la opción debajo de la propuesta frente a la contraseña recordar desde el navegador.

Si bien el usuario puede administrar la contraseña recordada (eliminada por sitio), está bien para una computadora personal, no para una computadora “pública” o compartida.

En mi caso, es para un ERP que se ejecuta en computadoras compartidas, así que lo probaré con mi solución a continuación.

  

Una forma que conozco es utilizar (por ejemplo) JavaScript para copiar el valor del campo de contraseña antes de enviar el formulario.

El principal problema con esto es que la solución está ligada a JavaScript.

Por otra parte, si se puede vincular a JavaScript, también puede hash la contraseña en el lado del cliente antes de enviar una solicitud al servidor.

El problema real es mucho más profundo que solo agregar atributos a su HTML: esta es una preocupación de seguridad común, es por eso que la gente inventó claves de hardware y otras cosas locas por seguridad.

Imagine que tiene autocompletar = “apagado” funcionando perfectamente en todos los navegadores. ¿Eso ayudaría con la seguridad? Claro que no. Los usuarios anotarán sus contraseñas en libros de texto, en pegatinas adheridas a su monitor, donde cada visitante de la oficina puede verlas, guardarlas en archivos de texto en el escritorio, etc.

En general, la aplicación web y el desarrollador web no son responsables en modo alguno de la seguridad del usuario final. Los usuarios finales pueden protegerse solo. Idealmente, DEBEN tener todas las contraseñas en su cabeza y usar la funcionalidad de restablecimiento de contraseñas (o administrador de contacto) en caso de que lo hayan olvidado. De lo contrario, siempre existirá el riesgo de que la contraseña se pueda ver y robar de alguna manera.

Entonces, o tiene alguna política loca de seguridad con claves de hardware (como algunos bancos ofrecen para banca por Internet que básicamente emplea autenticación de dos factores) o básicamente SIN SEGURIDAD. Bueno, esto es un poco exagerado, por supuesto. Es importante entender qué estás tratando de proteger contra:

  1. No acceso autorizado El formulario de inicio de sesión más simple es suficiente básicamente. A veces se toman medidas adicionales como preguntas de seguridad aleatorias, CAPTCHA, endurecimiento de contraseñas, etc.
  2. Credencial oliendo HTTPS es IMPRESCINDIBLE si las personas acceden a su aplicación web desde zonas Wi-Fi públicas, etc. Menciona que, incluso teniendo HTTPS, los usuarios deben cambiar sus contraseñas con regularidad.
  3. Ataque interno. Hay dos muchos ejemplos de este tipo, desde el simple robo de sus contraseñas del navegador o aquellas que haya anotado en algún lugar del escritorio (no requiere ninguna habilidad de TI) y termina con la falsificación de sesiones e interceptación del tráfico de red local (incluso encriptado) y acceder más a la aplicación web al igual que fue otro usuario final.

En esta publicación en particular, veo requisitos inadecuados para el desarrollador que nunca podrá resolver debido a la naturaleza del problema: seguridad del usuario final. Mi punto subjetivo es que el desarrollador debería decir NO y señalar el problema de los requisitos en lugar de perder el tiempo en tales tareas, sinceramente. Esto no hace que su sistema sea más seguro, sino que conduce a los casos con pegatinas en los monitores. Desafortunadamente, algunos jefes solo escuchan lo que quieren escuchar. Sin embargo, si yo fuera tú, intentaría explicar de dónde viene el problema real, y ese autocompletar = “apagado” no lo resolvería a menos que obligue a los usuarios a guardar todas sus contraseñas exclusivamente en su cabeza. El desarrollador en su extremo no puede proteger a los usuarios por completo, los usuarios necesitan saber cómo usar el sistema y, al mismo tiempo, no exponer su información sensible / segura y esto va más allá de la autenticación.

Enfrentando el mismo problema HIPAA y encontró una solución relativamente fácil,

  1. Cree un campo de contraseña oculta con el nombre del campo como una matriz.

      
  2. Use la misma matriz para el campo de contraseña real.

      

El navegador (Chrome) puede pedirle que “guarde la contraseña”, pero independientemente de si el usuario selecciona guardar, la próxima vez que inicie sesión la contraseña rellenará automáticamente el campo de contraseña oculta, la ranura cero en la matriz, dejando la 1ra ranura en blanco.

Traté de definir la matriz, como “contraseña [part2]”, pero todavía recuerdo. Creo que se descarta si se trata de una matriz no indexada porque no tiene más remedio que dejarla en el primer lugar.

Luego, utiliza su lenguaje de progtwigción de elección para acceder a la matriz, PHP, por ejemplo,

 echo $_POST['password'][1]; 

Dado que la mayoría de las sugerencias de autocomplete , incluida la aceptada, no funcionan en los navegadores web actuales (es decir, los administradores de contraseñas del navegador ignoran la función de autocomplete ), una solución más novedosa es intercambiar password y tipos de text y hacer que el color de fondo coincida con el texto color cuando el campo es un campo de texto sin formato, que continúa ocultando la contraseña mientras que es un campo de contraseña real cuando el usuario (o un progtwig como KeePass) ingresa una contraseña. Browsers don’t ask to save passwords that are stored in plain text fields.

The advantage of this approach is that it allows for progressive enhancement and therefore doesn’t require Javascript for a field to function as a normal password field (you could also start with a plain text field instead and apply the same approach but that’s not really HIPAA PHI/PII-compliant). Nor does this approach depend on hidden forms/fields which might not necessarily be sent to the server (because they are hidden) and some of those tricks also don’t work either in several modern browsers.

jQuery plugin:

https://github.com/cubiclesoft/php-flexforms-modules/blob/master/password-manager/jquery.stoppasswordmanager.js

Relevant source code from the above link:

 (function($) { $.fn.StopPasswordManager = function() { return this.each(function() { var $this = $(this); $this.addClass('no-print'); $this.attr('data-background-color', $this.css('background-color')); $this.css('background-color', $this.css('color')); $this.attr('type', 'text'); $this.attr('autocomplete', 'off'); $this.focus(function() { $this.attr('type', 'password'); $this.css('background-color', $this.attr('data-background-color')); }); $this.blur(function() { $this.css('background-color', $this.css('color')); $this.attr('type', 'text'); $this[0].selectionStart = $this[0].selectionEnd; }); $this.on('keydown', function(e) { if (e.keyCode == 13) { $this.css('background-color', $this.css('color')); $this.attr('type', 'text'); $this[0].selectionStart = $this[0].selectionEnd; } }); }); } }(jQuery)); 

Manifestación:

https://barebonescms.com/demos/admin_pack/admin.php

Click “Add Entry” in the menu and then scroll to the bottom of the page to “Module: Stop Password Manager”.

Disclaimer: While this approach works for sighted individuals, there might be issues with screen reader software. For example, a screen reader might read the user’s password out loud because it sees a plain text field. There might also be other unforeseen consequences of using the above plugin. Altering built-in web browser functionality should be done sparingly with testing a wide variety of conditions and edge cases.

Is there a way for a site to tell the browser not to offer to remember passwords?

The website tells the browser that it is a password by using . So if you must do this from a website perspective then you would have to change that. (Obviously I don’t recommend this).

The best solution would be to have the user configure their browser so it won’t remember passwords.

If you do not want to trust the autocomplete flag, you can make sure that the user types in the box using the onchange event. The code below is a simple HTML form. The hidden form element password_edited starts out set to 0. When the value of password is changed, the JavaScript at the top (pw_edited function) changes the value to 1. When the button is pressed, it checks the valueenter code here before submitting the form. That way, even if the browser ignores you and autocompletes the field, the user cannot pass the login page without typing in the password field. Also, make sure to blank the password field when focus is set. Otherwise, you can add a character at the end, then go back and remove it to trick the system. I recommend adding the autocomplete=”off” to password in addition, but this example shows how the backup code works.

      

autocomplete=”off” does not work for disabling the password manager in Firefox 31 and most likely not in some earlier versions, too.

Checkout the discussion at mozilla about this issue: https://bugzilla.mozilla.org/show_bug.cgi?id=956906

We wanted to use a second password field to enter a one-time password generated by a token. Now we are using a text input instead of a password input. 🙁

I was given a similar task to disable the auto-filling up of login name and passwords by browser, after lot of trial and errors i found the below solution to be optimal. Just add the below controls before your original controls.

     

This is working fine for IE11 and Chrome 44.0.2403.107

autocomplete=”off” works for most modern browsers, but another method I used that worked successfully with Epiphany (a WebKit-powered browser for GNOME) is to store a randomly generated prefix in session state (or a hidden field, I happened to have a suitable variable in session state already), and use this to alter the name of the fields. Epiphany still wants to save the password, but when going back to the form it won’t populate the fields.

I haven’t had any issues using this method:

Use autocomplete=”off”, add a hidden password field and then another non-hidden one. The browser tries to auto complete the hidden one if it doesn’t respect autocomplete=”off”

Another solution is to make the POST using an hidden form where all the input are of type hidden. The visible form will use input of type “password”. The latter form will never be submitted and so the browser can’t intercept at all the operation of login.