Возврат пароля веб-пользователю

Question

Я получил неудачное требование создания страницы, которая отображает новый пароль для аутентифицированного пользователя. Я безуспешно опротестовал это требование как в целом плохую идею, но я думаю, что жюри все еще отсутствует, поэтому, возможно, есть аргументы против отображения нового пароля, который я еще не пробовал. У вас есть предложения?

Во-вторых, было бы лучше отобразить пароль для пользователя в виде изображения, а не в виде текста. Я обеспокоен тем, что текст будет «очищен», что, я полагаю, будет сложнее с изображением. Как сделать так, чтобы браузер пользователей не кэшировал изображение?

спасибо заранее,

Answer 1

Изображение не будет защищено много.

Если вы используете HTTPS, тогда пароль будет безопасным в любом случае. Если вы используете HTTP, то пароль будет отправлен в виде открытого текста из формы (я полагаю, вы отображаете его для какого-то подтверждения), и то, как он будет отображаться через несколько секунд, не имеет значения.

Важно убедиться, что страница с паролем недоступна для кэширования.

Cache-control: no-cache, no-store, must-revalidate

Answer 2

Я не уверен, что вы собрали и каковы требования, но, как правило, я не считаю это серьезной проблемой безопасности. Давайте посмотрим на векторы атаки:

1. Человек в середине атаки на текстовый трафик HTTP - изображение, особенно изображение, скрытое от OCR (стиль CAPTCHA), предотвратит эту атаку, а также просто использует HTTPS, как упоминалось ранее.
2. Очистка экрана приложением удаленного рабочего стола - защита HTTPS не поможет, ни изображение, так как изображение на экране все равно должно быть прочитано человеком (злоумышленник может также обойти защиту вашего запутанного изображения от «человека в посередине », указав слушателю заархивировать изображение, а затем перейти к ним вручную) Если за скребком находится человек, у вас нет защиты.
3. через ваше плечо подслушивает - если злоумышленник просто стоит за пользователем, то опять же - у вас нет защиты.

Обращаем ваше внимание, что если ваш пароль автоматически сгенерирован, то вы должны показать его пользователю. Один из способов, с помощью которого сайты пытаются смягчить угрозу, - это отправить пароль по электронной почте - при условии, что пользователь может убедиться, что он прочитал письмо, когда его никто не просматривает, в свое время. К сожалению, электронная почта даже не позволяет использовать шифрование для защиты передачи.

На мой взгляд, лучший способ - позволить пользователю ввести пароль (в поле обфускации пароля, как обычно это делается), а затем сохранить только хэш пароля, поэтому вам не нужно сохранять действительный пароль, предотвращая Вы из показа пользователю. Если вам нужно показать его пользователю (возможно, потому что вы его генерируете), то убедитесь, что вы используете HTTPS и просто покажите это - все фанфары просто усложняют реализацию, не давая никаких преимуществ для безопасности.

Answer 3

Вы пробовали следующее?

• вы не можете показать пароль, потому что не храните его.

Answer 4

Я не уверен, действительно ли это такая плохая идея. Вы должны отправить новый пароль пользователю в любом случае. При отправке в виде незашифрованного электронного сообщения возникают те же проблемы: перехват или кэширование при использовании веб-почты.

Я бы предложил использовать изображение, может быть, что-то вроде капчи. Но это лишь немного защищает от автоматических атак, а не от человеческих атак.

Единственный способ обеспечить безопасность - использовать шифрование, предлагая HTTPS. Тогда использование вашего веб-сайта для отображения может стать еще более безопасным, чем использование электронной почты или подобных решений.

Разрешение пользователю вводить новый пароль имеет ту же проблему - теперь вы должны отправить его обратно на сервер.

Answer 5

Я просто предлагаю использовать HTTPS для шифрования трафика и хранить только хэши временных паролей, чтобы фактический пароль не сохранялся в базе данных. Конечно, вы не можете предотвратить кражу временного пароля физическими «хакерами» (например, людьми, заглядывающими за плечи), но, если возможно, вы можете потребовать, чтобы пользователи изменили свой пароль сразу же после входа с временным паролем, чтобы риски, связанные с временным паролем, были снижены.