Summary of Discussion on Password Security in Discourse API
A discussion was initiated by mikeredick regarding the security concern of passing plain text passwords when creating a user through the Discourse API. mpalmer explained that using SSL is considered sufficient to protect secrets in-flight, but Siddhu_Dhangar suggested passing an encrypted or hashed password instead. However, mpalmer clarified that hashing is not a supported configuration due to its changing mechanism within Discourse. mpalmer also pointed out that if someone has access to the endpoint, they can still capture the password. RGJ mentioned that if SSO is enabled, the password is not used, and spirobel suggested certificate pinning to prevent man-in-the-middle attacks.
I’m creating a small windows application that will use Discourse as the SSO provider. The first step in that chain is allowing the app to create a user through the Discourse API.
I’ve got that working, however it seems that the password for the user is passed in plain text and I’m wondering why that is? It seems like that could be a security issue… is the thought just that people should use SSL and that’s good enough to protect the password?
Yes, SSL is considered sufficient to protect secrets in-flight. Until the world sees the light and switches to something like TLS-SRP, sharing secrets over a secured channel are pretty much all we’ve got to work with.
Pouvons-nous envoyer un mot de passe chiffré au lieu d’un mot de passe en clair ?
Y a-t-il un moyen de transmettre un mot de passe chiffré au lieu d’un mot de passe en clair ? Nous développons une application qui utilise l’API /session pour vérifier l’authentification de l’utilisateur, où le nom d’utilisateur et le mot de passe doivent être soumis. J’ai remarqué une chose : si vous ouvrez les outils de développement du navigateur, vous pouvez voir le mot de passe en clair que vous transmettez lors de la connexion. Donc, si quelqu’un a accès à mon ordinateur portable, le mot de passe pourrait être compromis, n’est-ce pas ?
Si SSO est activé, le mot de passe n’est pas utilisé du tout, ce n’est donc pas un problème.
Fournissez simplement quelques caractères aléatoires.
Si vous souhaitez faire un effort supplémentaire, vous pouvez implémenter le verrouillage de certificat dans votre application pour vous assurer qu’il n’y a pas d’attaque de l’homme du milieu.
Tant que vous utilisez TLS, les mots de passe sont envoyés de manière chiffrée. Si vous n’utilisez pas TLS, vous êtes sur un train rapide vers la catastrophe, quoi qu’il arrive.
Si vous vouliez dire « haché » plutôt que « chiffré », alors non, ce n’est pas une configuration prise en charge, car le mécanisme de hachage utilisé dans Discourse ne fait pas partie du contrat d’interface publique et peut changer à tout moment.
Eh bien, oui, mais si quelqu’un a accès à votre ordinateur portable, il peut simplement installer un enregistreur de frappe qui capture le mot de passe avant qu’il ne passe par le processus de hachage. Le modèle de menace de sécurité de Discourse (et de chaque application web) inclut la stipulation que le point de terminaison n’est pas compromis.