Type d'entrée = mot de passe, ne laissez pas le navigateur se souvenir du mot de passe

101

Je me souviens avoir vu un moyen de faire en <input type="password" />sorte que le navigateur n'invite pas l'utilisateur à enregistrer le mot de passe. Mais je dessine un blanc. Y a-t-il un attribut HTML ou une astuce JavaScript qui fera cela?

DavGarcia
la source
4
Duplicate of stackoverflow.com/questions/32369/…
Jon Skeet

Réponses:

123

Essayez d'utiliser autocomplete="off". Je ne sais pas si tous les navigateurs le prennent en charge. Documents MSDN ici .

EDIT : Remarque: la plupart des navigateurs ont abandonné la prise en charge de cet attribut. Voir Est-ce que autocomplete = "off" est compatible avec tous les navigateurs modernes?

C'est sans doute quelque chose qui devrait être laissé à l'utilisateur plutôt qu'au concepteur du site Web.

Tvanfosson
la source
2
Vous pouvez également fournir la page avec HTTPS et via l'en-tête HTTP ou la balise META empêcher la mise en cache. De cette façon, le mot de passe ne sera pas non plus stocké (au moins dans Internet Explorer).
doekman
En ce qui concerne la validation, HTML5 ajoute l'attribut de saisie semi-automatique à la spécification, donc tout va bien maintenant
VictorySaber
9
Remarque pour les futurs lecteurs: tous les principaux navigateurs s'orientent vers l'ignorance de l'attribut. (voir stackoverflow.com/a/21348793/37706 )
rdans
@RyanDansie merci pour l'avoir signalé. J'ai mis à jour la réponse. La vieille réponse est ... ancienne.
tvanfosson
8
"C'est sans doute quelque chose qui devrait être laissé à l'utilisateur plutôt qu'au concepteur du site Web." il y a des raisons techniques et non techniques à cela. Les mots de passe à usage unique ne doivent pas être mémorisés, par exemple. Les sites bancaires avec "entrez le premier chiffre de votre code PIN" en est un autre. N'oubliez pas qu'un analyste commercial peut décider qu'il veut un champ de mot de passe et retirer le choix du développeur.
Sprague
61

<input type="password" autocomplete="off" />

Je voudrais simplement ajouter qu'en tant qu'utilisateur, je pense que c'est très ennuyeux et un problème à surmonter. Je recommande fortement de ne pas l'utiliser car cela aggravera probablement vos utilisateurs.

Les mots de passe ne sont déjà pas stockés dans la MRU, et les machines publiques correctement configurées n'enregistreront même pas le nom d'utilisateur.

matpie
la source
23
+1 pour "n'ennuyez pas vos utilisateurs". C'est exactement ce que fait ce genre de fonctionnalité. Tout comme les sites qui forcent la mise en cache, le bouton de retour efface le formulaire. EXTRÊMEMENT irritant.
cletus
6
+1 Je suis tout à fait d'accord. C'est pour une page de modification du profil client par l'administrateur où vous n'entrez un mot de passe que si vous avez l'intention de le changer. De cette façon, les administrateurs ne modifient pas le mot de passe chaque fois qu'ils vont modifier les informations du client.
DavGarcia
14
Il est très utile pour les champs de numéro de carte de crédit. Le formulaire de PayPal est stocké dans chaque navigateur et toute personne utilisant votre ordinateur peut saisir à nouveau toutes les données, vous devez donc supprimer manuellement tous les champs mémorisés.
Egor Pavlikhin
31
Sur un formulaire où l'utilisateur peut définir un mot de passe qui n'a rien à voir avec sa connexion, l'activation de la saisie semi-automatique est en fait l'option la plus ennuyeuse - le navigateur peut proposer d'enregistrer un mot de passe avec lequel il ne peut rien faire. De plus, si la sécurité est un problème sensible, je ne suppose pas que toutes les machines publiques sont correctement configurées.
jrb
3
J'utilise ceci pour un mot de passe à usage unique. Comme jrb l'a dit, ce serait très ennuyeux si le navigateur le stockait.
Danation
12

J'ai résolu d'une autre manière. Vous pouvez essayer ceci.

<input id="passfld" type="text" autocomplete="off" />
<script type="text/javascript">
// Using jQuery
$(function(){                                               
    setTimeout(function(){
        $("input#passfld").attr("type","password");
    },10);
});


// or in pure javascript
 window.onload=function(){                                              
    setTimeout(function(){  
        document.getElementById('passfld').type = 'password';
    },10);
  }   
</script>

#autrement

 <script type="text/javascript">    
 function setAutoCompleteOFF(tm){
    if(typeof tm =="undefined"){tm=10;}
    try{
    var inputs=$(".auto-complete-off,input[autocomplete=off]"); 
    setTimeout(function(){
        inputs.each(function(){     
            var old_value=$(this).attr("value");            
            var thisobj=$(this);            
            setTimeout(function(){  
                thisobj.removeClass("auto-complete-off").addClass("auto-complete-off-processed");
                thisobj.val(old_value);
            },tm);
         });
     },tm); 
    }catch(e){}
  }
 $(function(){                                              
        setAutoCompleteOFF();
    });
</script>

// vous devez ajouter l'attribut autocomplete = "off" ou vous pouvez ajouter la classe .auto-complete-off dans la zone de saisie et en profiter

Exemple:

  <input id="passfld" type="password" autocomplete="off" />
    OR
  <input id="passfld" class="auto-complete-off" type="password"  />
Sarwar Hasan
la source
4
Cela empêche le navigateur de stocker le mot de passe au lieu d'empêcher la saisie semi-automatique, ce qui est une meilleure solution dans mon scénario.
Pau Fracés
Merci, j'ai travaillé pour moi sur le dernier chrome. Veuillez noter: utilisé sur un système interne où seul Chrome est autorisé, faites plus de tests si vous l'utilisez sur un site de production.
Izion
@AntoVinish, j'espère que ma dernière solution fonctionnera dans Firefox 40.
Sarwar Hasan
7

J'ai essayé ce qui suit et il semble que cela fonctionne avec n'importe quel navigateur:

<input id="passfld" type="text" autocomplete="off" />

<script type="text/javascript">
    $(function(){  
        var passElem = $("input#passfld");
        passElem.focus(function() { 
            passElem.prop("type", "password");                                             
        });
    });
</script>

Cette méthode est beaucoup plus sûre que l'utilisation de techniques de temporisation, car elle garantit que le champ de saisie cédera au mot de passe lorsque l'utilisateur le concentre.

Apostolidis
la source
5

En ce qui concerne les problèmes de sécurité, voici ce qu'un consultant en sécurité vous dira sur l'ensemble du problème du terrain (cela provient d'un véritable audit de sécurité indépendant):

Saisie semi-automatique HTML activée - La saisie semi-automatique est activée pour les champs de mot de passe dans les formulaires HTML. La plupart des navigateurs ont la possibilité de mémoriser les informations d'identification des utilisateurs saisies dans les formulaires HTML.

Risque relatif: faible

Systèmes / appareils concernés: o https: // * ** * *** /

Je conviens également que cela devrait couvrir tout domaine contenant des données véritablement privées. Je pense qu'il est correct de forcer une personne à toujours taper ses informations de carte de crédit, son code CVC, ses mots de passe, ses noms d'utilisateur, etc. chaque fois que ce site va accéder à tout ce qui devrait être sécurisé [universellement ou par des exigences de conformité légale]. Par exemple: formulaires d'achat, sites bancaires / de crédit, sites fiscaux, données médicales, fédérales, nucléaires, etc. - et non des sites comme Stack Overflow ou Facebook.

D'autres types de sites - par exemple TimeStar Online pour les points d'entrée et de sortie du travail - c'est stupide, puisque j'utilise toujours le même PC / compte au travail, que je ne peux pas enregistrer les informations d'identification sur ce site - curieusement, je peux sur mon Android mais pas sur un iPad. Même les PC partagés, ce ne serait pas trop grave car pointer pour quelqu'un d'autre ne fait vraiment rien d'autre qu'ennuyer votre superviseur. (Ils doivent entrer et supprimer les poinçons erronés - choisissez simplement de ne pas enregistrer sur les PC publics).

Michael
la source
5
Ajoutez simplement un commentaire ici pour une raison pour laquelle vous ne voudriez pas enregistrer un mot de passe. Je gère un site Web avec des comptes d'utilisateurs où les administrateurs peuvent modifier le mot de passe d'un utilisateur. Le client est actuellement furieux que Chrome propose d'enregistrer le mot de passe saisi sur le formulaire "modifier le mot de passe" à chaque fois pour chaque utilisateur , car il identifie à tort le formulaire de modification de l'utilisateur comme un formulaire de connexion. Donner des instructions simples comme «cliquez simplement sur Ne jamais retenir le mot de passe» les dépasse, apparemment.
charredUtensil
5
<input type="password" placeholder="Enter New Password" autocomplete="new-password">

Voici.

Bhaumik Thakkar
la source
2
C'est comme ça, il existe de nombreuses solutions de contournement, et c'est aussi simple que cela, testé avec la dernière version de Firefox (v67) et Chrome (75).
Mariano Ruiz
Chrome 80 proposera toujours de se souvenir du mot de passe après avoir soumis le formulaire.
Bouke le
4

Voici la meilleure réponse et la plus simple! Mettez un champ de mot de passe supplémentaire devant votre inputchamp et définissez le display:none, de sorte que lorsque le navigateur le remplit, il le fasse dans un inputque vous ne vous souciez pas.

Change ça:

<input type="password" name="password" size="25" class="input" id="password" value="">

pour ça:

<input type="password" style="display:none;">
<input type="password" name="password" size="25" class="input" id="password" value="">
Capitaine fantastique
la source
En fait, cela fonctionne si 2 champs de mot de passe sont dans le formulaire, mais le nouveau navigateur ignore le deuxième mot de passe s'il n'est pas visible et activé; (
Cedric Simon
1
L'utilisation display:nonene fonctionne pas pour moi (Chrome 61 OSX), mais cela fonctionne:<input type="password" style="position: absolute; top: -1000px;">
John Hascall
2

Lisez aussi cette réponse où il utilise cette solution simple qui fonctionne partout (voir aussi le correctif pour Safari mobile):

<input type="password" readonly onfocus="this.removeAttribute('readonly');"/>
Ferie
la source
1

Vous pouvez utiliser JQuery, sélectionnez l'élément par identifiant:

$("input#Password").attr("autocomplete","off");

Ou sélectionnez l'article par type:

$("input[type='password']").attr("autocomplete","off");

Ou aussi:

Vous pouvez utiliser du Javascript pur:

document.getElementById('Password').autocomplete = 'off';
Fernando
la source
1

vous pouvez également l'utiliser comme suit

$('#Password').attr("autocomplete", "off");
setTimeout('$("#Password").val("");', 2000);
Chandrika Prajapati
la source
1

vu que la saisie semi-automatique = off est obsolète, je suggère une solution plus récente.

Définissez votre champ de mot de passe sur un champ de texte normal et masquez votre entrée avec des "disques" en utilisant CSS. le code devrait ressembler à ceci:

<input type="text" class="myPassword" /> 

input .myPassword{
    text-security:disc;
    -webkit-text-security:disc;
    -mox-text-security:disc;
}

Veuillez noter que cela peut ne pas fonctionner correctement sur les navigateurs Firefox et qu'une solution supplémentaire est nécessaire. Pour en savoir plus, cliquez ici: https://stackoverflow.com/a/49304708/5477548 .

La solution a été tirée de ce lien , mais pour se conformer à SO "no-hotlinks" je l'ai résumée ici.

yoad w
la source
0

Dans le cas de la plupart des principaux navigateurs, le fait d'avoir une entrée en dehors de et non connectée à quelque formulaire que ce soit pousse le navigateur à penser qu'il n'y a pas eu de soumission. Dans ce cas, vous devrez utiliser la validation JS pure pour votre connexion et le cryptage de vos mots de passe serait également nécessaire.

Avant:

<form action="..."><input type="password"/></form>

Après:

<input type="password"/>
Cannicide
la source
1
Au fait, c'est une astuce que vous ne devriez probablement pas utiliser. En n'utilisant pas de balise de formulaire, votre code devient HTML4 par défaut et rend plus difficile la validation des comptes de vos utilisateurs.
Cannicide
0

J'ai trouvé les travaux suivants sur Firefox et Chrome.

<form ... > <!-- more stuff -->
<input name="person" type="text" size=30 value="">
<input name="mypswd" type="password" size=6 value="" autocomplete="off">
<input name="userid" type="text" value="security" style="display:none">
<input name="passwd" type="password" value="faker" style="display:none">
<!-- more stuff --> </form>

Tous ces éléments se trouvent dans la section des formulaires. "person" et "mypswd" sont ce que vous voulez, mais le navigateur enregistrera "userid" et "passwd" une fois, et plus jamais car ils ne changent pas. Vous pouvez supprimer le champ "personne" si vous n'en avez pas vraiment besoin. Dans ce cas, tout ce que vous voulez est le champ "mypswd", qui pourrait changer d'une manière connue de l'utilisateur de votre page Web.

Dick Guertin
la source
0

Le seul moyen pour que Firefox, Edge et Internet Explorer désactivent la saisie semi-automatique est d'ajouter autocomplete = "false" dans ma déclaration de formulaire comme:

  <form action="postingpage.php" autocomplete="false" method="post">

et je dois ajouter l'autocomplete = "off" à mon entrée de formulaire et changer le type en texte comme:

     <input type="text" autocomplete="off">

Il semble que ce code html doive être standardisé avec les navigateurs. le type de formulaire = mot de passe doit être révisé afin qu'il remplace les paramètres du navigateur. Le seul problème que j'ai est que j'ai perdu mon masquage d'entrée. Mais du côté positif, l'ennuyeux "ce site n'est pas sécurisé" n'apparaît pas dans Firefox.

pour moi, ce n'est pas un gros problème car l'utilisateur est déjà authentifié et sa partie mon nom d'utilisateur et mot de passe change

drtechno
la source
2
NE FAITES PAS CELA. Les données seront toujours envoyées en clair à travers le réseau, ce qui est tout le problème avec HTTP (pas HTTPS) en premier lieu, d'où votre message d'avertissement "ennuyeux". Le fait que l'utilisateur soit déjà authentifié ne fait aucune différence car un homme au milieu peut toujours voir les données en texte brut et la journalisation côté serveur peut être configurée différemment (pourrait stocker les en-têtes de demande, alors qu'il y a d'autres problèmes si elle aurait stocké POST données sous HTTPS).
Jacob
https crypte le trafic. Si vous l'utilisez dans le cadre d'une application Internet publique, vous le faites quand même. La méthode de publication empêche le bookmarking, et plusieurs Iframes de code php dans un HTML empêchent l'injection d'URL. Techniquement, vous êtes censé mettre votre chemin complet. Si vous déployez, je vous recommande de charger une variable $ _SESSION avec l'URL de base qui est écrite dans le texte au lieu de regarder les variables $ _SERVER. $ _SERVER ['HTTP_HOST'], et $ _SERVER ['PHP_SELF'] ne doivent être utilisés que dans des environnements non publics car les deux ont plusieurs exploits.
drtechno
Btw, mon exemple concerne les systèmes fermés qui ne sont en aucun cas connectés à Internet
drtechno
personne n'a abordé l'utilisation d'un schéma de cryptage exécuté avec "java onclick" puis soumettez le formulaire après la routine de cryptage.
drtechno