phpass лучшее решение для безопасного хранения пароля? - PullRequest
Новая
       30

phpass лучшее решение для безопасного хранения пароля?

9 голосов
/ 12 июля 2011

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

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

Мой текущий метод -просто хэш sha512 с одной специфической для пользователя солью и другой хеш для конкретного сайта.Вот фрагмент моего PHP-кода: 

hash_hmac('sha512', $password.$account_specific, $site_specific);

Было бы здорово услышать некоторые экспертные мнения по этому вопросу.Я прошу прощения за создание другой темы для предмета, который был и будет всегда спрашиваться.Заранее спасибо.

РЕДАКТИРОВАТЬ:
Я также слышал, что хеширование пароля, скажем, 1000 раз, это также хороший способ хранения паролей.Таким образом, хеширование занимает всего несколько секунд (максимум), но взлом хешированного пароля буквально стареет?

Ответы [ 3 ]

8 голосов
/ 13 июля 2011

При работе с вопросами безопасности в Интернете не существует «истинного» безопасного способа действий. Сетевая безопасность по своей сути является игрой в кошки-мышки; обычные пользователи - мыши, а хакеры - кошки. Веб-безопасность прежде всего реактивна, что означает, что новая реализация безопасности рассматривается только тогда, когда происходит нарушение безопасности. Из-за этого хакеры, как правило, на один шаг впереди реализации безопасности.

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

1) Используйте значения соли.

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

2) Использовать SSL-сертификаты

Убедиться в том, что данные зашифрованы при переходе на / с сервера, на котором находится ваше приложение, является хорошим способом защиты от перехвата пакетов и перехвата сеанса.

3) Использовать хэши SHA2

Значения SHA2 широко используются и во много раз более безопасны, чем их предшественник, SHA1.

4) Ваша БД и приложение находятся на разных серверах.

Если у вас есть БД на отдельном сервере (или, по крайней мере, где-то с отдельным IP-адресом), вы можете ограничить доступ к БД указанным вызывающим IP-адресом / портом. При этом вы можете быть уверены, что ЕДИНСТВЕННЫЕ вызовы, которые можно выполнять в вашей базе данных, поступают из вашего приложения.

5) Используйте хранимые процедуры вместо динамического создания запросов.

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

6) Проверьте все возможные точки впрыскивания

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

Из моего опыта, если вы делаете все вышеперечисленное, тогда вы очень хорошо защищены. Ничто не является на 100% безопасным, но если вы не держите секретные коды в миллиард долларов, свободных от денег, то эти препятствия будут сдерживать подавляющее большинство хакеров (если не всех). Проработав несколько сайтов крупных корпораций, смешно отсутствие безопасности, которую используют некоторые из этих сайтов ( кашель * кашель * SONY кашель * кашель *).

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

С уважением,

2 голосов
/ 12 июля 2011

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

Как безопасно хранить пароль

0 голосов
/ 13 июля 2011

Я использую это: 

function super_hash($string,$key,$times=2) {
    $hashed_string = SITE_KEY . $string . $key;
    for($i=1;$i<=$times;$i++) {
        $hashed_string = hash_hmac('sha512',$hashed_string,SITE_KEY . $key . 'hardcoded_key');
    }
    return $hashed_string;
}

Для большей безопасности (медленная обработка) просто добавьте больше итераций (параметр $ times). Обратите внимание, что дополнительные итерации необходимы, только если ваша база данных и ваш код скомпрометированы.

...