Хеш-пароли php

У меня очень простая система входа в систему, которая аутентифицирует пользователей с помощью пользовательской таблицы в базе данных mysql с php.

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

Спасибо


person TechplexEngineer    schedule 24.08.2010    source источник
comment
см. stackoverflow.com/questions/3505346/php-md5-explained/   -  person Chris    schedule 25.08.2010
comment
возможный дубликат Безопасный хэш и соль для паролей PHP   -  person rook    schedule 25.08.2010


Ответы (4)


может кто-нибудь объяснить, в чем смысл хеширования паролей,

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

как это сделать с помощью php и что на самом деле хранится в базе данных.

Чтобы использовать его в PHP, вы просто берете строку, в этом примере $password = 'password';, и используете команду sha1();. Это вернет что-то вроде d0be2dc421be4fcd0172e5afceea3970e2f3d940. Также хорошей практикой является «солить» пароли с вашим php-скриптом, чтобы для успешного входа в систему требовался скрипт входа в PHP-скрипт. Пример:

<?php
    $salt1 = '2348SDasdf!^*__';
    $salt2 = '_a35j@*#(lsdf_';
    $password = sha1($salt1.$_POST['password'].$salt2); // d0be2dc421be4fcd0172e5afceea3970e2f3d940
?>

Затем вставьте $ password в свою базу данных. После входа в систему вам нужно будет ввести пароль, указанный для запуска через sha1, чтобы он совпадал с паролем в базе данных. Вы вставляете его в базу данных, как и любую другую строку, просто убедитесь, что у вас есть достаточная длина, предоставленная столбцу, который вы также пытаетесь вставить.

person Robert    schedule 24.08.2010
comment
Это не очень хороший ответ, так как соль должна быть случайной. Если «соление» является постоянным, атака методом грубой силы может взламывать пароли параллельно (то есть для каждого сгенерированного словарного слова вы вычисляете один хэш и смотрите, соответствует ли он одному из N пользователей). Но если вы возьмете случайную соль, хеш нужно будет вычислять для каждого слова и каждого пользователя, добавляя коэффициент N к сложности. - person mvds; 26.08.2010
comment
В противоположность тому, что они знают соль, получая базу данных, у обоих способов есть свои недостатки. Если это случайно, вам придется где-то хранить соль, что, если кто-то получит к ней доступ, будет так же легко перебрать. - person Robert; 26.08.2010

Скажем, кто-то взломал вашу систему (или нашел лазейку в ваших sql-запросах), тогда вы не хотите, чтобы они знали все пароли.

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

Если только вы не используете слабый хеш. Если бы вы использовали только sha1($password), то вы обнаружите, что размещение хеша часто используемых паролей в Google дает пароль менее чем за 0,1 секунды * (но в противном случае вы также можете найти радужные таблицы для всех видов хешей)

Итак, вы хотите добавить «соль», это означает, что вы генерируете какое-то значение мусора:

$salt = rand().rand().rand();

а затем сохраните

$hash = $salt."-".sha1($salt.$password);

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

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

person mvds    schedule 24.08.2010
comment
MD5 следует считать криптографически взломанным и непригодным для дальнейшего использования. kb.cert.org/vuls/id/836068 - person webbiedave; 25.08.2010
comment
rand() не является криптографически безопасным. также соль должна быть отдельной колонкой, это плохой дизайн БД. - person rook; 25.08.2010
comment
Итак, если хакер знает, в чем заключается соль, разве это не полностью разрушает цель соления? - person TechplexEngineer; 25.08.2010
comment
@The Rook: Даже если бы я согласился, здесь это немного не относится к делу. (и, честно говоря, я не согласен, потому что я хочу, чтобы пароль соли + хэш был хорошим атомарным фрагментом данных, где бы я его ни взял. Соль и хеш бесполезны, когда они разделены, я только упаковываю / распаковываю их, когда это необходимо, остальная часть системы просто видит это как одну строку) - person mvds; 25.08.2010
comment
@TechplexEngineer не разрушает цели. Вы увеличиваете свои пароли, чтобы усложнить задачу. Вы запираете двери дома, чтобы предотвратить мелкую кражу, но решительным ворам не помешает что-то вроде запертой двери. - person Robert; 25.08.2010
comment
@Techplex: нет, потому что, если бы он знал, что соль, скажем, 7236817, тогда он фактически должен был бы отменить хэш 7236817your_password, что с меньшей вероятностью произойдет в радужной таблице. Кроме того, перебор всех ваших учетных записей будет означать, что злоумышленник должен хешировать каждый пароль, который он пытается использовать, для каждой обнаруженной соли. Так что просто сделайте соль длинным и положите туда больше, чем просто 0-9! - person mvds; 25.08.2010
comment
@mvds Я думаю, это означает, что ваша соль буквенно-цифровая или, может быть, даже просто base16. Значение соли должно быть base256 (полный байт на символ), вам нужно максимальное соотношение энтропии к длине строки. - person rook; 25.08.2010
comment
@Rock ну, я бы оставил его буквенно-цифровым (или OP вернется позже с проблемами двоичных данных mysql), но в любом случае пример с rand() был самым простым для передачи сообщения. - person mvds; 25.08.2010

Хеш - это «односторонняя функция». Вы вводите пароль и получаете приблизительно уникальный результат, который невозможно (с вычислительной точки зрения) преобразовать обратно в реальный пароль. В зависимости от хеша он будет выглядеть по-разному. Например, с sha1 (http://php.net/manual/en/function.sha1.php) всегда будет строка длиной 20 байт.

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

person Jonathan    schedule 24.08.2010
comment
Что ж, вы легко можете найти большой список общих паролей. Нетривиально написать программу для вычисления хэша для всех из них, а затем сравнить эти хэши с базой данных паролей. Это, конечно, актуально только тогда, когда кто-то имеет доступ к хешированным паролям. Кроме того, это можно эффективно предотвратить, используя соль, как упоминалось в другом сообщении. - person Jonathan; 25.08.2010
comment
да, если я скажу вам, что я хэширую свои пароли, используя md5($password), а мой хеш - 08b5411f848a2581a41672a759c87380, вы можете сказать мне, какой у меня пароль? - person mvds; 25.08.2010
comment
@Jonathan: тебе больше не нужно делать эти вещи самому, они есть и индексируются бесплатно. - person mvds; 25.08.2010
comment
Кстати, этот хеш дал несколько неожиданных результатов: пользовательские таблицы! - person mvds; 25.08.2010
comment
Правильно, но для этого вам не нужен md5decryption.com, Google подойдет. - person mvds; 25.08.2010

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

person James    schedule 24.08.2010
comment
Дело не в этом так. Дело в том, что если ваша база данных была украдена, вы должны сообщить всем своим 1 миллиону пользователей, что их пароли были украдены и что они должны их изменить. Они этого не сделают, так что некоторые сумасшедшие будут иметь доступ к учетным записям 900 тысяч пользователей в вашей системе. Итак, у вас самая большая проблема. - person mvds; 25.08.2010
comment
отчасти хороший момент @mvds, за исключением того, что вы можете заставить своих пользователей менять пароли, чтобы обойти эту проблему - это не сделает вас популярным, но это сработает. Но мой по-прежнему хороший аргумент. Конечно, если хакеры взламывают чужие сайты, используя пароли, украденные у вас, это не ваша проблема, но думаете ли вы, что ваши (возможно, бывшие) клиенты увидят это так? - person James; 25.08.2010
comment
Конечно, это зависит от обстоятельств. Если вы компания, вы можете заставить 100% своих сотрудников сменить пароли, и они не покинут вашу компанию, правда. Если вы используете gmail / hotmail, вы можете принудительно установить 80% (при условии, что много мертвых учетных записей), и некоторые клиенты уйдут от вас. Если вы занимаетесь менее важными вещами (социальные сети, игры, форумы и т. Д.), Вы, скорее всего, отпугнете 50% своих с трудом заработанных пользователей, поскольку вам придется заблокировать учетные записи в какой-то момент, если пользователи не отвечают на ваш запрос. Кроме того, есть проблема, что в этом последнем случае вы - продолжение - person mvds; 26.08.2010
comment
- вероятно, нет надлежащих механизмов для подлинной аутентификации пользователя (секретный вопрос, фактическая дата рождения и т. д.). Так что реальный риск состоит в том, что вы просто выйдете из бизнеса не только из-за плохой прессы. - person mvds; 26.08.2010