Отправка имени пользователя и пароля по электронной почте после регистрации пользователя в веб-приложении

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

Этот подход достаточно безопасен?

  1. Мой второй вопрос заключается в том, что в основном на нашем сайте пользователь заполняет определенные формы и вводит некоторую информацию, такую ​​как имя, адрес, номер телефона, информацию о доходах и такую ​​личную информацию. В конце, когда они подают заявку, мы думаем о том, чтобы отправить им резюме всей этой информации, например, их имя, адрес и т.д., чтобы они имели их для своих записей.

это нормально... достаточно. Каковы проблемы

Ответ 1

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

Если возможно:

  • Храните свои пароли в засоленном хэше, поэтому исходный текст невосстанавливается и, следовательно, не может быть уничтожен ничем, кроме атаки грубой силы. Если пользователь забудет свой пароль, сделайте их reset и отправьте временный пароль (который они должны изменить при входе в систему) или ссылку подтверждения (которая снова запрашивает новый пароль) по электронной почте.

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

Ответ 2

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

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

Ответ 3

Люди часто используют пароли через сайты. Таким образом, вы должны предположить, что тот же пароль работает для онлайн-банкинга клиента, и вы никогда не должны отправлять его по электронной почте или предоставлять способ (кто-то притворяется) клиентом для его получения.

Это нормально, чтобы отправить им подтверждение по электронной почте с их именем пользователя - это полезно.

Помните, что если вы отправите им свой пароль по электронной почте, они, вероятно, забудут об этом электронном письме или просто удалят его. Таким образом, вам нужен еще один механизм паролей reset.

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

Относительно личной информации (адрес, доход и т.д.): почему кому-то нужно, чтобы это было отправлено им по почте? Они уже знают это! Вы просто отправляете личные данные, незашифрованные в Интернете, без причины.

Ответ 4

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

Изменить: Чтобы ответить на второй вопрос, я бы даже не писал об этом. Вместо этого я отправил ссылку, чтобы они могли легко видеть их профиль/информацию при входе в систему.

Ответ 5

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

Ответ 6

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

Воздерживаться от отправки какой-либо личной информации, например, паролей и информации о доходах по электронной почте, поскольку она может стать ОЧЕНЬ ЭМБАРРОССИЕЙ для вас и вашей организации, если такая информация была пропущена или украдена. Подумайте о безопасности серьезно. Это просто один случай, когда все кирпичи упадут.

Что касается поиска пароля, внимательно прочитайте "Восстановить пароль" .

Суть в том, что приложение следует придерживаться пользователю reset свой собственный пароль. Вопросы личной безопасности должны быть используемый. Приложение не должно отправлять электронной почты, отображения паролей и временные пароли.

EDIT: Обновлено Ссылка...

Ответ 7

Большинство компаний просто не включают комбинацию паролей пользователей из-за безопасности внешнего почтового клиента. Любые числа пользователей могут переборщить или угадать пароль на учетную запись электронной почты других пользователей, что позволит хакеру просматривать электронную почту вашего сайта. Тогда хакер может нанести ущерб вашему сайту, а также

Ответ 8

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

Ответ 9

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

Ответ 10

У меня есть три правила, касающиеся паролей:

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

Ответ 11

Как уже упоминалось в комментариях, вы можете посмотреть OpenID. Самый безопасный способ управления паролями - устранить их.

Ответ 12

Я создаю веб-приложение для отправки конфиденциальной информации по электронной почте. Это не UI, но он действительно безопасен и работает очень хорошо.

Там есть плагин outlook, API для подключения внешнего веб-сайта и веб-сайта.

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

Сообщение представляет собой запас в зашифрованной базе данных на нашей стороне. Вы можете настроить пароль, который известен только двум частям, чтобы открыть сообщение в Интернете или получить пароль (Random 6 number) с помощью SMS.

Это очень просто реализовать API.

Существует образец

//https://www.secure-exchanges.com/API.aspx

var nom = this.Nom.Value;
            var prenom = this.PrenomNom.Value; ;
            var email = this.MotPasse.Value;
            string sujet = string.Format("Informations pour {0}, {1} courriel :", prenom, nom, email);
            API.APISoapClient secure = new API.APISoapClient();
            Guid user = Guid.Empty;
            Guid psw = Guid.Empty;
            string serialNumber = "xxxxxxxxxxxxxxx";
            Guid.TryParse("xxxxxxxxxxxxxxxx8", out user);
            Guid.TryParse("xxxxxxxxxxxxxxxxxxx", out psw);
            API.GranttKeyAnswer a = secure.GetAccessToken(user, psw);

            API.SendMessageAnswer a2 = secure.SendMessage(user, a.GranttAccessKey, "mon message", "", sujet, true, "[email protected]", false, "819-888-8888", serialNumber, "onlyEmail", "fr-CA");