Deshabilitar la funcionalidad 'Guardar contraseña' del navegador

423

Una de las alegrías de trabajar para una agencia de salud del gobierno es tener que lidiar con toda la paranoia en torno a la PHI (Información de salud protegida). No me malinterpreten, estoy dispuesto a 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 demasiado nerviosas.

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

Pregunta : ¿Hay alguna forma de que un sitio le diga al navegador que no ofrezca recordar contraseñas? He estado en el desarrollo web durante mucho tiempo, pero no sé si me he encontrado con eso antes.

Cualquier ayuda es apreciada.

mattsmith321
fuente
66
Debe proporcionar un script de greasemonkey para que las personas puedan volver a habilitarlo. No creo que a los usuarios les guste verse obligados a escribir la contraseña cada vez ...
ThiefMaster
14
La pregunta merece un voto positivo por ser útil y clara. Por otro lado, no quiero que la gente encuentre una solución a este "problema".
Ian Boyd
11
Esto no siempre es un "problema". Vine aquí porque firefox me pide que guarde una contraseña para un formulario que contiene una contraseña WiFi / SSID, no un formulario de nombre de usuario / contraseña de inicio de sesión. Es muy molesto y quiero detenerlo.
srd
1
Si la información es tan crítica, debe estar protegida por algo más que una contraseña.
Sam Watkins
Una forma en que parece funcionar es no usar <form>. Si está utilizando javascript para enviar los datos (XHR), entonces no los necesita. Quería deshabilitar en un sistema que usa autenticación de "contraseña de un solo uso" (no hay razón para almacenarlo). Para las autenticaciones de usuario / contraseña, no recomendaría desactivar esa función.
lepe

Respuestas:

322

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

<form id="loginForm" action="login.cgi" method="post" autocomplete="off">

La forma más fácil y sencilla de deshabilitar las solicitudes de almacenamiento de Formularios y Contraseñas y evitar que los datos del formulario se almacenen en caché en el historial de la sesión es utilizar el atributo de elemento de formulario autocompletado con el valor "desactivado".

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

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

@Joseph : Si es un requisito estricto pasar la validación XHTML con el marcado real (no sé por qué sería), teóricamente podría agregar este atributo con JavaScript después, pero luego los usuarios con js deshabilitado (probablemente una cantidad descuidada de su base de usuarios o cero si su sitio requiere js) aún tendrá sus contraseñas guardadas.

Ejemplo con jQuery:

$('#loginForm').attr('autocomplete', 'off');
Markus Olsson
fuente
48
Solo un comentario rápido, ya que esto está cambiando, HTML5 agrega el atributo de autocompletar a la especificación, por lo que ahora es válido.
Tyler Egeto
11
Solo para su información, Microsoft decidió que Internet Explorer 11 ya no será un honor autocomplete="off"para los input type="password"campos. msdn.microsoft.com/en-us/library/ie/ms533486%28v=vs.85%29.aspx
JW Lim
66
Al igual que @JWLim mencionó el soporte de caída de IE 11 para deshabilitar la funcionalidad de guardar contraseña, también lo es Firefox. bugzilla.mozilla.org/show_bug.cgi?id=956906
Gregory Cosmo Haun
3
Firefox (desafortunadamente) siguió el ejemplo de Microsoft y también "eliminó" el soporte de autocompletar. Para más detalles, vea el comentario 100 en la siguiente discusión: bugzilla.mozilla.org/show_bug.cgi?id=956906
Bouncing Bit
8
Ahora, no funciona para Firefox 38+ mozilla.org/en-US/firefox/38.0/releasenotes
Illuminator
44

Además de

autocomplete="off"

Utilizar

readonly onfocus="this.removeAttribute('readonly');"

para las entradas que no quiere que recuerden los datos del formulario ( username, password, etc.) como se muestra a continuación:

<input type="text" name="UserName" autocomplete="off" readonly 
    onfocus="this.removeAttribute('readonly');" >

<input type="password" name="Password" autocomplete="off" readonly 
    onfocus="this.removeAttribute('readonly');" >

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.

Murat Yıldız
fuente
2
@Murat Yıldız: Tengo que implementar lo mismo y seguí su código. Me está funcionando bien en todos los navegadores. Gracias !
Sree
1
@Sree Estoy feliz de que haya sido útil para ti :)
Murat Yıldız
3
¡Acabo de probar Mozilla Firefox 52.0 , Google Chrome 57.0 , Microsoft Edge 38.1 y funciona a las mil maravillas! ..
Murat Yıldız
1
Puede haber un error en Safari mobile ya que esta respuesta lo está arreglando stackoverflow.com/questions/2530/…
Ferie
1
Windows Firefox 57.0.2 (64 bits) todavía sugiere guardar la contraseña después de implementar esto.
Panu Haaramo
37

Había estado luchando con este problema por un tiempo, con un giro único al problema. Los usuarios privilegiados no podían tener las contraseñas guardadas para ellos, pero los usuarios normales lo necesitaban. Esto significaba que los usuarios privilegiados tenían que iniciar sesión dos veces, la segunda vez sin forzar contraseñas guardadas.

Con este requisito, el autocomplete="off"método estándar no funciona en todos los navegadores, porque 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 estaba enfocado con un nuevo campo de contraseña, y luego enfocarse en el nuevo campo de contraseña (luego conecte el mismo controlador de eventos). Esto funcionó (excepto que causó un bucle infinito en IE6). Tal vez había una forma de evitar eso, 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, esto 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 algo de jQuery para que funcione:

<input type="text" id="username" name="username"/>
<input type="password" id="password" name="password"/>

<form id="theForm" action="/your/login" method="post">
  <input type="hidden" id="hiddenUsername" name="username"/>
  <input type="hidden" id="hiddenPassword" name="password"/>
  <input type="submit" value="Login"/>
</form>

<script type="text/javascript" language="JavaScript">
  $("#theForm").submit(function() {
    $("#hiddenUsername").val($("#username").val());
    $("#hiddenPassword").val($("#password").val());
  });
  $("#username,#password").keypress(function(e) {
    if (e.which == 13) {
      $("#theForm").submit();
    }
  });
</script>
Mike Stone
fuente
1
Eso parece una buena solución. Tiene sentido ya que el formulario que envía no incluye una contraseña. Supongo que para estar seguro de que podría tener dos formularios, el primero solo para asegurarse de que el nombre de usuario y la contraseña sean visibles en todos los navegadores.
Alexis Wilke
3
Me gusta su solución e implementé una similar en mi sitio, es ridículo cómo en la actualidad, los navegadores no ofrecen una forma simple de resolver esto.
AgelessEssence
No estoy seguro si es porque estoy atascado usando jquery 1.6, pero el jquery anterior solo funcionó después de envolver dentro de $ (document) .ready (function () {});
rgbflawed
La única idea correcta es esta, ya que algunos navegadores ya no aceptarán autocompletar = "off".
Abadis el
1
He intentado este método en Chrome, Opera e Internet Explorer y parece que funciona, pero no funciona con Firefox unforuntately
chenks
29

Bueno, es una publicación muy antigua, pero aún así daré mi solución, que mi equipo había estado tratando de lograr durante mucho tiempo. Acabamos de agregar un nuevo campo input type = "password" dentro del formulario y lo envolvimos en div y lo ocultamos. Asegúrese 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:

<form method="post" action="yoururl">
      <div class="hidden">
        <input type="password"/>
      </div>
      <input type="text" name="username" placeholder="username"/>
      <input type="password" name="password" placeholder="password"/>
    </form>

CSS:

.hidden {display:none;}
whyAto8
fuente
1
Una ventaja de esta manera contra los que usan entradas ocultas es que de esta manera una contraseña nunca se almacena en un campo de texto plano
pvgoddijn
@ whyAto8 Esto no funcionó para mí en Chrome 47.0.2526.111 ... el truco para hacerlo funcionar fue agregar otro texto de campo en el div oculto. El navegador solicita guardar la contraseña PERO dice "¿Está seguro de guardar esta actualización?" y luego muestra un nombre de usuario en blanco y una contraseña en blanco. Esto ha funcionado.
David Bélanger
1
La solución de whyAto8 junto con el comentario de @David Bélanger funcionó para mí (ninguna de las otras soluciones lo hizo). También debo mencionar que agregué los dos campos ocultos en blanco ANTES de los realmente utilizados para la entrada de datos, y los campos duplicados (ocultos) tenían los mismos nombres respectivos. De esta manera, Chrome (48.0.2564.103) ni siquiera preguntó si se debía guardar alguna contraseña.
Vadim
Ninguna combinación de esto funciona en Chrome 48.0.2564.116. Incluso combinado con el comentario de DavidBelanger, la ventana emergente de Chrome que le pide que guarde la contraseña todavía la almacena en caché si hace clic en Aceptar
ChrisO
Gran respuesta ... ¿Podrías decirme por qué dijiste "Asegúrate de que este div esté antes de ingresar la contraseña real" ? Puse ese div después de esa entrada de contraseña real y aún funciona ... Entonces, ¿por qué mencionaste eso?
Martin AJ
16

Puede evitar que el navegador coincida con los formularios aleatorizando el nombre utilizado para el campo de contraseña en cada programa. 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 además del uso de autocompletar u otras tácticas, no un reemplazo para ellos, 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 evitará que almacene la contraseña en cualquier nivel de seguridad arbitraria que el navegador elija usar.

Joel Coehoorn
fuente
55
[@Joel] (# 32409) que podría evitar que el formulario se complete automáticamente, pero ¿evitaría que el navegador solicite guardar la contraseña para este supuesto nuevo formulario?
Joseph Pecoraro
3
No creo que esto funcione ahora. En FF 13, tengo un formulario con varios campos de contraseña, todos con diferentes nombres. FF, una vez que guarda una contraseña para esa página, pega la contraseña guardada en TODOS los campos de contraseña. No le importa cuál sea el nombre de los campos (tengo "nueva_contraseña" y "antigua_contraseña", por ejemplo, y la contraseña guardada se descarga en ambos). En este formulario en particular, no tengo un nombre de usuario para guardar la contraseña, solo dos campos de contraseña, en caso de que eso marque la diferencia.
Jason
1
@ Jason asiente con la cabeza, dando al campo de contraseña de un nuevo UUID para un nombre cada vez que no hizo nada para derrotar los intentos del navegador para llenarlo.
FP libremente
14

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

David Schmitt
fuente
2
por cierto, es autenticación, no autenticación
Jonathan.
26
@Jonathan Pity, prefiero la autenticación
Ian Boyd
Otra solución podría ser la implementación de un JavaScript, que cierra el navegador a la fuerza una vez que el usuario cierra la sesión de la aplicación. Esto vaciará la memoria completa del navegador y, por lo tanto, no se pueden recuperar datos de la memoria del navegador.
Ajay Takur
13

La forma más limpia es usar el autocomplete="off"atributo de etiqueta, pero Firefox no lo obedece correctamente cuando cambia los campos con Tab.

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

<input type="text" id="username" name="username"/>
<input type="password" id="prevent_autofill" autocomplete="off" style="display:none" tabindex="-1" />
<input type="password" id="password" autocomplete="off" name="password"/>

Es un truco 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ña, porque FF "guardará" el valor de #prevent_autofill(que está vacío) e intentará completar las contraseñas guardadas allí, ya que siempre usa la primera type="password"entrada que encuentra en DOM después del "nombre de usuario" respectivo entrada.

venimus
fuente
¿Qué sentido tiene evitar que el navegador complete la contraseña pero le permite almacenarla? Solo engaña al usuario para que piense que su contraseña no está almacenada mientras sea realmente vulnerable.
CodesInChaos
De esta manera, en realidad no almacenará su contraseña, porque escribe en el otro cuadro, que FF ignora. En su lugar, almacenará una cadena vacía.
venimus
@CodesInChaos En mi humilde opinión, debe reconsiderar su voto negativo, porque su preocupación no es válida
venimus
12

He probado que agregar autocompletar = "off" en la etiqueta de formulario en todos los principales navegadores. De hecho, la mayoría de las personas en los Estados Unidos 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 rellenan.

  2. Chrome e IE 11 no son compatibles con la función autocomplete = "off"
  3. FF que admite el autocompletar = "off". pero a veces se completan las credenciales guardadas existentes.

Actualizado el 11 de junio de 2014

Finalmente, a continuación se muestra una solución de navegador cruzado que utiliza JavaScript y funciona 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, coloque 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 hace clic 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, ingrese el evento que no funciona aquí.

HTML

<form id="HiddenLoginForm" action="" method="post">
<input type="hidden" name="username" id="hidden_username" />
<input type="hidden" name="password" id="hidden_password" />
</form>

Username: <input type="text" name="username" id="username" onKeyPress="return checkAndSubmit(event);" /> 
Password: <input type="text" name="password" id="password" onKeyPress="return checkAndSubmit(event);" /> 
<input type="button" value="submit" onClick="return validateAndLogin();" onKeyPress="return checkAndSubmit(event);" /> 

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!!!

Asik
fuente
Aunque esta respuesta proporciona información útil, en realidad no responde a la pregunta de cómo evitar que los navegadores guarden contraseñas.
JW Lim
@JW Lim, he actualizado la respuesta. Por favor, míralo. ¡Gracias!
Asik
@Sivakumar, Ok, incluya el sistema operativo y la versión de Safari. para que otras personas se den cuenta de lo mismo. funcionaba en mi sistema (Windows 8, Safary 5)
Asik
@Asik Safari 8.0.3 y Mac OS 10.10
Sivakumar
7

En realidad no, lo único que puede hacer de manera realista es ofrecer consejos sobre el sitio; tal vez, antes de iniciar sesión por primera vez, podría mostrarles 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, anotará la contraseña en una nota adhesiva y la pegará en su monitor.

Jason Bunting
fuente
10
Debes recordar que este es un sitio del gobierno , y esas cosas están políticamente cargadas. Si alguien alto dice "no debe funcionar así", entonces lo que es realista no es parte de la ecuación. El problema puede ser trasladado a las notas Post-It, pero la política es para que un departamento diferente lo maneje; el problema se ha movido ;-) Y en realidad estoy hablando en serio.
Jason
6

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

Ejemplo de jQuery:

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

Al usarlo setTimeout(), puede esperar a que el navegador complete el campo antes de borrarlo; de lo contrario, el navegador siempre se completará automáticamente una vez que haya borrado el campo.

Howard Young
fuente
3

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í.

Nikhil Dinesh
fuente
3

Como 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:

<input type="password" data-password-autocomplete="off">

Incluya el siguiente JS:

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

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

mfernandes
fuente
Windows Firefox 57.0.2 (64 bits) todavía sugiere guardar la contraseña después de implementar esto.
Panu Haaramo
2

Para que la gente se dé cuenta: el atributo 'autocompletar' funciona la mayor parte del tiempo, pero los usuarios avanzados pueden evitarlo utilizando un marcador.

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 es guardar las contraseñas en el navegador pero protegerlas con una contraseña maestra (al menos en Firefox).

Thrawn
fuente
2
"pero los usuarios avanzados pueden evitarlo" , eso es aplicable a la mayoría de las funciones de la aplicación, web o no, y no debería ser una razón para limitar el sistema. Las personas también pueden escribir sus contraseñas en post-it y ponerlas en su monitor, solo puede hacer mucho por la seguridad desde la perspectiva de la aplicación, y proporcionar un comportamiento predeterminado significativo (no guardarlo localmente) es un comienzo.
Niels Keurentjes
2

Tengo una solución, que puede ayudar.

Podrías hacer un hack de fuente personalizado. Entonces, haga 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. Comprueba cómo hacer esto en inkscape: cómo hacer tu propia fuente

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

<form autocomplete='off'  ...>
   <input type="text" name="email" ...>
   <input type="text" name="password" class="password" autocomplete='off' ...>
   <input type=submit>
</form>

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 compatible con navegadores cruzados. He intentado IE6 +, FF, Safari y Chrome. Solo asegúrese de que la fuente oet que convierta no se corrompa. ¿Espero eso ayude?

Dai Bok
fuente
1
muy buena solución no es una fuente contraseña aquí
Andrew
66
Si utiliza una solución de este tipo, debe tener en cuenta que los usuarios pueden copiar libremente el texto ingresado en este campo de contraseña similar. Las funciones de copiar y cortar están deshabilitadas en los campos de contraseña real.
2

La forma más sencilla de resolver este problema es colocar los campos de ENTRADA fuera de la etiqueta FORM y agregar dos campos ocultos dentro de la etiqueta FORM. Luego, en un detector de eventos de envío antes de que los datos del formulario se envíen al servidor, copie los valores de la entrada visible a los invisibles.

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

<!doctype html>
<html>
<head>
  <title>Login & Save password test</title>
  <meta charset="utf-8">
  <script src="//ajax.googleapis.com/ajax/libs/jquery/1.11.2/jquery.min.js"></script>
</head>

  <body>
      <!-- the following fields will show on page, but are not part of the form -->
      <input class="username" type="text" placeholder="Username" />
      <input class="password" type="password" placeholder="Password" />

      <form id="loginForm" action="login.aspx" method="post">
        <!-- thw following two fields are part of the form, but are not visible -->
        <input name="username" id="username" type="hidden" />
        <input name="password" id="password" type="hidden" />
        <!-- standard submit button -->
        <button type="submit">Login</button>
      </form>

    <script>
      // attache a event listener which will get called just before the form data is sent to server
      $('form').submit(function(ev) {
        console.log('xxx');
        // read the value from the visible INPUT and save it to invisible one
        // ... so that it gets sent to the server
        $('#username').val($('.username').val());
        $('#password').val($('.password').val());
      });
    </script>

  </body>
</html>

rodilla-cola
fuente
Windows Firefox 57.0.2 (64 bits) todavía sugiere guardar la contraseña después de implementar esto.
Panu Haaramo
bueno, esto fue solo un truco, que podría dejar de funcionar en cualquier momento :)
knee-cola
¡esta es la mejor opcion! simplemente borre el campo de contraseña antes de enviar: $ ('. contraseña'). val ('')
ebelendez
2

Mi solución alternativa js (jquery) es cambiar el tipo de entrada de contraseña a texto en el envío del formulario . La contraseña podría ser visible por un segundo, así que también oculto la entrada justo antes de eso. Prefiero no usar esto para los formularios de inicio de sesión , pero es útil (junto con autocompletar = "off"), 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).

ovalek
fuente
1
Esto realmente funciona. Esto evita que el navegador guarde la contraseña. Para evitar mostrar la contraseña, puede ajustar el campo de entrada en un div oculto. Y ya puede hacerlo si se carga el DOM, no es necesario esperar hasta que envíe el formulario.
Ferry Kranenburg
Funciona en IE 11.0.9600.18161!
Lu55
Eso es verdad. Ahora probé esto en FF 44.0.2 y este truco ya no funciona ... qué pena. En Chrome esto todavía funciona.
ovalek
Puede reemplazar la entrada [type = submit] o button [type = submit] con un botón normal [type = button] y hacerlo en el controlador onclick. Si no hay [type = submit] en el formulario, también evitará que el formulario se envíe con la tecla Intro y que aparezca el mensaje para guardar la contraseña.
Steven Don
2

Probé muchas soluciones. Nombre de campo de contraseña dinámica, campos de contraseña múltiples (invisibles para los falsos), cambiando el tipo de entrada de "texto" a "contraseña", autocompletar = "off", autocomplete = "nueva contraseña", ... pero nada lo resolvió con reciente navegador.

Para deshacerse de la contraseña, recuerde que finalmente traté la contraseña como campo de entrada y "borré" 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 la contraseña no se recuerda. También depende de tener Javascript activado.

Tendrás que estimar el riesgo de utilizar la opción propuesta debajo de recordar contraseña del navegador.

Si bien el usuario puede administrar (deshabilitar por sitio) el recuerdo de contraseña, está bien para una computadora personal, no para una computadora "pública" o compartida.

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

<input style="background-color: rgb(239, 179, 196); color: black; text-shadow: none;" name="password" size="10" maxlength="30" onfocus="this.value='';this.style.color='black'; this.style.textShadow='none';" onkeypress="this.style.color='transparent'; this.style.textShadow='1px 1px 6px green';" autocomplete="off" type="text">
Cedric Simon
fuente
1

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

El único inconveniente de usar este atributo es que no es estándar (funciona en los navegadores IE y Mozilla), y causaría un error en la validación XHTML. Sin embargo, creo que este es un caso en el que es razonable romper la validación. ( fuente )

Debo 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.

Joseph Pecoraro
fuente
Tengo este problema de validación según los estándares w3c. La cuestión es que quiero esta funcionalidad para un sitio web de banca móvil. Supongo que los navegadores móviles son lo suficientemente estrictos y a veces pueden estropear el formulario si se está utilizando algún atributo no válido. ¿Qué me recomiendan en este caso?
pide el
2
Creo que es un viejo estilo de pensamiento. Muchos navegadores móviles recientes se basan en WebKit y admiten o ignoran con gracia este atributo. No sé cómo otros países, o los navegadores en teléfonos celulares más antiguos manejan esto, pero manejar con gracia atributos / elementos que no se conocen es fundamental para un buen navegador. Es "pruebas futuras" para que el navegador no se rompa a medida que la web evoluciona. Puede retrasarse (no implementar nuevas funciones) pero no se romperá. Espero que ayude =)
Joseph Pecoraro
1
Debería ser más bien un comentario a la respuesta referida que una respuesta a la pregunta misma.
viam0Zah
1

Lo intenté arriba autocomplete="off"y, sin embargo, todo fue exitoso si está usando angular js, mi recomendación es ir con el botón y el clic ng.

<button type="button" class="" ng-click="vm.login()" />

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

Gracias por la pregunta y las respuestas.

Lasitha Benaragama
fuente
Obviamente, esto se rompe al presionar la tecla entero returnpara enviar un formulario.
8eecf0d2
0

Una forma que sé es usar (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á vinculada a JavaScript.

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

Huppie
fuente
El hash en el lado del cliente no sustituye al hash en el lado del servidor. No estoy seguro de si es de alguna ayuda (si se hace además).
Brilliand
2
Permitir el hash en el lado del cliente es peligroso porque significa que un atacante no necesita descifrar la contraseña del hash, solo puede usar el hash para iniciar sesión. El hash se convierte en una contraseña equivalente.
rjmunro
Estoy de acuerdo con Brilliand en que el hash en el cliente es útil solo si también tiene un hash en el servidor antes de guardar la contraseña en su base de datos. Sin embargo, tener un hash en el lado del cliente puede ayudar a una cierta cantidad de problemas con los hombres en el medio. Dicho esto, dado que el código estará disponible (al menos en sitios públicos) para los piratas informáticos, probablemente no sea tan útil como parece.
Alexis Wilke
0

El verdadero problema es mucho más profundo que simplemente agregar atributos a su HTML: esta es una preocupación de seguridad común, es por eso que la gente inventó las llaves de hardware y otras locuras para la seguridad.

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

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

Entonces, o tiene una política de seguridad loca con claves de hardware (como, algunos bancos ofrecen para la 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 contra qué está tratando de protegerse:

  1. Acceso no 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ña, etc.
  2. Oler credencial. HTTPS es IMPRESCINDIBLE si las personas acceden a su aplicación web desde puntos de acceso Wi-Fi públicos, etc. Mencione que incluso teniendo HTTPS, sus usuarios necesitan cambiar sus contraseñas regularmente.
  3. Ataque interno. Hay dos ejemplos, comenzando por el simple robo de sus contraseñas del navegador o las que ha escrito en algún lugar del escritorio (no requiere ninguna habilidad de TI) y terminando con la falsificación de sesiones e interceptando el tráfico de la red local (incluso encriptado) y más acceso a la aplicación web como si fuera otro usuario final.

En esta publicación en particular, puedo ver requisitos inadecuados para el desarrollador que nunca podrá resolver debido a la naturaleza del problema: la seguridad del usuario final. Mi punto subjetivo es que el desarrollador básicamente debería decir NO y señalar el problema de requisitos en lugar de perder el tiempo en tales tareas, honestamente. Esto no hace que su sistema sea más seguro, sino que llevará a los casos con pegatinas en los monitores. Desafortunadamente, algunos jefes solo escuchan lo que quieren escuchar. Sin embargo, si fuera usted, trataría de explicar de dónde viene el problema real, y que autocompletar = "off" no lo resolvería a menos que obligue a los usuarios a mantener todas sus contraseñas exclusivamente en su cabeza. El desarrollador por su parte no puede proteger a los usuarios por completo,

ruruskyi
fuente
0

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

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

    <input type="password" name="password[]" style="display:none" />
    
  2. Use la misma matriz para el campo de contraseña real.

    <input type="password" name="password[]" />
    

El navegador (Chrome) puede solicitarle "Guardar 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, el espacio cero en la matriz, dejando el primer espacio en blanco.

Intenté definir la matriz, como "contraseña [parte2]", pero aún así lo recordaba. Creo que lo descarta si es una matriz no indexada porque no tiene más remedio que soltarlo en el primer lugar.

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

echo $_POST['password'][1];
Miguel
fuente
1
Con esto, está ocultando un problema de seguridad: el hash de la contraseña todavía se almacena en la memoria caché del navegador.
Alexander Burakevych
1
¿Podrías aclararlo por favor? La contraseña se enviaría como texto sin formato mediante POST. Por lo que he leído, las solicitudes POST no se pueden almacenar en caché. ¿Estás diciendo que hay una alternativa al uso de POST para enviar datos? ¿O está diciendo que la contraseña se almacena en el navegador, porque no está almacenando la contraseña sino el valor vacío al comienzo de la matriz, ha probado este método?
Mike
0

Dado que la mayoría de las autocompletesugerencias, incluyendo la respuesta aceptada, no hacer el trabajo en los navegadores web de hoy (encargados de la contraseña es decir, del navegador ignoran autocomplete), una solución más novedosa es intercambiar entre passwordy texttipos y hacer que el color de fondo que coincida con el color del texto cuando el campo es un campo de texto sin formato, que continúa ocultando la contraseña mientras es un campo de contraseña real cuando el usuario (o un programa como KeePass) ingresa una contraseña. Los navegadores no solicitan guardar contraseñas almacenadas en campos de texto sin formato.

La ventaja de este enfoque es que permite una mejora progresiva y, por lo tanto, no requiere Javascript para que un campo funcione como un campo de contraseña normal (también puede comenzar con un campo de texto sin formato y aplicar el mismo enfoque, pero eso no es realmente HIPAA Compatible con PHI / PII). Este enfoque tampoco depende de formas / campos ocultos que no necesariamente se envían al servidor (porque están ocultos) y algunos de esos trucos tampoco funcionan en varios navegadores modernos.

Complemento jQuery:

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

Código fuente relevante del enlace anterior:

(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

Haga clic en "Agregar entrada" en el menú y luego desplácese hasta la parte inferior de la página para "Módulo: Detener el Administrador de contraseñas".

Descargo de responsabilidad: si bien este enfoque funciona para personas videntes, puede haber problemas con el software del lector de pantalla. Por ejemplo, un lector de pantalla puede leer la contraseña del usuario en voz alta porque ve un campo de texto sin formato. También puede haber otras consecuencias imprevistas de usar el complemento anterior. La alteración de la funcionalidad incorporada del navegador web debe hacerse con moderación con la prueba de una amplia variedad de condiciones y casos extremos.

CubículoSoft
fuente
-1

¿Hay alguna forma de que un sitio le diga al navegador que no ofrezca recordar contraseñas?

El sitio web le dice al navegador que es una contraseña mediante el uso <input type="password">. Entonces, si debe hacer esto desde la perspectiva de un sitio web, entonces tendría que cambiar eso. (Obviamente no recomiendo esto).

La mejor solución sería que el usuario configure su navegador para que no recuerde las contraseñas.

Joseph Pecoraro
fuente
3
¿Cómo es obvio que no recomienda cambiar un campo de tipo de entrada? Sería útil una elaboración de los problemas de seguridad.
Karl
1
@karl: porque tener que escribir la contraseña al aire libre permite "navegar por el hombro", el proceso de obtener una contraseña mirando la pantalla mientras se está escribiendo.
David Schmitt
No solo navegar por el hombro humano, sino que el spyware o los virus pueden mirar su pantalla y ver lo que se ha escrito en los campos de texto sin formato.
Karl el
66
@karl: Si tienes spyware / virus en tu computadora, entonces ninguna cantidad de protección contra asteriscos te salvará. No es más difícil para una aplicación instalada interceptar lo que se está escribiendo en un campo de 'contraseña' que hacer lo mismo para un campo de texto sin formato.
Markus Olsson
3
Además, si el navegador ve una entrada de texto regular en lugar de una entrada de contraseña, es probable que guarde la contraseña en la base de datos de autocompletar en lugar de la base de datos de contraseñas ... y luego sugerirla o incluso completarla automáticamente en algún sitio web no relacionado. Así que en realidad estás peor que cuando empezaste.
zwol
-1

Si no desea confiar en el indicador de autocompletar, puede asegurarse de que el usuario escriba en el cuadro utilizando el evento onchange. El siguiente código es un formulario HTML simple. El elemento de formulario oculto password_edited comienza establecido en 0. Cuando se cambia el valor de la contraseña, el JavaScript en la parte superior (función pw_edited) cambia el valor a 1. Cuando se presiona el botón, comprueba el código del valor aquí antes de enviar el formulario . De esa manera, incluso si el navegador lo ignora y completa automáticamente el campo, el usuario no puede pasar la página de inicio de sesión sin escribir el campo de contraseña. Además, asegúrese de dejar en blanco el campo de contraseña cuando se establece el foco. De lo contrario, puede agregar un personaje al final, luego regresar y eliminarlo para engañar al sistema. Recomiendo agregar el autocomplete = "off" a la contraseña además, pero este ejemplo muestra cómo funciona el código de respaldo.

<html>
  <head>
    <script>
      function pw_edited() {
        document.this_form.password_edited.value = 1;
      }
      function pw_blank() {
        document.this_form.password.value = "";
      }
      function submitf() {
        if(document.this_form.password_edited.value < 1) {
          alert("Please Enter Your Password!");
        }
        else {
         document.this_form.submit();
        }
      }
    </script>
  </head>
  <body>
    <form name="this_form" method="post" action="../../cgi-bin/yourscript.cgi?login">
      <div style="padding-left:25px;">
        <p>
          <label>User:</label>
          <input name="user_name" type="text" class="input" value="" size="30" maxlength="60">
        </p>
        <p>
          <label>Password:</label>
          <input name="password" type="password" class="input" size="20" value="" maxlength="50" onfocus="pw_blank();" onchange="pw_edited();">
        </p>
        <p>
          <span id="error_msg"></span>
        </p>
        <p>
          <input type="hidden" name="password_edited" value="0">
          <input name="submitform" type="button" class="button" value="Login" onclick="return submitf();">
        </p>
      </div>
    </form>
  </body>
</html>
Tom
fuente
-1

autocomplete = "off" no funciona para deshabilitar el administrador de contraseñas en Firefox 31 y probablemente tampoco en algunas versiones anteriores.

Vea la discusión en mozilla sobre este tema: https://bugzilla.mozilla.org/show_bug.cgi?id=956906

Queríamos usar un segundo campo de contraseña para ingresar una contraseña de un solo uso generada por un token. Ahora estamos usando una entrada de texto en lugar de una entrada de contraseña. :-(

Andreas Stankewitz
fuente
-1

Me dieron una tarea similar para deshabilitar el llenado automático del nombre de usuario y las contraseñas por navegador, después de muchas pruebas y errores, encontré que la solución a continuación es óptima. Simplemente agregue los siguientes controles antes de sus controles originales.

<input type="text" style="display:none">
<input type="text" name="OriginalLoginTextBox">

<input type="password" style="display:none">
<input type="text" name="OriginalPasswordTextBox">

Esto funciona bien para IE11 y Chrome 44.0.2403.107

Jeque
fuente
-2

autocomplete = "off" funciona para la mayoría de los navegadores modernos, pero otro método que utilicé que funcionó con éxito con Epiphany (un navegador WebKit para GNOME) es almacenar un prefijo generado aleatoriamente en estado de sesión (o un campo oculto, resultó que tenía una variable adecuada en estado de sesión ya), y úsela para alterar el nombre de los campos. Epiphany todavía quiere guardar la contraseña, pero al volver al formulario no completará los campos.

Peter Nelson
fuente
Eso es aún peor que almacenarlos de la manera habitual, ya que ahora el usuario no ve que la contraseña se guardó sin evitar que un atacante extraiga la contraseña de la tienda.
CodesInChaos
-2

No he tenido ningún problema al usar este método:

Use autocomplete = "off", agregue un campo de contraseña oculto y luego otro no oculto. El navegador intenta completar automáticamente el oculto si no respeta autocompletar = "off"

Spechal
fuente
-2

Otra solución es hacer la POST usando una forma oculta donde todas las entradas son de tipo oculto. El formulario visible utilizará la entrada de tipo "contraseña". El último formulario nunca se enviará, por lo que el navegador no puede interceptar en absoluto la operación de inicio de sesión.

Señor del goo
fuente