Empêcher l'utilisateur de trouver le mot de passe par le biais de Firebug/Chrome Dev Tools

Réponse courte: Il ne peut pas être empêché, malheureusement. C'est parce que tous les code côté client (JavaScript) est modifiable par le client lui-même - donc faire un client basé sur le système de sécurité vulnérables.

La seule solution viable que je pense, est de stocker un haché représentation du mot de passe, au lieu du mot de passe brut. Ce sera (si l'on fait abstraction de hachage attaques bruteforce) garder le mot de passe brut coffre-fort.

Une table de hachage est une représentation du texte original, et est non réversible. C'est, à l'origine de la chaîne de caractères ne peut pas être récupéré par n'importe quel algorithme, en utilisant uniquement le hachage. Exemples de hash est MD5 et SHA. Cette technique est couramment utilisé dans les routeurs, où le mot de passe est souvent stocké dans le navigateur.

Clarification: ne Jamais stocker vos mots de passe en texte clair, et si vous souhaitez adopter cette technique de pré-entré le mot de passe; le hachage et/ou le chiffrement doit se produire sur le côté serveur.

Comme il est clientside, il n'y a pas de véritable moyen de l'en empêcher. En termes d'un modèle de sécurité: nous ne pouvons pas faire confiance au client. D'autre part, cependant, il n'y a pas de véritable moyen de mettre en œuvre de façon différente sans l'utilisation d'un tiers de l'appareil.

Si vous êtes prêt à passer par la peine d'avoir un tiers de l'appareil d'aider à l'authentification: le site de générer et d'afficher une valeur aléatoire, que l'appareil demande pour la graine et le mot de passe pour générer un hachage, et de s'authentifier sur le site à l'aide de la table de hachage. Bien sûr, le hash sera toujours visible si vous utilisez un web de débogueur, mais au moins il n'y a aucun point dans le stockage/lecture comme de hachage différentes pour chaque session. Ce n'est pas complètement sécurisé soit, par ailleurs, que cette méthode est sujette à l'attaque à texte clair choisi.

Bravo si vous êtes prêt à passer par tout ce mal si. Je suppose que vous pourriez écrire une application pour cela de disposer d'un smartphone de la fonction en tant que tiers de l'appareil.

    je crois que le problème que vous rencontrez est de plusieurs personnes utilisent le même ordinateur, et si un utilisateur enregistre son mot de passe sur votre site, alors toute autre personne qui visite le site sur le même pc devra être capable de manipuler le champ de révéler le mot de passe.

    Un moyen de prévenir ce problème est de désactiver l'auto-complétion. autocomplete="off" Placez ce code dans l'élément d'entrée et même si le mot de passe est enregistré, il ne devrait pas. <input autocomplete="off" type="text" required="" tabindex="2" class="std_textbox" placeholder="Enter your account password." id="pass" name="pass">

Pros
Vous n'avez pas à vous soucier des utilisateurs partageant les ordinateurs, et les mots de passe étant révélé pour la plupart.

Contre
les Utilisateurs peuvent penser que leurs mots de passe sont enregistrés (et ils peuvent encore enregistrer les mots de passe), mais quand ils viennent à votre site, il ne sera pas affiché.
NOTE Ce n'est pas la pleine preuve de prévenir les utilisateurs de la manipulation de la forme et de récupérer les mots de passe d'autres utilisateurs.

Comme une note de côté, si le site n'est pas actualisé après la saisie d'un mot de passe et nom d'utilisateur, le navigateur web ne vont pas vous demander d'enregistrer le mot de passe. Par exemple, en utilisant un appel ajax au lieu de soumettre le formulaire.

Vous pouvez utiliser JavaScript pour effacer le texte à l'intérieur du champ de mot de passe lorsque la page se charge. Un meilleur style serait d'ajouter le champ lorsque le chargement de la page avec du JavaScript comme ceci:var x = document.createElement("INPUT"); x.setAttribute("type", "mot de passe");

Une alternative à l'autocomplete="off" la saisie semi-automatique alternative Il implique la génération d'un nom à partir de l'arrière-plan et de l'utiliser comme nom de domaines, de telle sorte que la saisie semi-automatique ne saura jamais où mettre vos utilisateurs des données enregistrées

Remarque: je pense que vous devriez éviter de faire ce qu'il va se casser de base de la fonctionnalité de navigateur.

Mais si vous insistez, vous pouvez le faire plus difficile quelqu'un pour révéler le mot de passe par "déléguer" la saisie à un autre champ de saisie et de remplir le champ mot de passe avec des caractères aléatoires.

Ci-dessous est un exemple d'une façon de le faire. Gardez à l'esprit qu'en aucun cas il ne empêcher quelqu'un de récupérer le mot de passe dans le corps de la requête directement ou s'ils trouvent votre "caché" délégué élément.

!function() {

    var passwordEl, delegateEl;

    function syncPassword() {
        passwordEl.value = 
            Array(delegateEl.value.length + 1).join('*');
    }

    function createDelegate() {
        delegateEl = document.createElement('input');
        delegateEl.style.position = 'absolute';
        delegateEl.style.top = '-9999px';

        delegateEl
            .addEventListener('keyup', syncPassword, false);

        document.body.appendChild(delegateEl);
    }

    window.addEventListener('load', function() {
        passwordEl = document.getElementById('passwordId');
        createDelegate();

        //steal the focus from the password input
        passwordEl.addEventListener('focus', function(e) {
            e.preventDefault();
            delegateEl.focus();
        }, false);

        syncPassword(); //clear if was auto completed

    }, false);
}();

Maintenant, vous avez la possibilité de re-remplissage de votre entrée de mot de passe avec le mot de passe correct sur le formulaire de soumission, ou tout simplement avoir votre serveur attendre le mot de passe d'arriver de la déléguée champ.

Si vous avez envie, vous pouvez ajouter le style approprié pour le champ mot de passe lorsque le délégué champ est concentré et donc de donner à l'utilisateur l'impression qu'ils sont encore concentrés sur le champ de mot de passe lui-même.

Mais ne le font pas.

Bien, vous ne pouvez pas.

Mais là encore. Il est un moyen sûr pour empêcher l'utilisateur de ne jamais le voir à l'aide de la console pour Développeur - ne pas afficher le champ de SAISIE qui a le mot de passe.

L'alternative consisterait à imiter le domaine du comportement, de sorte qu'il semble être là, mais ne l'est pas. Je n'ai pas trouvé techniquement de solution encore comment il pourrait être fait, mais ici est un exemple de la manière dont il pourrait être fait: (mise à jour) http://jsfiddle.net/858kef4h/

Dans cet exemple, l'idée est de créer une DIV en fonction pseudofield qui ressemble à de la SAISIE de mot de passe et est à l'écoute des touches de l'utilisateur et l'enregistrement de la valeur d'une variable JavaScript

<div class="pwField">
  <div class="pwData"></div>
  <div class="cursor"><div class="tfarea"></div></div>
</div>

Cette simple hack a juste trois variables d'état pour le mot de passe, l'accent de l'état et le caché textarea

var pw = "", bHasFocus = false, tfArea;

Le "curseur" de la classe est activée /désactivée à l'aide de JavaScript pour émuler réel curseur

setInterval( function() {
   $(".cursor").toggleClass("blink");
},600);

Lorsque la div est cliqué, cela crée un textarea à l'endroit du curseur et se concentre à elle.

$(".pwField").on("click", function() {
    //enable cursor and create element if needed
    $(".pwField").addClass("active");
    if(tfArea) { //if already created, just focus to the field
        tfArea.focus(); 
        bHasFocus = true;
        return;
    }
    tfArea = document.createElement("textarea");
    tfArea.value="";
    $(".tfarea").append(tfArea);
    tfArea.focus();   
    bHasFocus = true;
    $(tfArea).on("blur", function() {
        //disable cursor and exit
        $(".pwField").removeClass("active");
        bHasFocus = false; 
    });
});

Vous pouvez ensuite écouter keyup/keydown et d'enregistrer les valeurs

$(document).keydown(function(  ) {
    if(!bHasFocus) return;
    pw = tfArea.value;
    //print asterisks
    $(".pwData").html( asterisks( pw.length ) );
});

Et lorsque vous êtes prêt à vous connecter, la valeur est dans le "pw" à la variable.

Cette créées dynamiquement TEXTAREA peut passer inaperçu par le système automatique de gestionnaires de mots de passe, car il n'est pas le genre d'ENTRÉE -champ le Mot de passe Gestionnaires s'attendent à voir.

L'utilisateur qui modifie le champ peut naturellement inspecter la valeur de cet élément en utilisant les outils de développement Chrome, mais le point ici est, si le PW manager ne considère pas que le champ mot de passe -champ, il n'est pas de la remplir avec le mot de passe de l'utilisateur précédent.

Je ne recommande pas l'utilisation de ce, de ce été fait juste de la curiosité. L'idée était de montrer que, même si vous ne pouvez pas empêcher l'utilisateur de voir les éléments, vous pouvez toujours être en mesure de cacher le résultat de Gestionnaires de mots de Passe. Mais comme le dit le vieil adage, "vous pouvez tromper certains d'entre eux de temps en temps, mais pas tous d'entre eux tout le temps".

L'expérience de l'utilisateur n'est pas le même qu'avec l'entrée standard, mais il pourrait être amélioré. Un problème est aussi que, même si l'on voulait éviter que le mot de passe pour être montré, que peut-être ce que les utilisateurs veulent vraiment. Ils veulent peut-être de l'utilisateur, le Gestionnaire de Mot de passe. Mais dans ce cas, vous êtes hors de la chance de toute façon.

Il peut aussi y avoir des problèmes avec le clic, focus et blur avec les différents navigateurs, ils peuvent ne pas fonctionner avec les appareils mobiles que vous attendez. Si ce genre de hack est déjà utilisé, vous devriez soigneusement testé. Il pourrait être utilisé, si vous savez exactement quel type de navigateurs, les utilisateurs utilisent et vous savez qu'ils ont JavaScript activé.

EDIT: j'ai testé l'approche avec certains appareils mobiles et il semblait un peu de travail, mais avec l'iPad, et a remarqué que le passage de la caché textarea va encore créer un curseur visible et de modifier le facteur de zoom, de sorte que maintenant le caché textarea est placé à l'intérieur de la pseudocursor DIV et le zoom doit suivre.

La prémisse de cette question est que l'ordinateur client est compromise et est utilisé par quelqu'un qui ne devrait pas avoir accès. En supposant qu'un gestionnaire de mot de passe est en cours d'utilisation (tels que google Chrome) qui ne nécessite pas de mot de passe principal avant chaque ouverture de session sous forme d'auto-remplissage, il n'y a rien que vous pouvez faire pour empêcher l'attaquant d'accéder à des comptes.

Que vous essayez de résoudre un problème au niveau de l'application lorsque le problème de l'accès est plus profond que cela.

Supposons que Bob oublie de se déconnecter de son ordinateur. Un attaquant (Eve) bute sur sa ouvrir une session Windows et veut accéder à son compte PayPal. Bob utilise un gestionnaire de mot de passe pour plusieurs comptes, y compris son Gmail, Paypal, et Reddit comptes. Supposons que PayPal a pris niveau de l'application des précautions pour prévenir la Veille de l'apprentissage de Bob le mot de passe à partir d'un gestionnaire de mot de passe de l'auto-remplissage. Eve pense qu'elle va seulement être en mesure d'avoir le contrôle de Bob compte PayPal pour aussi longtemps qu'il le faudra pour Bob de retour. Mais alors, Eve avis de PayPal réinitialisation de mot de passe fonctionnalité de lien. Bob compte de courrier électronique est également compromise en raison de son mot de passe car c'est aussi dans le gestionnaire de mot de passe. Avec l'accès à Bob compte de courrier électronique, Eve peut réinitialiser l'une des Bob les mots de passe qu'elle veut. Elle pourrait maintenir l'accès par l'installation d'un keylogger sur l'ordinateur de Bob.

Ligne de fond, les problèmes de sécurité que vous essayez d'adresse au-delà de votre pouvoir d'adresse (en supposant un classique nom d'utilisateur mot de passe du modèle). Même sans présumer de rien au sujet de votre application, Eve a un accès physique à l'ordinateur de Bob, ainsi elle pourrait compromettre dans une multitude de façons.

Si vous faites vos utilisateurs d'utiliser l'authentification à deux facteurs (envoyer un code par sms via Twilio), de les faire transporter un matériel clé usb, etc...vous permettront d'accroître la sécurité et d'éviter le mot de passe du gestionnaire de problème à portée de main.

Mais en fin de compte, vous faites face à un compromis de sécurité et de convivialité. Si Bob est trop paresseux/distrait/apathie/négligent de se déconnecter de son PC, aucun montant de JavaScript que vous écrivez peut le sauver.