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를 사용하는 앱을 개발 중입니다. 이 API에서는 사용자 이름과 비밀번호를 제출해야 합니다. 그런데 브라우저의 개발자 도구를 열어 보면 로그인 시 전달하는 평문 비밀번호를 실제로 확인할 수 있다는 점을 발견했습니다. 즉, 제 노트북에 접근할 수 있는 사람이 있다면 비밀번호가 해킹당할 수 있는 것이죠.
SSO가 활성화되어 있으면 비밀번호는 전혀 사용되지 않으므로 이는 문제가 되지 않습니다.
임의의 문자열을 입력하면 됩니다.
한 발 더 나아가려면, 앱에서 인증서 고정(certificate pinning)을 적용하여 중간자 공격(man in the middle attack)이 발생하지 않도록 할 수 있습니다.
TLS를 사용하고 있다면 비밀번호는 암호화된 상태로 전송됩니다. TLS를 사용하지 않는다면, 어떤 방법을 쓰든 큰 위험에 처하게 됩니다.
"암호화(encrypted)"가 아니라 "해싱(hashed)"을 의미했다면, 해싱 메커니즘이 공개된 인터페이스 계약의 일부가 아니며 언제든지 변경될 수 있으므로, 이는 지원되지 않는 설정입니다.
네, 맞습니다. 하지만 누군가가 노트북에 접근할 수 있다면, 해싱 과정을 거치기 전에 비밀번호를 캡처하는 키로거를 설치할 수 있습니다. Discourse(그리고 모든 웹 애플리케이션)의 보안 위협 모델에는 엔드포인트가 침해되지 않았다는 전제가 포함됩니다.