Nom d'utilisateur et mot de passe dans l'url https

Lorsque vous mettez le nom d'utilisateur et le mot de passe en avant de l'armée, ces données ne sont pas envoyés de cette façon pour le serveur. Il est plutôt transformé en en-tête de requête selon le schéma d'authentification utilisé. La plupart du temps, cela va être Basic Auth qui je décris ci-dessous. Une semblable (mais nettement moins souvent utilisé) schéma d'authentification est Digest Auth qui fournit de nos jours comparables fonctions de sécurité.

Avec l'Authentification Basique, la requête HTTP à partir de la question va ressembler à quelque chose comme ceci:

GET /HTTP/1.1
Host: example.com
Authorization: Basic Zm9vOnBhc3N3b3Jk

Le hachage comme chaîne de caractères que vous voyez là est créé par le navigateur comme ceci: base64_encode(username + ":" + password).

À l'extérieur de l'HTTPS transfert, cette information est cachée (comme tout le reste sur le site HTTP niveau). Vous devez prendre soin de l'exploitation forestière sur le client et tous les serveurs intermédiaires si. Le nom d'utilisateur sera normalement indiqué dans les logs du serveur, mais le mot de passe ne sera pas. Ce n'est pas garanti si. Lorsque vous appelez cette URL sur le client avec, par exemple,curl, le nom d'utilisateur et le mot de passe sera clairement visible sur la liste des processus et pourrait se retrouver dans l'historique bash fichier.

Lorsque vous utilisez l'approche par ayush, le nom d'utilisateur et le mot de passe toujours transformer en serveur de logs de votre serveur web, serveur d'application, caches, ... sauf si vous configurez votre serveurs pour ne pas les enregistrer. Cela s'applique uniquement aux serveurs d'être capable de lire la http non de données, comme votre serveur d'application si.

Basic auth est standardisé et mis en œuvre par les navigateurs en montrant ce petit nom d'utilisateur/mot de passe s'affiche. Lorsque vous mettez le nom d'utilisateur/mot de passe dans un formulaire HTML envoyé par GET ou POST, vous avez à mettre en œuvre tous les login/logout logique de vous-même (ce qui peut être un avantage). Mais vous devriez jamais de transfert de noms d'utilisateur et mots de passe par les paramètres GET. Si vous devez utiliser des POST à la place. L'empêche de l'enregistrement de ces données par défaut.

Lors de la mise en œuvre d'un mécanisme d'authentification d'un utilisateur/mot de passe formulaire de participation et un cookie de session tel qu'il est couramment utilisé aujourd'hui, vous avez à faire assurez-vous que le mot de passe est soit transportée avec les requêtes POST ou celui de la standardisation des systèmes d'authentification au-dessus seulement.

Concluant, je pourrais dire, que de transférer les données au fil du HTTPS est sûr, aussi longtemps que vous prenez soin que le mot de passe ne tourne pas dans des endroits inattendus. Mais ce conseil s'applique à tout transfert de tout mot de passe en quelque sorte.