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.
平文のパスワードではなく、暗号化されたパスワードを送信することはできますか？
平文のパスワードではなく、暗号化されたパスワードを渡す方法はありませんか？私たちは認証確認のために /session API を使用しているアプリを開発しています。ここではユーザー名とパスワードの提出が必要です。一つ気づいたのですが、ブラウザのデベロッパーツールを見ると、ログイン時に送信する平文のパスワードが実際に確認できてしまいます。もし誰かが私のノートパソコンにアクセスできれば、パスワードがハッキングされる可能性がありますよね。
SSO が有効になっている場合、パスワードは全く使用されないため、これは問題になりません。
適当な文字列を入力してください。
さらに安全性を高めたい場合は、アプリで証明書ピンニングを実装して、中間者攻撃を防ぐことができます。
TLS を使用している限り、パスワードは暗号化されて送信されます。TLS を使用していない場合、それは破滅への高速列車に乗っているようなものです。
もし「暗号化」ではなく「ハッシュ化」を意味していたのであれば、いいえ、それはサポートされていない構成です。Discourse 内で使用されているハッシュ化メカニズムは公開インターフェース契約の一部ではなく、いつでも変更される可能性があるためです。
はい、その通りです。しかし、誰かがあなたのノートパソコンにアクセスできているのであれば、ハッシュ化プロセスを通過する前にパスワードをキャプチャするキーロガーを仕掛けることも可能です。Discourse（およびあらゆる Web アプリケーション）のセキュリティ脅威モデルには、エンドポイントが侵害されていないことが前提として含まれています。