Disabilita la funzionalità "Salva password" del browser

Una delle gioie di lavorare per un'agenzia sanitaria del governo è quella di occuparsi di tutta la paranoia nel trattare con PHI (Protected Health Information). Non fraintendetemi, sto facendo tutto il possibile per proteggere le informazioni personali delle persone (salute, finanze, abitudini di navigazione, ecc.), Ma a volte le persone diventano un po 'troppo nervose.

Caso in questione: uno dei nostri clienti statali ha recentemente scoperto che il browser offre la comoda funzione per salvare la password. Sappiamo tutti che è lì da un po 'di tempo ed è completamente facoltativo e spetta all'utente finale decidere se utilizzare o meno una decisione intelligente. Tuttavia, al momento c'è un po 'di tumulto e ci viene chiesto di trovare un modo per disabilitare quella funzionalità per il nostro sito.

Domanda : esiste un modo per un sito di dire al browser di non offrire di ricordare le password? Mi occupo di sviluppo web da molto tempo ma non so di essermi mai imbattuto prima.

Qualsiasi aiuto è apprezzato.

Non sono sicuro che funzionerà in tutti i browser, ma dovresti provare a impostare il completamento automatico = "off" sul modulo.

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

Il modo più semplice e semplice per disabilitare i prompt di archiviazione di moduli e password e impedire la memorizzazione nella cache dei dati dei moduli nella cronologia della sessione è utilizzare l'attributo dell'elemento del modulo di completamento automatico con valore "off".

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

Alcune ricerche minori mostrano che questo funziona in IE ma non lascerò garanzie;)

@Joseph : se è un requisito rigoroso passare la convalida XHTML con il markup effettivo (non so perché sarebbe comunque) potresti teoricamente aggiungere questo attributo con javascript in seguito, ma poi gli utenti con js disabilitati (probabilmente una quantità trascurabile della tua base utenti o zero se il tuo sito richiede js) verrà comunque salvata la password.

Esempio con jQuery:

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

Inoltre

autocomplete="off"

Uso

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

per gli ingressi che non si desidera loro di ricordare i dati dei moduli ( username, password, ecc) come mostrato di seguito:

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

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

Testato sulle ultime versioni dei principali browser cioè Google Chrome, Mozilla Firefox, Microsoft Edge, ecc e funziona come un fascino. Spero che sia di aiuto.

Ero stato alle prese con questo problema per un po ', con una svolta unica al problema. Gli utenti con privilegi non potevano far funzionare le password salvate per loro, ma ne avevano bisogno gli utenti normali. Ciò significava che gli utenti privilegiati dovevano effettuare l'accesso due volte, la seconda volta senza applicare password salvate.

Con questo requisito, il autocomplete="off"metodo standard non funziona su tutti i browser, poiché la password potrebbe essere stata salvata dal primo accesso. Un collega ha trovato una soluzione per sostituire il campo password quando era attivo con un nuovo campo password, quindi si è concentrato sul nuovo campo password (quindi collegare lo stesso gestore eventi). Questo ha funzionato (tranne che ha causato un loop infinito in IE6). Forse c'era un modo per aggirare questo, ma mi stava causando un'emicrania.

Alla fine, ho provato ad avere solo nome utente e password al di fuori del modulo. Con mia sorpresa, ha funzionato! Ha funzionato su IE6 e le versioni correnti di Firefox e Chrome su Linux. Non l'ho ancora testato, ma sospetto che funzioni nella maggior parte se non in tutti i browser (ma non mi sorprenderebbe se ci fosse un browser là fuori a cui non importava se non c'era un modulo).

Ecco del codice di esempio, insieme ad alcuni jQuery per farlo funzionare:

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

Bene, è un post molto vecchio, ma continuerò a dare la mia soluzione, che la mia squadra ha cercato di raggiungere a lungo. Abbiamo appena aggiunto un nuovo campo type = "password" di input all'interno del modulo e lo abbiamo racchiuso in div e reso nascosto il div. Assicurati che questo div sia prima dell'immissione effettiva della password. Questo ha funzionato per noi e non ha fornito alcuna opzione Salva password

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;}

È possibile impedire al browser di abbinare i moduli randomizzando il nome utilizzato per il campo password in ogni spettacolo. Quindi il browser vede una password per lo stesso url, ma non può essere sicuro che sia la stessa password . Forse sta controllando qualcos'altro.

Aggiornamento: nota che questo dovrebbe essere in aggiunta all'utilizzo del completamento automatico o di altre tattiche, non una sostituzione per loro, per i motivi indicati da altri.

Si noti inoltre che ciò impedirà al browser di completare automaticamente la password. Non gli impedirà di archiviare la password in qualsiasi livello arbitrario di sicurezza che il browser sceglie di utilizzare.

Utilizzare l'autenticazione a due fattori reale per evitare l'unica dipendenza dalle password che potrebbero essere archiviate in molti più luoghi rispetto alla cache del browser dell'utente.

Il modo più pulito è utilizzare l' autocomplete="off"attributo tag ma Firefox non gli obbedisce correttamente quando si cambia campo con Tab.

L'unico modo per fermarlo è aggiungere un campo di password nascosta falso che inganna il browser per popolare lì la password.

<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"/>

È un brutto hack, perché cambi il comportamento del browser, che dovrebbe essere considerato una cattiva pratica. Usalo solo se ne hai davvero bisogno.

Nota: questo interromperà effettivamente il riempimento automatico della password, poiché FF "salverà" il valore di #prevent_autofill(che è vuoto) e proverà a popolare lì tutte le password salvate, poiché utilizza sempre il primo type="password"input che trova in DOM dopo il rispettivo "nome utente" ingresso.

Ho provato che aggiungendo autocomplete = "off" nel tag del modulo in tutti i principali browser. In effetti, la maggior parte delle persone negli Stati Uniti ha utilizzato IE8 finora.

1. IE8, IE9, IE10, Firefox, Safari funzionano perfettamente.

   Il browser non chiede "salva password". Inoltre, il nome utente e la password salvati in precedenza non venivano compilati.

2. Chrome e IE 11 non supportano la funzione di completamento automatico = "off"
3. FF che supporta il completamento automatico = "off". ma a volte vengono popolate le credenziali salvate esistenti.

Aggiornato l'11 giugno 2014

Infine, di seguito è riportata una soluzione cross-browser che utilizza JavaScript e funziona perfettamente in tutti i browser.

È necessario rimuovere il tag "form" nel modulo di accesso. Dopo la convalida lato client, metti quelle credenziali in forma nascosta e inviale.

Inoltre, aggiungi due metodi. uno per la convalida "validateLogin ()" e un altro per l'ascolto, immettere l'evento mentre si fa clic su invio nella casella di testo / password / pulsante "checkAndSubmit ()". perché ora il modulo di login non ha un tag form, quindi inserisci l'evento che non funziona qui.

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();
 }
}

In bocca al lupo!!!

Non proprio - l'unica cosa che potresti realisticamente fare è offrire consigli sul sito; forse, prima del primo accesso, è possibile mostrare loro un modulo con informazioni che indicano che non è consigliabile consentire al browser di memorizzare la password.

Quindi l'utente seguirà immediatamente il consiglio, annota la password su una nota di post-it e la registra sul suo monitor.

Quello che ho fatto è una combinazione di completamento automatico = "off" e la cancellazione dei campi password usando un javascript / jQuery.

Esempio di jQuery:

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

Usando setTimeout()puoi aspettare che il browser completi il ​​campo prima di cancellarlo, altrimenti il ​​browser si completerà sempre automaticamente dopo aver cancellato il campo.

se autocomplete = "off" non funziona ... rimuovi il tag del modulo e usa invece un tag div, quindi passa i valori del modulo usando jquery al server. Questo ha funzionato per me.

Poiché autocomplete = "off" non funziona per i campi password, è necessario fare affidamento su JavaScript. Ecco una semplice soluzione basata sulle risposte trovate qui.

Aggiungi l'attributo data-password-autocomplete = "off" al campo password:

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

Includi il seguente 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');
        });
    });     
});

Questa soluzione funziona sia per Chrome che per FF.

Proprio così la gente capisce: l'attributo 'completamento automatico' funziona la maggior parte delle volte, ma gli utenti esperti possono aggirarlo usando un bookmarklet.

Avere un browser che salva le tue password in realtà aumenta la protezione contro il keylogging, quindi probabilmente l'opzione più sicura è quella di salvare le password nel browser ma proteggerle con una password principale (almeno in Firefox).

Ho un lavoro in giro, che può aiutare.

Potresti creare un hack di font personalizzato. Quindi, crea un carattere personalizzato, ad esempio con tutti i caratteri come punto / cerchio / stella. Usa questo come carattere personalizzato per il tuo sito web. Controlla come eseguire questa operazione in inkscape: come creare il tuo carattere

Quindi nel modulo di accesso utilizzare:

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

Quindi aggiungi il tuo 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';
}

Abbastanza compatibile con più browser. Ho provato IE6 +, FF, Safari e Chrome. Assicurati solo che il carattere originale convertito non venga danneggiato. Spero che sia d'aiuto?

Il modo più semplice per risolvere questo problema è posizionare i campi INPUT all'esterno del tag FORM e aggiungere due campi nascosti all'interno del tag FORM. Quindi in un listener di eventi di invio prima che i dati del modulo vengano inviati al server copiano i valori dall'input visibile a quelli invisibili.

Ecco un esempio (non è possibile eseguirlo qui, poiché l'azione del modulo non è impostata su uno script di accesso reale):

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

La mia soluzione alternativa a js (jquery) consiste nel modificare il tipo di immissione della password in testo all'invio del modulo . La password potrebbe diventare visibile per un secondo, quindi nascondo anche l'input appena prima. Preferirei non usarlo per i moduli di accesso , ma è utile (insieme al completamento automatico = "off"), ad esempio all'interno della parte amministrativa del sito Web.

Prova a metterlo all'interno di una console (con jquery), prima di inviare il modulo.

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

Testato su Chrome 44.0.2403.157 (64 bit).

Ho testato molte soluzioni. Nome campo password dinamica, campi password multipli (invisibili per falsi), modifica del tipo di input da "testo" a "password", completamento automatico = "off", completamento automatico = "nuova password", ... ma nulla ha risolto con recenti browser.

Per sbarazzarsi della password, ricordo, ho finalmente trattato la password come campo di input e "sfocato" il testo digitato.

È meno "sicuro" di un campo password nativo poiché la selezione del testo digitato lo mostrerebbe come testo non crittografato, ma la password non viene ricordata. Dipende anche dall'attivazione di Javascript.

Avrai una stima del rischio di utilizzare l'opzione sotto proposta vs password ricordare dal navigatore.

Mentre la password ricordata può essere gestita (squilibrata per sito) dall'utente, va bene per un personal computer, non per un computer "pubblico" o condiviso.

Il mio caso è per un ERP in esecuzione su computer condivisi, quindi lo proverò alla mia soluzione di seguito.

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

Markus ha sollevato un ottimo punto. Ho deciso di cercare l' autocompleteattributo e ho ottenuto quanto segue:

L'unico aspetto negativo dell'utilizzo di questo attributo è che non è standard (funziona nei browser IE e Mozilla) e causerebbe il fallimento della convalida XHTML. Penso che questo sia un caso in cui è ragionevole interrompere la convalida. ( fonte )

Quindi dovrei dire che sebbene non funzioni al 100% su tutta la linea, è gestito nei principali browser, quindi è un'ottima soluzione.

Ho provato sopra autocomplete="off"e ancora qualcosa di successo. se stai usando angular js la mia raccomandazione è di andare con il pulsante e il ng-click.

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

Questo ha già una risposta accettata, aggiungendo questo se qualcuno non può risolvere il problema con la risposta accettata, può seguire il mio meccanismo.

Grazie per la domanda e le risposte.

Un modo che conosco è usare (ad esempio) JavaScript per copiare il valore fuori dal campo della password prima di inviare il modulo.

Il problema principale è che la soluzione è legata a JavaScript.

Inoltre, se può essere associato a JavaScript, è possibile anche eseguire l'hashing della password sul lato client prima di inviare una richiesta al server.

Il vero problema è molto più profondo della semplice aggiunta di attributi al tuo HTML: questo è un problema di sicurezza comune, ecco perché le persone hanno inventato chiavi hardware e altre cose folli per motivi di sicurezza.

Immagina di avere autocomplete = "off" perfettamente funzionante in tutti i browser. Ciò aiuterebbe con la sicurezza? Ovviamente no. Gli utenti scriveranno le loro password nei libri di testo, sugli adesivi attaccati al loro monitor dove ogni visitatore dell'ufficio può vederli, salvarli su file di testo sul desktop e così via.

In generale, l'applicazione web e lo sviluppatore web non sono in alcun modo responsabili per la sicurezza dell'utente finale. Gli utenti finali possono proteggere solo se stessi. Idealmente, DEVONO tenere tutte le password in testa e utilizzare la funzionalità di reimpostazione della password (o contattare l'amministratore) nel caso in cui lo abbiano dimenticato. Altrimenti ci sarà sempre il rischio che la password possa essere vista e rubata in qualche modo.

Quindi, o hai una pazza politica di sicurezza con chiavi hardware (come, alcune banche offrono per Internet-banking che fondamentalmente impiega l'autenticazione a due fattori) o fondamentalmente NESSUNA SICUREZZA. Bene, questo è un po 'esagerato ovviamente. È importante capire da cosa stai cercando di proteggere:

1. Accesso non autorizzato. Il modulo di accesso più semplice è praticamente sufficiente. A volte vengono prese misure aggiuntive come domande casuali di sicurezza, CAPTCHA, protezione della password, ecc.
2. Sniffing delle credenziali. HTTPS è NECESSARIO se le persone accedono alla tua applicazione web da hotspot Wi-Fi pubblici ecc. Ricorda che, pur avendo HTTPS, i tuoi utenti devono cambiare regolarmente le loro password.
3. Attacco da insider. Ci sono due molti esempi di questo, a partire dal semplice furto delle password dal browser o da quelle che hai scritto da qualche parte sulla scrivania (non richiede alcuna competenza IT) e termina con la forgiatura della sessione e l'intercettazione del traffico di rete locale (anche crittografato) e accedere ulteriormente all'applicazione Web proprio come se fosse un altro utente finale.

In questo particolare post, posso vedere requisiti inadeguati per lo sviluppatore che non sarà mai in grado di risolvere a causa della natura del problema: la sicurezza dell'utente finale. Il mio punto soggettivo è che lo sviluppatore dovrebbe sostanzialmente dire NO e puntare sul problema dei requisiti piuttosto che perdere tempo su tali compiti, onestamente. Questo non rende assolutamente più sicuro il tuo sistema, ma piuttosto condurrà alle custodie con adesivi sui monitor. Sfortunatamente, alcuni capi sentono solo ciò che vogliono sentire. Tuttavia, se fossi in te, proverei a spiegare da dove proviene il problema reale e che il completamento automatico = "off" non lo risolverebbe a meno che non costringa gli utenti a mantenere tutte le loro password esclusivamente nella loro testa! Lo sviluppatore da parte sua non può proteggere completamente gli utenti,

Di fronte allo stesso problema HIPAA e trovato una soluzione relativamente semplice,

1. Creare un campo password nascosto con il nome del campo come un array.

   <input type="password" name="password[]" style="display:none" />
   

2. Utilizzare lo stesso array per il campo della password effettiva.

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

Il browser (Chrome) potrebbe richiedere di "Salva password", ma indipendentemente dal fatto che l'utente selezioni Salva, al successivo accesso la password popolerà automaticamente il campo della password nascosta, lo slot zero nell'array, lasciando vuoto il primo slot.

Ho provato a definire l'array, come "password [part2]", ma è ancora ricordato. Penso che lo butti via se è un array non indicizzato perché non ha altra scelta che lasciarlo cadere nel primo posto.

Quindi usi il tuo linguaggio di programmazione preferito per accedere all'array, ad esempio PHP,

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

Poiché la maggior parte dei autocompletesuggerimenti, inclusa la risposta accettata, non funziona nei browser Web di oggi (ovvero i gestori delle password del browser Web ignorano autocomplete), una soluzione più innovativa consiste nello scambiare tra passworde texttipi e fare in modo che il colore di sfondo corrisponda al colore del testo quando il campo è un campo di testo semplice, che continua a nascondere la password pur essendo un vero campo password quando l'utente (o un programma come KeePass) sta inserendo una password. I browser non chiedono di salvare le password memorizzate in campi di testo normale.

Il vantaggio di questo approccio è che consente un miglioramento progressivo e quindi non richiede Javascript per un campo per funzionare come un normale campo password (potresti anche iniziare con un campo di testo semplice e applicare lo stesso approccio ma non è proprio HIPAA PHI / PII-compliant). Né questo approccio dipende da moduli / campi nascosti che potrebbero non essere necessariamente inviati al server (perché sono nascosti) e alcuni di questi trucchi non funzionano neanche in molti browser moderni.

Plugin jQuery:

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

Codice sorgente pertinente dal link sopra:

(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));

demo:

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

Fai clic su "Aggiungi voce" nel menu, quindi scorri fino alla fine della pagina fino a "Modulo: Stop Password Manager".

Dichiarazione di non responsabilità: mentre questo approccio funziona per le persone vedenti, potrebbero esserci problemi con il software dello screen reader. Ad esempio, uno screen reader potrebbe leggere ad alta voce la password dell'utente perché vede un campo di testo semplice. Potrebbero esserci anche altre conseguenze impreviste nell'uso del plugin sopra. La modifica della funzionalità del browser Web integrata deve essere eseguita con parsimonia testando un'ampia varietà di condizioni e casi limite.

C'è un modo per un sito di dire al browser di non offrire di ricordare le password?

Il sito Web comunica al browser che si tratta di una password tramite <input type="password">. Quindi, se è necessario farlo dal punto di vista del sito Web, è necessario modificarlo. (Ovviamente non lo consiglio).

La soluzione migliore sarebbe che l'utente configuri il proprio browser in modo che non ricordi le password.

Se non si desidera fidarsi del flag di completamento automatico, è possibile assicurarsi che l'utente digiti nella casella utilizzando l'evento onchange. Il codice seguente è un semplice modulo HTML. L'elemento di modulo nascosto password_edited inizia impostato su 0. Quando il valore della password viene modificato, JavaScript in alto (funzione pw_edited) cambia il valore in 1. Quando si preme il pulsante, controlla qui il codice valueenter prima di inviare il modulo . In questo modo, anche se il browser ti ignora e compila automaticamente il campo, l'utente non può passare la pagina di accesso senza digitare il campo della password. Inoltre, assicurarsi di svuotare il campo della password quando è impostato lo stato attivo. Altrimenti, puoi aggiungere un personaggio alla fine, quindi tornare indietro e rimuoverlo per ingannare il sistema. Consiglio inoltre di aggiungere autocomplete = "off" alla password, ma questo esempio mostra come funziona il codice di backup.

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

autocomplete = "off" non funziona per disabilitare il gestore password in Firefox 31 e molto probabilmente non in alcune versioni precedenti.

Guarda la discussione su mozilla su questo problema: https://bugzilla.mozilla.org/show_bug.cgi?id=956906

Volevamo usare un secondo campo password per inserire una password una tantum generata da un token. Ora stiamo usando un input di testo anziché un input di password. :-(

Mi è stato assegnato un compito simile per disabilitare il riempimento automatico del nome di accesso e delle password tramite browser, dopo molte prove ed errori ho trovato la soluzione di seguito ottimale. Basta aggiungere i controlli di seguito prima dei controlli originali.

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

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

Funziona bene con IE11 e Chrome 44.0.2403.107

autocomplete = "off" funziona per la maggior parte dei browser moderni, ma un altro metodo che ho usato che ha funzionato con successo con Epiphany (un browser basato su WebKit per GNOME) è quello di memorizzare un prefisso generato casualmente nello stato della sessione (o un campo nascosto, mi è capitato di avere una variabile adatta nello stato della sessione) e utilizzarla per modificare il nome dei campi. Epifania vuole ancora salvare la password, ma tornando al modulo non popolerà i campi.

Non ho avuto problemi con questo metodo:

Usa autocomplete = "off", aggiungi un campo password nascosto e poi un altro campo non nascosto. Il browser tenta di completare automaticamente quello nascosto se non rispetta il completamento automatico = "off"

Un'altra soluzione è rendere il POST utilizzando un modulo nascosto in cui tutti gli input sono di tipo nascosto. Il modulo visibile utilizzerà input di tipo "password". Quest'ultimo modulo non verrà mai inviato e quindi il browser non può intercettare affatto l'operazione di accesso.