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.
Существует ли способ передавать зашифрованный пароль вместо пароля в открытом виде? Мы разрабатываем приложение, в котором используем API /session для проверки аутентификации пользователя. Требуется отправлять имя пользователя и пароль. Я заметил одну вещь: если открыть инструменты разработчика в браузере, можно увидеть пароль в открытом виде, который мы передаем при входе. Таким образом, если кто-то получит доступ к моему ноутбуку, пароль может быть скомпрометирован, верно?
Если вы хотите перестраховаться, вы можете использовать закрепление сертификатов в вашем приложении, чтобы гарантировать отсутствие атак типа «человек посередине».
Пока вы используете TLS, пароли передаются в зашифрованном виде. Если вы не используете TLS, вы очень быстро придёте к краху в любом случае.
Если вы имели в виду «хэшированный» вместо «зашифрованный», то нет, такая конфигурация не поддерживается, поскольку механизм хэширования, используемый в Discourse, не является частью публичного контракта интерфейса и может быть изменён в любой момент.
Ну да, но если у кого-то есть доступ к вашему ноутбуку, он просто установит кейлоггер, который перехватит пароль ещё до того, как он подвергнется хэшированию. Модель угроз безопасности Discourse (как и любого другого веб-приложения) предполагает, что конечная точка не скомпрометирована.