MediaTemple не хэширует пароли. Они хранят их как текст. Это имеет значение, хотя? - PullRequest
1 голос
/ 18 февраля 2010

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

Кроме возможности испортить сотрудников или хакера, который берет учетные записи электронной почты и пароли от SAAS на example.com, а затем пытается войти в учетную запись электронной почты каждого клиента, используя свои пароли example.com (на случай, если они использовать один и тот же пароль несколько раз), что может произойти, есть ли другие причины, по которым пароль должен храниться в зашифрованном виде?

Ответы [ 3 ]

4 голосов
/ 18 февраля 2010

Этих причин недостаточно?

Единственная причина для шифрования любой информации заключается в том, что те, кто не авторизован для ее просмотра, не получат ее. Пароли включены.

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

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

1 голос
/ 20 февраля 2010

Оба ответа хороши, однако (mt) Media Temple не хранит пароли в виде простого текста. В ноябре и декабре 2009 года был проведен капитальный ремонт системы безопасности. Все пароли хранятся в хеше. Сотрудники не могут видеть пароли клиентов, и с этого времени проверка подлинности выполняется с использованием краткосрочного ПИН-кода или сопоставления паролей.

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

М Ханда Супервайзер поддержки (мт) Медиа Храм, Inc

1 голос
/ 18 февраля 2010

На самом деле, то, что вы только что описали, является уязвимостью. Вредоносный инсайдер - это серьезная угроза для ваших охранников, и это здорово, что вы это признали. Никто не должен знать ваш пароль, если кто-нибудь узнает ваш пароль, вы ДОЛЖНЫ изменить его.

Существуют очень четкие инструкции по хранению паролей. Они определяются родительским идентификатором CWE-255: http://cwe.mitre.org/data/definitions/255.html

Под CWE-255 указано CWE-256 , в котором четко указано, что хранение паролей в открытом тексте является уязвимостью. Следующим является CWE-257 , в котором говорится, что хранение паролей в «Восстанавливаемом формате» является уязвимостью, поэтому если вы используете «Шифрование», злоумышленник может «расшифровать» ваш пароль и атаковать вас , Кроме того, не используя хэши, вы делаете веб-приложение более уязвимым для SQL-инъекций. Распространенная атака SQL-инъекций - это чтение хэша пароля из базы данных. Если вы можете расшифровать пароль, то хакер может сразу войти в систему. Идея, лежащая в основе хэша, состоит в том, чтобы заставить их сломать его, что замедляет атакующего.

Для хранения пароля семейство sha2 в настоящее время является лучшим решением. Мне нравится sha256, хотя sha512 также принадлежит к тому же семейству и может быть использован, если вы более параноик.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...