Disabilita la funzionalità "Salva password" del browser


423

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.


6
Dovresti fornire uno script greasemonkey in modo che le persone possano riattivarlo. Non credo che agli utenti piaccia essere costretti a digitare la password ogni volta ...
ThiefMaster il

14
La domanda merita un voto per essere utile e chiara. D'altra parte non voglio che le persone trovino una soluzione a questo "problema".
Ian Boyd,

11
Questo non è sempre un "problema". Sono venuto qui perché Firefox richiede di salvare una password per un modulo che contiene password WiFi / SSID, non un modulo nome utente / password di accesso. È molto fastidioso e voglio fermarlo.
srd

1
Se le informazioni sono così importanti, dovrebbero essere protette da più di una semplice password.
Sam Watkins,

Un modo in cui sembra funzionare non è usare <form>. Se si utilizza JavaScript per inviare i dati (XHR), non è necessario. Volevo disabilitare in un sistema che utilizza l'autenticazione "one-time-password" (nessun motivo per memorizzarlo). Per le autenticazioni utente / pass, non consiglierei di disabilitare quella funzione.
lepe

Risposte:


322

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

48
Solo un breve commento, poiché questo sta cambiando, HTML5 aggiunge l'attributo di completamento automatico alla specifica, quindi è valido ora.
Tyler Egeto,

11
Cordiali saluti, Microsoft ha deciso che Internet Explorer 11 non sarà più onore autocomplete="off"per input type="password"i campi. msdn.microsoft.com/en-us/library/ie/ms533486%28v=vs.85%29.aspx
JW Lim

6
Proprio come @JWLim ha menzionato il supporto di IE 11 per disabilitare la funzionalità di salvataggio della password, così è Firefox. bugzilla.mozilla.org/show_bug.cgi?id=956906
Gregory Cosmo Haun

3
Firefox (purtroppo) ha seguito l'esempio di Microsoft e ha "rimosso" anche il supporto per il completamento automatico. Per i dettagli, consultare il commento 100 nella seguente discussione del problema: bugzilla.mozilla.org/show_bug.cgi?id=956906
Bouncing Bit

8
Ora, non funziona con Firefox 38+ mozilla.org/en-US/firefox/38.0/releasenotes
Illuminator

44

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.


2
@Murat Yıldız: Devo implementare lo stesso e ho seguito il tuo codice. Funziona bene per me in tutti i browser. Grazie !
Sree,

1
@Sree Sono felice che ti sia stato utile :)
Murat Yıldız

3
Ho appena testato Mozilla Firefox 52.0 , Google Chrome 57.0 , Microsoft Edge 38.1 e funzionando come un fascino! ..
Murat Yıldız

1
Potrebbe essersi verificato un errore in Safari mobile poiché questa risposta lo sta risolvendo stackoverflow.com/questions/2530/…
Ferie

1
Windows Firefox 57.0.2 (64 bit) sta ancora suggerendo di salvare la password dopo averlo implementato.
Panu Haaramo,

37

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>

1
Sembra una buona soluzione. Ha senso poiché il modulo che si invia non include di per sé una password. Suppongo che tu possa avere due moduli, il primo solo per garantire che il nome utente e la password siano visibili in tutti i browser.
Alexis Wilke,

3
mi piace la tua soluzione e ne ho implementata una simile sul mio sito, è ridicolo come oggi i browser non offrano un modo semplice per risolverlo.
AgelessEssence,

Non sono sicuro che sia perché sono bloccato usando jquery 1.6, ma il jquery sopra ha funzionato solo dopo essere stato racchiuso in un $ (document) .ready (function () {});
rgbflawed

L'unica soultion corretta è questa poiché alcuni browser non accettano più il completamento automatico = "off"!
Abadis,

1
ho appena provato questo metodo su Chrome, Opera e Internet Explorer e sembra funzionare, ma non funziona con Firefox in modo inopportuno
chenks

29

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

1
Un vantaggio in questo modo rispetto a quelli che usano input nascosti è che in questo modo una password non viene mai memorizzata in un campo di testo normale
pvgoddijn,

@ whyAto8 Questo non ha funzionato per me in Chrome 47.0.2526.111 ... il trucco per farlo funzionare era aggiungere un altro campo di testo nel div nascosto. Il browser chiede di salvare la password, ma dice "Sei sicuro di salvare questo crendetial?" e quindi mostra un nome utente vuoto e una password vuota. Questo ha funzionato
David Bélanger,

1
perché la soluzione di Ato8 insieme al commento di @David Bélanger ha funzionato per me (nessuna delle altre soluzioni ha funzionato). Vorrei anche ricordare che ho aggiunto i due campi nascosti vuoti PRIMA di quelli effettivamente utilizzati per l'immissione dei dati e che i campi duplicati (nascosti) avevano gli stessi rispettivi nomi. In questo modo Chrome (48.0.2564.103) non ha nemmeno chiesto se fosse necessario salvare una password.
Vadim,

Nessuna combinazione di questo funziona su Chrome 48.0.2564.116. Anche combinato con il commento di DavidBelanger, il popup di Chrome che ti chiede di salvare la password memorizza ancora la password nella cache se fai clic su OK
ChrisO

Ottima risposta .. Per favore, potresti dirmi perché hai detto "Assicurati che questo div sia prima dell'immissione effettiva della password" ? Ho messo quel div dopo quell'attuale inserimento della password e funziona ancora .. Allora perché l'hai detto?
Martin AJ,

16

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


5
[@Joel] (# 32409) che potrebbe impedire il popolamento automatico del modulo ma impedirebbe al browser di chiedere di salvare la password per questo nuovo modulo presunto ?
Joseph Pecoraro,

3
Non credo che funzionerà ora. In FF 13, ho un modulo con diversi campi password, tutti con nomi diversi. FF, una volta salvata una password per quella pagina, inserisce la password salvata in TUTTI i campi della password. Non importa quale sia il nome dei campi (ho "new_password" e "old_password" per esempio, e la password salvata viene scaricata in entrambi). In questa forma particolare non ho un nome utente per il salvataggio della password - solo due campi password, nel caso ciò faccia la differenza.
Jason,

1
Annuisce @Jason, dando al campo password un nuovo UUID per un nome ogni volta che non ha fatto nulla per sconfiggere i tentativi del browser di riempirlo.
FP Freely,

14

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.


2
tra l'altro è autenticazione non autenticazione
Jonathan.

26
@Jonathan Peccato, preferisco l' autenticazione
Ian Boyd il

Un'altra soluzione potrebbe essere l'implementazione di un JavaScript, che chiude forzatamente il browser una volta che l'utente è disconnesso dall'applicazione. Ciò eliminerà la memoria completa del browser e pertanto non è possibile recuperare dati dalla memoria del browser.
Ajay Takur,

13

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.


Che senso ha impedire al browser di compilare la password ma consentirgli di memorizzarla? Induce l'utente a pensare che la sua password non sia memorizzata mentre in realtà sono vulnerabili.
CodesInChaos

In questo modo non memorizzerà la tua password, perché digiti nell'altra casella, che viene ignorata da FF. Invece memorizzerà una stringa vuota.
venimus

@CodesInChaos IMHO dovresti riconsiderare il tuo downvote, perché la tua preoccupazione non è valida
venimus

12

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


Sebbene questa risposta fornisca informazioni utili, in realtà non risponde alla domanda su come impedire ai browser di salvare le password.
JW Lim,

@JW Lim, ho aggiornato la risposta. Per favore, guardaci dentro. Grazie!
Asik,

@Sivakumar, Ok, includi il sistema operativo e la versione di Safari. così che altre persone ne siano consapevoli. stava funzionando nel mio sistema (Windows 8, Safary 5)
Asik

@Asik Safari 8.0.3 e Mac OS 10.10
Sivakumar

7

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.


10
Devi ricordare che questo è un sito governativo e tali cose sono accusate politicamente. Se qualcuno in alto dice "non deve funzionare così", ciò che è realistico non fa parte dell'equazione. Il problema può essere spostato nelle note di post-it, ma la politica su questi è per un reparto diverso da gestire - il problema è stato spostato ;-) E in realtà sono serio.
Jason,

6

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.


3

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.


3

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.


Windows Firefox 57.0.2 (64 bit) sta ancora suggerendo di salvare la password dopo averlo implementato.
Panu Haaramo,

2

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


2
"ma gli utenti esperti possono aggirarlo" , che è applicabile alla maggior parte delle funzionalità dell'applicazione, web o no, e non dovrebbe essere un motivo per limitare il sistema. Le persone possono anche scrivere le loro password sui post-it e metterle sul loro monitor, puoi fare solo così tanto per la sicurezza dal punto di vista dell'applicazione e fornire un comportamento predefinito significativo (non salvarlo localmente) è un inizio.
Niels Keurentjes,

2

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?


1
soluzione davvero accurata c'è un font password qui
andrew

6
Se si utilizza tale soluzione, è necessario tenere conto del fatto che gli utenti possono copiare liberamente il testo immesso in questo campo password simile. Le funzioni di copia e taglio sono disabilitate su campi password reali.

2

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>


Windows Firefox 57.0.2 (64 bit) sta ancora suggerendo di salvare la password dopo averlo implementato.
Panu Haaramo,

beh, questo era solo un trucco, che potrebbe smettere di funzionare in qualsiasi momento :)
ginocchio-cola,

questa è l'opzione migliore! basta cancellare il campo della password prima di inviare: $ ('. password'). val ('')
ebelendez

2

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


1
Questo funziona davvero. Ciò impedisce al browser di salvare la password. Per impedire la visualizzazione della password, è possibile racchiudere il campo di input in un div nascosto. E puoi già farlo se il DOM è caricato, non è necessario attendere fino a quando non invii il modulo.
Traghetto Kranenburg,

Funziona su IE 11.0.9600.18161!
Lu55,

Questo è vero. Ora ho provato questo in FF 44.0.2 e questo hack non funziona più ... che peccato. In Chrome funziona ancora.
Ovalek,

È possibile sostituire l'input [type = submit] o il pulsante [type = submit] con un pulsante normale [type = button] e farlo nel gestore onclick. Se nel modulo non è presente [tipo = invio], verrà impedito l'invio del modulo con la chiave di invio e la visualizzazione della password di salvataggio.
Steven Don,

2

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

1

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.


sto avendo questo problema di convalida secondo gli standard w3c. Il fatto è che voglio questa funzionalità per un sito Web di mobile banking. Suppongo che i browser mobili siano abbastanza rigidi e che a volte possano rovinare il modulo se si utilizzano alcuni attributi non validi. Cosa mi consigliate in questo caso?
chiede l'

2
Penso che sia un vecchio modo di pensare. Molti browser mobili recenti sono basati su WebKit e supportano o ignorano con garbo questo attributo. Non sono a conoscenza di come altri paesi o browser nei telefoni cellulari più vecchi gestiscono questo, ma gestire con garbo attributi / elementi che non sono noti è fondamentale per un buon browser. "Prove future" per il browser non rompersi mentre il web si evolve. Potrebbe rimanere indietro (non implementando nuove funzionalità) ma non si romperà. Spero che aiuti =)
Joseph Pecoraro,

1
Dovrebbe essere piuttosto un commento alla risposta inviata piuttosto che una risposta alla domanda stessa.
viam0Zah,

1

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.


questo ovviamente si interrompe premendo il tasto entero returnper inviare un modulo.
8eecf0d2

0

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.


L'hash sul lato client non sostituisce l'hashing sul lato server. Non sono sicuro se sia di alcun aiuto (se fatto in aggiunta).
Brilliand,

2
Consentire l'hash sul lato client è pericoloso perché significa che un utente malintenzionato non ha bisogno di decifrare la password dall'hash, può semplicemente utilizzare l'hash per accedere. L'hash diventa equivalente a password.
rjmunro,

Concordo con Brilliand che l'hash sul client è utile solo se si dispone anche di un hash sul server prima di salvare la password nel database. Tuttavia, avere un hash sul lato client può aiutare una certa quantità di problemi con gli uomini nel mezzo. Detto questo, poiché il codice sarà disponibile (almeno su siti pubblici) agli hacker, probabilmente non è così utile come potrebbe sembrare.
Alexis Wilke,

0

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,


0

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

1
Con questo stai nascondendo un problema di sicurezza: l'hash della password è ancora memorizzato nella cache del browser.
Alexander Burakevych,

1
Potresti chiarire, per favore? La password verrebbe inviata come testo normale usando POST. Per quanto ho letto, le richieste POST non possono essere memorizzate nella cache. Stai dicendo che esiste un'alternativa all'utilizzo di POST per inviare dati? Oppure stai dicendo che la password è memorizzata nel browser, perché non sta memorizzando la password ma il valore vuoto all'inizio dell'array, hai testato questo metodo?
Mike,

0

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.


-1

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.


3
Come è ovvio che non si consiglia di modificare un campo del tipo di input? Un'elaborazione di problemi di sicurezza sarebbe utile.
Karl,

1
@karl: poiché è necessario digitare la password all'aperto per consentire la navigazione a spalla, il processo di scorrimento della password guardando lo schermo mentre viene digitata.
David Schmitt,

Non solo il surf sulle spalle umane, ma spyware o virus possono guardare il tuo schermo e vedere cosa è stato digitato nei campi in chiaro.
Karl,

6
@karl: se hai spyware / virus sul tuo computer, nessuna protezione da asterisco ti salverà. Non è più difficile per un'app installata intercettare ciò che viene digitato in un campo "password" di quanto non faccia lo stesso per un campo di testo semplice.
Markus Olsson,

3
Inoltre, se il browser vede un normale input di testo anziché un input di password, è probabile che stash la password nel database del modulo di completamento automatico invece del database delle password ... e quindi suggerirla o addirittura compilarla automaticamente su un sito Web non correlato! Quindi in realtà stai anche peggio di quando hai iniziato.
zwol,

-1

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>

-1

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. :-(


-1

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


-2

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.


È ancora peggio che archiviarli nel solito modo, poiché ora l'utente non vede che la password è stata salvata senza impedire a un utente malintenzionato di estrarre la password dall'archivio.
CodesInChaos,

-2

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"


-2

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.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.