Как пароли должны быть надежно сохранены для веб-хостинга? [дубликат]
Возможный дубликат:
Шифрование/Хеширование незашифрованных паролей в базе данныхНедавно, я обнаружил, что крупнейшие хостинговые компании хранят пароли своих пользователей в простом тексте и даже просят последние 4 цифры пользователя' у пароля при попытке проверить их идентификационные данные. Это кажется жизненно неправильным и полным проблем безопасности. Я верю их причине того, чтобы сделать, это должно просто помочь в идентификации пользователей.
- Что корректный путь состоит в том, чтобы надежно сохранить пароли пользователей? И что корректный путь состоит в том, чтобы безопасно и надежный идентифицировать пользователей, не прося их пароли (например, по телефону)?
- После поиска с помощью Google для немного, кажется, что многие люди жаловались, что несколько популярных поставщиков веб-хостинга используют метод простого текста. Это может действительно быть верно, что это многие поставщики веб-хостинга использует этот метод простого текста хранения паролей? Каковы некоторые популярные веб-хосты, которые действительно надежно и безопасно хранят персональную информацию их пользователей?
4 ответа
1a) Не храните пароль пользователя, только его (соленый) хеш. Когда пользователь входит в систему, хешируйте предоставленный им пароль и сравнивайте его с вашим заархивированным хешем. Если вы не знаете настоящий пароль пользователя, вы не можете поставить под угрозу его безопасность.
1b) Трудно надежно идентифицировать пользователя по телефону, и уровень усилий, которые вы приложите, будет зависеть от того, насколько «опасным» будет несанкционированный доступ к учетной записи. Мои банковские счета требуют, чтобы я звонил с домашнего, рабочего или сотового номеров (которые я указал им заранее). Вы можете попросить вызывающего абонента проверить случайно выбранную информацию об учетной записи, которая есть у вас в файле (например, номер учетной записи, почтовый индекс для выставления счета, средний инициал, дату рождения, седьмую цифру в номере кредитной карты и т. Д.). Некоторые телефонные системы имеют индивидуальный ПИН-код для каждого пользователя, отличный от обычного пароля / ПИН-кода. Вы можете отправить вызывающему абоненту одноразовый пароль на его мобильный телефон с помощью текстового сообщения и потребовать от него ввести его в систему в течение определенного периода времени. Одна из наиболее безопасных систем, которую я видел, использует приложение Verisign VIP Mobile для генерации одноразовых паролей. (конечно, если кто-то украдет ваш мобильный телефон, это мало поможет)
2) Я сомневаюсь, что информация является общедоступной. Если бы существовал список компаний, которые небезопасно хранят информацию об учетных записях пользователей, он дублировался бы как список «пожалуйста, взломайте меня», и эти компании были бы атакованы попытками вторжения.
Относительно №1 - Правильный способ сделать это - вообще не хранить пароли. Вместо этого сохраните соленый хеш пароля.
Что касается безопасной идентификации пользователей, не запрашивая их пароли, это немного неразрешимая проблема. Все, что вы можете использовать для их идентификации, по сути становится другим паролем (с теми же проблемами хранения, что и первый). Фактически, большинство сервисов будет использовать некоторую другую личную информацию - последние 4 цифры соц. сек. номер, девичья фамилия матери или «секретный вопрос». Однако все они почти наверняка менее безопасны, чем хороший пароль.
Отвечая на первую часть вашего вопроса: вообще не храните пароль. Храните хеш пароля, соленый.
Чтобы распознать их по телефону, я бы, вероятно, попросил их сначала заранее подтвердить номер телефона, а затем использовать его в сочетании с секретным вопросом, который они могут определить.
К сожалению, многие хосты не хранят надежно пароли. У меня недостаточно опыта, чтобы комментировать в этом отношении хороших хозяев.
Обычно вы не хотите хранить пароль вообще - вы храните хэш соленого пароля. Когда они хотят войти в систему, вы солите и хэшируете то, что они вводят в качестве пароля, и сравниваете результат с сохраненным хэшем.