Réglage du type entrées « mot de passe » avec une valeur de soumettre précédente après l'échec de validation

Question

Je crée un walkup créer page de compte pour notre site. J'ai toujours éclairci la valeur par défaut = « » pour un type = « mot de passe » entrée de la paranoïa, après qu'un utilisateur a soumis un formulaire, même si les deux mots de passe correspondent et sont valides. J'ai commencé à penser à cela après notre designer m'a demandé s'il y avait un véritable point de le faire. Je peux certainement l'écho des mots de passe dans la valeur = « champ » après soumettre, si elles ne sont pas l'échec de la validation incriminée, mais y at-il des vulnérabilités associées à cette approche? Nous sommes en défaut à https sur cette page particulière. Je sais que vous pourriez faire un html récrire pour changer le type d'entrée de telle sorte que vous echo'ing dans une entrée non masquée, mais qui semble comme il ne pouvait affecter l'utilisateur local.

formulaire Exemple:

<input type="text" name="username" value="<?php echo $username; ?>">
<input type="password" name="password1" value="">
<input type="password" name="password2" value="">

soumettre, vérifier si le nom d'utilisateur ressemble à un e-mail correcte, les mots de passe correspondent, et les mots de passe a battu nos exigences minimales. Si l'e-mail offense, mais les mots de passe ne sont pas, pourrais-je ajouter ...

<input type="password" name="password1" value="<?php echo $password1; ?>">
<input type="password" name="password2" value="<?php echo $password2; ?>">

... et être sans souci? Et non, je ne suis pas à l'aide register globals. Je les retirer de $ _POST manuellement et faire sanitization d'abord.

Josh

Answer 1

Je suppose que vous ne devriez pas le faire comme un collègue pourrait voler votre mot de passe va à la page de profil et faire une source de vue.

Vous ne devriez probablement pas être en mesure de mettre en œuvre cette fonctionnalité si vos mots de passe sont cryptés en utilisant un hachage sécurisé comme c'est une façon unique et vous ne pouvez pas récupérer le mot de passe d'origine.

Answer 2

Je pense qu'il est une mauvaise idée de le faire de cette façon parce que la source HTML peut être mis en mémoire cache, même si vous dites à l'aide d'en-têtes HTTP qu'il ne doit pas être mis en mémoire cache. Cela dépend des navigateurs, Microsoft et suggère d'inclure une étiquette supplémentaire HEAD après la balise BODY. Microsoft a plus d'informations sur cette "fonctionnalité" pour Internet Explorer.