Quelle est la manière la plus sûre d'informer un nouvel utilisateur de son mot de passe sur un site Web sur invitation uniquement?
Je développe un site Web où les gens auront des comptes. Cependant, contrairement à la plupart des sites Web, les utilisateurs ne s'inscrivent pas, ils sont plutôt invités par les administrateurs du site. Les administrateurs du site créeront un nouveau profil utilisateur, basé sur leur adresse e-mail, puis souhaiteront que le site leur envoie un e-mail leur indiquant que leur profil est prêt à être utilisé.
Cependant, je ne suis pas sûr du moyen le plus sûr de faire connaître son mot de passe aux utilisateurs. Dans une inscription normale, l'utilisateur entre son mot de passe de choix, qui est haché et stocké. Il ne reste plus qu'à leur envoyer un lien pour vérifier leur adresse e-mail.
Dans notre cas, ils ne s'enregistrent pas, donc ne fournissez pas de mot de passe. Quelle est la façon la plus sûre de procéder?
Cette réponse suggère de leur envoyer un lien vers une page où ils peuvent voir leur mot de passe, mais je ne sais pas si cela présente des avantages par rapport à leur envoi vers une page où ils peuvent entrer leur propre mot de passe. En fait, je pense que cette dernière suggestion est meilleure, comme si le mot de passe a déjà été défini, la page Web peut les informer que le mot de passe a été défini, et si ce n'était pas eux, contacter immédiatement les administrateurs.
Quelle serait la meilleure façon d'informer un nouvel utilisateur de son mot de passe, en termes de sécurité?
La meilleure pratique dans ce cas est de leur envoyer un lien vers une page où ils peuvent définir leur propre mot de passe.
Vous devez vous assurer qu'après avoir utilisé ce lien pour vous inscrire, ce lien ne peut pas être utilisé pour la prise de contrôle de compte. Un moyen d'y parvenir consiste à inclure un jeton à usage unique limité dans le temps dans l'URL.
Vous devez simplement envoyer aux nouveaux utilisateurs créés un lien où ils peuvent définir leur propre mot de passe. Mais pensez aux réflexions suivantes pour éviter les abus, car les mails sont envoyés en texte brut:
- assurez-vous que le lien ne peut être utilisé qu'une seule fois (donc uniquement si l'utilisateur n'a pas encore de mot de passe)
- peut-être définir une date jusqu'à ce que le mot de passe doive être défini, sinon ils doivent demander un nouveau lien
- génération de liens aléatoires, il sera donc (presque) impossible de deviner le lien d'un e-mail
- ajouter une autre étape de vérification (par exemple, leur demander de saisir leur e-mail et/ou leur anniversaire)
D'après mon expérience, cela se fait généralement de deux manières.
Une façon a déjà été décrite par David Waters, donc je n'en parlerai pas.
L'autre façon est de leur envoyer un mot de passe à usage unique, qu'ils devront changer dans un certain délai (généralement une fenêtre de 48 heures).
Avec cette méthode, vous devez vous assurer qu'ils reçoivent un mot de passe aléatoire qui est suffisamment sécurisé pour ne pas être brutalisé, et est unique et ne peut pas être utilisé à nouveau.
Une fois que l'utilisateur se connecte à l'aide de ce mot de passe, le site Web doit le rediriger vers une page où il peut choisir le mot de passe de son choix.
Demandez à vos utilisateurs de faire une première authentification via un OpenID ou un fournisseur Oauth, comme Google, Microsoft, Amazon, etc.) pour vérifier leur identité. Cela évite tout problème de sécurité lié à l'envoi par e-mail d'un mot de passe à l'utilisateur.
Les utilisateurs ont donc un compte avec une adresse e-mail associée, mais n'ont pas défini leur mot de passe. C'est exactement la même situation que lorsqu'ils ont défini mais oublié leur mot de passe.
Mettez donc en œuvre une procédure de "mot de passe oublié" qui permet à un utilisateur de demander un lien par e-mail pour définir un nouveau mot de passe. Demandez ensuite à vos utilisateurs d'utiliser cette procédure pour définir leur mot de passe la première fois qu'ils utilisent leur compte. Vous pouvez définir leurs mots de passe sur une chaîne générée aléatoirement lors de la création de leurs comptes.
Cela vous permet de créer leurs comptes à votre propre rythme, sans avoir à générer une URL unique ou expirante alors. S'ils n'utilisent jamais leur compte, leur mot de passe reste cette chaîne générée aléatoirement, qui devrait être suffisamment sécurisée contre les tentatives de forçage brutal.
De mon point de vue, les e-mails sont un canal de communication couramment utilisé. Il est généralement considéré comme sécurisé, ce qui pourrait être vrai si tout le monde mettait les choses en place, comme l'utilisation de connexions SSL/TLS pour POP3/IMAP ou SMTP. En réalité, tout le monde ne sait pas à quoi servent ces techniques et ne fait qu'aller de l'avant sans sécurité de transport et donc mal configurer son système. Alors, comment surmonter ce problème?
Je dirais qu'il y aura un moyen plus sûr de fournir un compte à votre client. Pensez à votre téléphone. Pas besoin de le configurer et ça marche. Il n'y aura donc pas de problème de mauvaise configuration. Alors réfléchissons un peu. Je sais SMS Le jeton et les appels ne sont pas sûrs non plus, mais il est un peu plus difficile d'obtenir un SMS d'un autre téléphone redirigé vers le téléphone des pirates informatiques. Alors pourquoi ne pas utiliser le numéro de téléphone pour leur envoyer un mot de passe unique qu'ils utilisent sur une page de configuration et terminer leur inscription? Je dirais que ce sera plus sûr que d'utiliser les e-mails.
Quoi qu'il en soit, si vous souhaitez utiliser les e-mails, je ne définirais pas le mot de passe de l'utilisateur et ne le lui enverrais pas. Et j'ai quelques raisons de penser pourquoi vous ne devriez pas le faire de cette façon et de les laisser définir le mot de passe par eux-mêmes:
- Si vous envoyez un mot de passe, certains utilisateurs pourraient penser que vous les stockez sans hachage et que vous pouvez le voir afin qu'ils ne vous fassent pas confiance, même si ce n'est pas vrai.
- Certains utilisateurs ne modifient pas le mot de passe et le laissent comme celui envoyé.
- Si le client laisse le mot de passe d'origine et que quelqu'un a accès aux autres comptes e-mail ou aux e-mails de l'expéditeur, il obtient son mot de passe.
Pour ces raisons, je voudrais simplement envoyer un lien où ils peuvent créer leur propre mot de passe.
La méthode la plus utilisée consiste à envoyer à l'utilisateur un lien pour créer son propre mot de passe.
Si toutefois cela n'est pas pratique (EG parce que vous n'avez pas encore développé cette partie du site) et que vous souhaitez quand même inviter l'utilisateur assis à côté de vous par en leur donnant leur premier mot de passe manuellement, utilisez un One-Time Secret .
Il existe de nombreux services, mais https://onetimesecret.com est facile à retenir.
N'oubliez pas de leur dire de vous avertir si quelqu'un d'autre a déjà lu leur secret (EG Le FSB ou le NSA a déjà accédé à son compte) ; -)
Veuillez cliquez ici pour le secret dont vous avez besoin pour accéder à notre service sur invitation uniquement.
Si vous recevez l'avertissement suivant:
Secret inconnu
Il n'a jamais existé ou a déjà été consulté.
Veuillez nous contacter immédiatement au +00800 IVEBEENHAD
Envoyez un lien pour définir leur propre mot de passe avec un jeton unique généré de manière aléatoire. Ce que vous faites maintenant viole quelques principes de sécurité:
1) Les administrateurs du site ne doivent pas connaître les mots de passe des utilisateurs
2) Les mots de passe ne doivent jamais être envoyés en clair
S'assurer que le jeton est généré de manière aléatoire empêchera un attaquant de forcer brutalement d'éventuels jetons, puis de définir lui-même le mot de passe. Demander aux utilisateurs de définir leur propre mot de passe élimine le besoin d'un canal de distribution sécurisé. Je recommanderais également une limite de temps sur le jeton, après quoi un nouveau doit être généré. Cela évitera la situation où les utilisateurs qui ne définissent pas leur mot de passe peuvent voir leur jeton deviné et leur compte piraté.
J'enverrais ce même e-mail (de [email protected]) à tout le monde (la seule différence entre les e-mails est un long code de compte généré automatiquement qui ne peut pas être forcé par brute):
A new trading account #3298889119019881 is available for you.
To activate it, please:
1) Respond to this email with the words "I accept with password suffix X"
2) Then, log in to https://InvitedTrading.com using username=<your email> and password=<3298889119019881 + private details + X>
<private details> is a string of first name, last name, birthdate, and social security number
E.g., "3298889119019881JohnDoe06251984123456789f76djisuh" for John Doe, born June 25, 1984, with social security number 123456789, with X=f76djisuh
You must then change your password and can change your username if desired
Or, do nothing and all will be deleted in 48 hours.
If you do not trust https://InvitedTrading.com or have any reason to doubt that they should already know your
private details above, please do nothing.