Question:
L'envoi du mot de passe à l'adresse e-mail de l'utilisateur est-il sécurisé?
user310291
2012-08-01 15:18:51 UTC
view on stackexchange narkive permalink

Dans quelle mesure l'envoi de mots de passe par e-mail à un utilisateur est-il sécurisé, puisque les e-mails ne sont pas sécurisés par HTTPS.

Quelle est la meilleure façon de le sécuriser? Dois-je utiliser le cryptage?

No, no, no, no no! Never ever use plain text passwords in email. Infact never send passwords at all if at all possible.
Worth reading this blog post by Troy Hunt on Tesco, the UK's leading supermarket, sending passwords via email. http://www.troyhunt.com/2012/07/lessons-in-website-security-anti.html
No, never. We even shame those who do at plaintextoffenders.com.
AiliwppmsiCMT Amusing that you posted that - I've been heavily involved in the campaign to get them to fix it! :)
The fact that you can send users their password means you're storing user's password in plain text or at least a reversible cipher. That alone is a cause for red flag.
@user606723 Comment toutes les banques parviennent-elles à demander les lettres x, y et z des mots de passe si elles ne font pas des choses étranges avec elles ou ne les chiffrent pas du tout. Certainement pas hash of salt + pass ...
Les banques @ewanm89: sont les principaux contrevenants en matière de sécurité. Cela dit, il est possible que la question implique l'envoi d'un mot de passe temporaire à l'utilisateur comme mesure de récupération. De nombreux sites le font, puis vous obligent à le modifier dès que vous vous connectez.
AilikjegvyCMT banks could in theory at least be storing hashes of every combination of characters they're going to ask for.
In addition to what others have said, do note that e-mail can be encrypted on the wire (HTTPS isn't the only encrypted protocol in common use out there!). My own mail server is set up to do opportunistic `STARTTLS` encryption over SMTP, and the POP server won't even let you log in unless you start a TLS session first. That doesn't address storage, though.
AilirzsemuCMT Actually, the "secret word" challenges like that are usually implemented in a black-box HSM, so you'd have to physically compromise the device to break them.
AilivohaxiCMTörling "_My own mail server is set up to do opportunistic STARTTLS encryption over SMTP_" do you check the TLS certificate? Against what?
@MichaelKjörling et en avez-vous besoin pour tous les courriers envoyés et reçus vers d'autres serveurs ... Qu'en est-il de tout serveur par lequel le courrier est relayé, pouvez-vous les garantir?
Les certificats @curiousguy sont comparés au jeu de certificats CA fourni avec l'implémentation SSL du système d'exploitation.
@ewanm89 Il est configuré pour faire un cryptage ** opportuniste **; ne pas exiger TLS. Exiger TLS pour le trafic SMTP simple vers chaque serveur aléatoire sur Internet serait beaucoup trop brisé, mais quiconque le demande se voit dire que la prise en charge de STARTTLS est disponible via ESMTP et qu'elle est parfois utilisée pour le trafic entrant et sortant. Et * bien sûr * je ne peux rien garantir sur la configuration des autres serveurs de messagerie. Je ne peux prendre en charge que mon petit coin d'Internet. Si je veux une sécurité de bout en bout, j'utilise GnuPG.
@MichaelKjörling "_Si je veux une sécurité de bout en bout, j'utilise GnuPG._" PGP / GPG et TLS sur SMTP ont des portées différentes et protègent différentes choses. Ni l'un ni l'autre n'est supérieur, ni un substitut à l'autre.
@MichaelKjörling "_Les certificats sont vérifiés par rapport au jeu de certificats CA fourni avec l'implémentation SSL du système d'exploitation._" le certificat doit nommer le domaine de l'adresse e-mail de destination?
@curiousguy "* PGP / GPG et TLS sur SMTP ont des portées différentes et protègent des choses différentes. *" C'est un peu mon point. "* le certificat doit nommer le domaine de l'adresse e-mail de destination? *" Non, car un serveur avec un certificat peut potentiellement gérer les e-mails pour de nombreux domaines. Même si le serveur savait d'une manière ou d'une autre quel certificat présenter, une seule transaction SMTP peut impliquer la livraison à des destinataires sur différents domaines sur le même serveur, de sorte qu'il n'aurait aucun moyen de savoir quel certificat présenter à l'avance. ** Quoi qu'il en soit ** cela va loin de la question posée.
Une fois, j'ai trouvé un hébergeur qui avait besoin d'un mot de passe assez sécurisé ... très long (je pense au moins 12 caractères), des chiffres, des caractères spéciaux et ainsi de suite ... J'ai d'abord pensé que c'était sécurisé. Ensuite, ils l'ont envoyé en texte clair. Je n'ai plus hébergé mon site Web là-bas.
@LieRyan: Ce que j'ai vu est le mot de passe * reset *, où le système génère un * nouveau * mot de passe, l'envoie par courrier électronique à l'utilisateur, puis le hache et stocke le hachage dans la base de données. L'étape «e-mail» est toujours aussi peu sûre que n'importe quel e-mail, mais au moins cette séquence ne nécessite pas de stockage de mot de passe réversible.
Même si l'e-mail était sécurisé par une connexion https, il ne serait toujours pas sécurisé d'envoyer un mot de passe. Les e-mails sont stockés en texte brut sauf s'ils sont cryptés. Cela signifie qu'une fois que le client a téléchargé les données, ce n'est pas sécurisé. si nous parlons d'un client Web, alors en théorie, le cache est également vulerable, dépend vraiment du client. Je n'entrerai pas dans les différences ou vraiment l'absence de différences entre SMTP et HTTP, HTTPS, les versions chiffrées sécurisées de SMTP.
Cinq réponses:
Polynomial
2012-08-01 15:33:25 UTC
view on stackexchange narkive permalink

Vous ne devez jamais envoyer de mots de passe en clair, ni les stocker en clair. Vous devez les hacher en utilisant un hachage cryptographique unidirectionnel lent tel que bcrypt ou PBKDF2. Si un utilisateur oublie son mot de passe, vous lui proposez une fonction de «réinitialisation du mot de passe», qui envoie un lien de réinitialisation unique à son compte.

Un schéma comme celui-ci est raisonnable:

  • Hachez tous les mots de passe en utilisant a salt plus bcrypt / PBKDF2 . Consultez mon raisonnement ici. (EDIT, mars 2019: utilisez Argon2)
  • Validez les hachages lors de la connexion.
  • Si un utilisateur oublie son mot de passe, envoyez-lui un lien de réinitialisation, à l'aide d'un jeton de réinitialisation généré aléatoirement stocké dans la base de données. Le jeton doit être unique et secret, donc hachez le jeton dans la base de données et comparez-le lorsque le lien est utilisé.
  • Assurez-vous qu'un jeton ne peut être utilisé que pour réinitialiser le mot de passe de l'utilisateur qui l'a demandé.
  • Une fois le jeton utilisé, il doit être supprimé de la base de données et ne doit plus pouvoir être réutilisé.
  • Faire en sorte que tous les jetons équivalents au mot de passe, y compris les jetons de réinitialisation, expirent après peu de temps, par exemple 48 heures. Cela empêche un attaquant d'exploiter des jetons inutilisés à une date ultérieure.
  • Afficher immédiatement un formulaire pour permettre à l'utilisateur de définir un nouveau mot de passe. N'utilisez pas de mots de passe temporaires générés de manière aléatoire!
  • Faites tout cela via SSL.

Je vous suggère fortement de lire le Guide définitif de l'authentification de site Web par formulaire pour un ensemble complet de directives sur la création de systèmes de connexion sécurisés.

+1 The root problem has nothing to do with email. The root problem is that passwords are being stored in plaintext or with reversible encryption. Solve that problem and the email question answers itself.
Il n'y a rien de mal à envoyer un mot de passe à usage unique en clair. Par exemple, le système vient de créer / réinitialiser un compte pour vous, votre mot de passe initial est quelque chose de créé aléatoirement (`sA2aXUpHcYrm`), valable 1 jour, et lors de la première connexion, vous serez invité à définir votre mot de passe. Vous devez encore évaluer la sécurité de cette fonctionnalité car la création de compte / la réinitialisation du mot de passe est souvent un maillon faible dans vos protocoles de sécurité.
AilijntlyaCMT well in effect that just became no different from a reset link, without the autologin and select account part.
"Si un utilisateur oublie son mot de passe, envoyez-lui un lien de réinitialisation sécurisé à usage unique, à l'aide d'un jeton de réinitialisation généré de manière aléatoire et stocké dans la base de données. Le jeton doit être unique et secret, alors hachez le jeton dans la base de données et comparez-le lorsque le lien est utilisé." Ce n'est pas différent de l'envoi d'un mot de passe temporaire. Il peut même être moins sécurisé à moins que le navigateur des utilisateurs crypte automatiquement les requêtes HTTP (toux Internet Explorer, toux). Au moins avec un mot de passe temporaire, vous pouvez être sûr qu'il sera envoyé via HTTPS, alors qu'avec un jeton intégré dans une requête GET, vous ne pouvez pas.
AilitwvlyaCMT You can't revoke a temporary password as easily, after a set time-frame. It also confuses users, since they'll get a failed login despite the email saying the new password is valid. Furthermore, a reset link forces the user to immediately change their password, which reduces the risk of the temp password being stolen later. I also don't understand your HTTPS argument - why would a link like `https://example.com/reset?token=123...` cause the token to be sent in the clear when logging in?
Le jeton fait partie de la requête HTTP, pas de la charge de données. Si vous utilisiez POST, ce serait probablement OK, mais la plupart des clients de messagerie n'aimeront pas cela. Si vous avez déjà utilisé des sockets sécurisés en java, vous remarquerez qu'il existe un indicateur qui doit être explicitement défini pour chiffrer les arguments HTTP, sinon ils seront envoyés en texte brut même via HTTPS. Je ne sais pas si IE se comporte de cette façon ou non, mais connaissant ses lacunes passées, je ne serais pas disposé à faire des paris.
AilizejcrbCMT Erm, I think you've misunderstood HTTPS. The entire HTTP conversation, including GET parameters, are all encapsulated inside the SSL stream. Go grab a copy of Wireshark and verify it for yourself.
Also, it would be easy enough to do, just track both the password hash and a password expiry timestamp in their user info. Send them the password, and store its hash in the database with a 24h expiry time. If they don't use it, password expires and they must request another reset, if they do, it makes them change their password (which also sets the expiry time back to the default of presumably infinity).
Je vais tester quand je rentre à la maison comment les navigateurs le traitent, mais je suis tout à fait sûr que les paramètres peuvent ne pas être chiffrés (il y a eu un exploit minecraft il y a quelque temps qui impliquait de renifler le mot de passe de la demande de session, qui a été envoyée comme un HTTPS à un serveur de connexion qui renvoie un jeton de session sécurisé, mais les arguments GET ont été envoyés en texte brut).
AilixiszbyCMT That's still overcomplicating things. Besides, a completely random token is *stronger* than a password, since it has `2^n` bits of entropy, where `n` is the length of the token in bits. Compare that to a password, which has much harder-to-compute entropy, and sufficed to say that it'll be a lower number. As far as the Minecraft exploit goes, I'm pretty sure that was due to standard session hijacking, i.e. the login screen was HTTPS, but the subsequent requests were plain HTTP, leaking the session ID.
Pourquoi le jeton doit-il être supprimé de la base de données après utilisation? À proprement parler, il suffit de ne plus permettre son utilisation.
The entire request URL is encrypted in HTTPS; this is why secured domains must be hosted on dedicated IP addresses, as certificate selection can't be based upon the request address since that information isn't available to the server until *after* the session has been negotiated. Even so, if the token is one-time-use-only, what would even be the harm in its being sent in plaintext? By the time anyone could have observed it, it won't work anymore.
AilipjskxuCMT What's the point of keeping it in the database if it can't ever be used again?
@AndreyBotalov: Il est vrai que sa suppression est un détail d'implémentation, mais cela semble la chose la plus pratique à faire (quel serait le but de le conserver?) Plutôt que d'ajouter une logique pour déterminer si le jeton est valide ou non.
Pourquoi hacher le jeton dans la base de données? Contre quelle attaque cela protège-t-il?
AilixmwuloCMT If an attacker breaches the database, he could use the reset tokens to gain access to any account he likes. Hashing the tokens prevents this, since he can't determine what the original token was.
I think it's important to state the reason for all of the password-protection mechanisms: It is to protect users' passwords since they commonly use the same password on multiple sites. If your system is compromised it should not compromise the users' passwords.
@SarelBotha Pas seulement cela. Il est important d'empêcher l'attaquant de pouvoir se connecter à votre système en utilisant les données qu'il capture dans la base de données.
@AdamRobinson Il est intéressant de noter que nous conservons les jetons de réinitialisation, mais les marquons avec une date «Réclamé» car cela nous permet de vérifier le processus après coup.
Je sais qu'il y a des sites qui, lorsque vous vous inscrivez, génèrent un mot de passe initial aléatoire et vous l'envoient par courrier électronique, puis vous vous connectez et vous oblige à le changer.Cela ne semble pas aussi mauvais (par exemple, vous pouvez l'envoyer dès que vous le générez et ne jamais le stocker en texte brut dans votre base de données), mais c'est toujours une mauvaise idée, non?
@Kevin Le problème est que si l'utilisateur ne se connecte pas, il vous reste un compte utilisant un mot de passe qui pourrait être connu d'un attaquant.Cela devient également une condition de concurrence s'ils utilisent un réseau non approuvé.Si vous ne souhaitez pas demander un mot de passe avant la vérification, il devrait y avoir un lien d'activation du délai d'expiration de 24h / 48h pour le compte, puis l'utilisateur devrait être obligé de saisir un mot de passe pour la première fois au moment de l'activation.
@Phil vous n'avez pas besoin de stocker un mot de passe pour l'envoyer.Vous pouvez envoyer l'e-mail de mot de passe au moment où il est généré ou soumis par l'utilisateur.Et fondamentalement, il est stocké, mais il est stocké côté utilisateur, vous ne stockez pas l'e-mail.
@maciejkrawczyk Vous pouvez, mais vous transmettez toujours le mot de passe via un protocole non sécurisé (e-mail).
Thomas Pornin
2012-08-01 16:31:01 UTC
view on stackexchange narkive permalink

Les e-mails ne sont pas sécurisés. L'envoi d'un mot de passe par e-mail est donc un risque de sécurité. Pour atténuer le risque, vous pouvez (dans certaines situations) faire en sorte que le mot de passe envoyé par e-mail soit un mot de passe à usage unique, ce qui déverrouille uniquement la possibilité pour l'utilisateur de sélectionner son propre mot de passe.

C'est ce que font les bons systèmes I-Forgot-My-Password-for-this-Web-site: l'utilisateur clique sur le bouton "bon sang, j'ai oublié mon mot de passe", et un e-mail est envoyé, qui contient une URL ( avec HTTPS) qui intègre un identifiant de session aléatoire et pointe vers une page qui permet à l'utilisateur de choisir un nouveau mot de passe. L'URL est le "mot de passe à usage unique". Avec ce schéma, vous pouvez au moins, du côté serveur, savoir quand l'URL a été utilisée.

Si vous pouvez chiffrer correctement , c'est-à-dire si vous pouvez envoyer un OpenPGP ou Message S / MIME chiffré avec la clé publique de l'utilisateur, puis l'utilisateur a une paire de clés privée / publique: dans ce cas, pourquoi utiliseriez-vous des mots de passe?

Alors, qu'est-ce qui empêche le lien dans l'e-mail d'être détourné par un intermédiaire qui utilise le lien pour réinitialiser le mot de passe de l'utilisateur?
user10211
2012-08-01 15:26:52 UTC
view on stackexchange narkive permalink

C'est une mauvaise pratique d'envoyer des mots de passe à l'utilisateur, car cela signifierait que vous avez une copie en texte clair du mot de passe de l'utilisateur.

Je ne vois aucune bonne raison de le faire. Il existe d'autres moyens plus sûrs d'accomplir ce qui est nécessaire.

Pour une réponse générale concernant la sécurité des e-mails, je vous suggère de lire ce lien, qui contient de bonnes informations.

Si vous DEVEZ envoyer des informations sensibles par e-mail, utiliser un schéma tel que PGP ou d'autres techniques de cryptage pour sécuriser les données.

This is not true; you can create an e-mail to send to the user after the submit to create the password. At a certain point in time, you will always have the password in clear text. While I agree it's not smart to e-mail passwords after creating an account, it doesn't mean the password storage is lacking. You could store the password with PBKDF2 SHA-512 with 10k itterations, this doesn't mean you can't send the password the user picked via e-mail.
@NKCSS: un jour, quelqu'un créera un compte sur votre site Web, en utilisant son courrier de travail partagé, avec son mot de passe personnel.
@NKCSS Certes, vous pouvez envoyer le mot de passe immédiatement avant de le stocker, et votre solution de * stockage * peut être sécurisée. Mais envoyer le mot de passe en clair est toujours ridiculement incertain. Peu importe la possibilité que Lie Ryan a suggérée, vous devriez également vous demander qui pourrait écouter la conversation par e-mail. L'utilisateur peut utiliser un service qui transfère des e-mails en clair entre les serveurs ou vers le client. Voir ma réponse sur [ce sujet] (http://security.stackexchange.com/a/13222/953) pour plus de raisons de ne pas faire confiance aux e-mails pour la confidentialité.
Vaughan Hilts
2012-08-02 02:58:28 UTC
view on stackexchange narkive permalink

Si vous avez le 'mot de passe clair' à envoyer en premier lieu (mis à part le processus d'enregistrement), vous vous trompez. Jamais, jamais stocker le mot de passe en clair! Beaucoup d'entreprises comme Sony Music et autres ont été brûlées ces derniers temps à cause de cela .. et laissez-moi vous dire que les consommateurs ne sont pas satisfaits.

Pour être clair (jeu de mots non prévu), vous ne devez * jamais * envoyer le mot de passe en texte clair - même pas lors de l'inscription. Oui, de par la nature du processus, vous aurez probablement une copie en texte clair (ou crypté) du mot de passe lors de l'enregistrement, mais il doit être immédiatement salé, haché et stocké dans la base de données * sécurisée * - jamais envoyé ou affiché à l'utilisateur.
Katie Campbell
2012-08-01 18:13:18 UTC
view on stackexchange narkive permalink

Faisant écho aux messages précédents, le courrier électronique n'est certainement pas sûr et vous ne devez jamais envoyer par courrier électronique de données sensibles , en particulier les mots de passe. D'autant plus qu'ils ne sont pas cryptés et que nous les trouvons en texte clair, il est extrêmement facile pour quiconque de pirater votre courrier électronique et d'y accéder sur le réseau public.

Si vous ou votre client avez des difficultés à vous souvenir de vos mots de passe, vous devez utiliser un gestionnaire de mots de passe sécurisé. Il s'agit d'un site Web qui héberge une liste de vos mots de passe dans un coffre-fort entièrement crypté. Les bons sont KeePass ou LastPass.

Si vous êtes une entreprise qui tente de renvoyer son mot de passe à ses clients, vous devriez avoir des questions de sécurité configurées auxquelles les clients répondront lors de la création initiale de leur compte. De cette façon, s'ils l'oublient, ils peuvent cliquer sur un lien qui les envoie pour répondre correctement à ces questions et réinitialiser leur mot de passe.

Pour votre propre connaissance, ceci est un blog informatif, qui plaide pour le cryptage et met en garde contre l'utilisation de certains mots de passe http://www.ziptr.com/blog-last-4-digits -ssn-password de Ziptr.

FYI: KeePass is not a "website". It's an application. And, by default, it does not synch to the cloud. I believe there are plugins available to synch it with DropBox or other cloud storage services, though.


ⓘ
Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...