2013-04-22 6 views
0

Я ищу, чтобы узнать, как я могу редактировать свой код, чтобы шифровать пароли пользователей. На данный момент пользователь заполняет HTML-форму, которая отправляется в customerRegister.php, которая проходит ряд проверок перед отправкой запроса.MySQL - как шифровать пароль

customerRegister.php

registerUser($_POST['firstName'], $_POST['lastName'], $_POST['username'], $_POST['houseNo'], $_POST['StreetName'], $_POST['town'], $_POST['postCode'], $_POST['emailAddress'], $_POST['phoneNumber'], $_POST['password'], $_POST['conPassword'],$_POST['carRegistration'],$_POST['carMake'],$_POST['carModel'],$_POST['carYear'],$_POST['carEngineSize'],$_POST['carFuel']); 

function registerUser($firstName, $lastName, $username, $houseNo, $streetName, $town, $postCode, $emailAddress, $phoneNumber, $password, $conPassword, $registration, $carMake, $carModel, $carYear, $carEngineSize, $carFuel) { 

     $registerQuery = new UserLoginQueries(); 

/******************************** 
SERIES OF VALIDATIONS 
********************************/ 

$registerQuery->insertUser($firstName, $lastName, $username, $houseNo, $streetName, $town, $postCode, $emailAddress, $phoneNumber, $password); 

Эти детали затем передаются в userLoginQueries.php, где выполняется запрос.

userLoginQueries.php

public function insertUser($custFirstName, $custLastName, $username, $houseNo, $streetName, $town, $postCode, $email, $number, $pass) { 
    $sth = $this->conn->prepare("INSERT INTO `customer`(`CustFirstName`, `CustLastName`, `HouseNo`, `StreetName`, `Town`, `PostCode`, `EmailAddress`, `PhoneNumber`, `Username`, `Password`) VALUES (?,?,?,?,?,?,?,?,?,?)"); 
    $sth->bindValue (1, $custFirstName); 
    $sth->bindValue (2, $custLastName); 
    $sth->bindValue (3, $houseNo); 
    $sth->bindValue (4, $streetName); 
    $sth->bindValue (5, $town); 
    $sth->bindValue (6, $postCode); 
    $sth->bindValue (7, $email); 
    $sth->bindValue (8, $number); 
    $sth->bindValue (9, $username); 
    $sth->bindValue (10, $pass); 
    $sth->execute(); 
    } 

Когда пользователь вводит их Логин информация следующий запрос RAN:

public function queryLogin($username, $password) { 
    $sth = $this->conn->prepare("SELECT * FROM customer WHERE Username = ? AND Password = ? AND UserType = 'Customer'"); 
    $sth->bindValue (1, $username); 
    $sth->bindValue (2, $password); 
    $sth->execute(); 
    $count = $sth->rowCount(); 
    return $count; 
    } 

Как я могу изменить мой код так, что пароль пользователей шифруются?

+0

http://dev.mysql.com/doc/refman/5.0/en/password-hashing.html – Colton

+0

Я уже проверил документацию, но мне это не очень понятно. – Colin747

+1

@Sparksis Нет, эти функции предназначены только для пользователей MySQL! – Gumbo

ответ

2

Пожалуйста, взгляните на этот ответ: How do you use bcrypt for hashing passwords in PHP?, вам просто нужно позвонить $hash = $bcrypt->hash('password'); при регистрации пользователя, а затем сохранить хешированную версию пароля в базе данных. Затем вы можете проверить пользователя, используя $isGood = $bcrypt->verify('password', $hash);

2

Вы должны действительно сохранить пароль с помощью алгоритма хеширования http://en.wikipedia.org/wiki/Hash_function (один алгоритм способ) с использованием соли, см http://en.wikipedia.org/wiki/Salt_(cryptography)

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

Простой алгоритм хэширования - ша-1. Вы можете увидеть, как использовать его здесь http://php.net/manual/en/function.sha1.php

хеширования с использованием соли

Следующие может помочь: -

$sth->bindValue (2, sha1($password . "random private stuff here as salt")); 

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

Зачем использовать соль?

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

+0

Пожалуйста, не рекламируйте слабые решения. Есть способы лучше, чем односолодованный MD5. – Gumbo

+0

Ну, «несколько слабостей» - это нечто вроде преуменьшения. [Лучше не использовать его в новом коде больше.] (Http://www.kb.cert.org/vuls/id/836068) – Wrikken

+0

Я посмотрел http://stackoverflow.com/questions/2772014/is- sha-1-secure-for-password-storage перед ответом, но я все равно изменил алгоритм хеширования. – chrisw

2

Важно помнить, что «шифрование» - это неправильное слово. Возможность шифрования подразумевает способность расшифровывать, и это плохо для паролей. Вы никогда не должны когда-либо расшифровывать пароли. Вместо этого вам необходимо указать hash пароль. Хеширование использует сложную математическую задачу для перетаскивания текстового ввода (например, пароля) в очень длинное число. Чем длиннее потенциальный номер, тем более надежным будет хэш. Важно то, что хеши нельзя отменить. Если мой пароль «p4 $$ w0rd», а полученный хэш - «12345», никогда не получится вернуть «p4 $$ w0rd» обратно с «12345».Чтобы аутентифицировать пользователей, когда кто-то пытается войти в систему, вы вычисляете хэш пароля, который они использовали, а затем сравниваете это с сохраненным значением хеша. Вы не храните пароль нигде. Когда-либо. Да, это означает, что вы никогда не предлагаете пользователю восстановить потерянный пароль; вы только когда-либо позволяете им сбросить его.

Кроме того, хеши сами по себе недостаточно хороши. Оказывается, что базы паролей сами по себе скомпрометированы, и хакеры часто уже знают ваши хэш-значения. Хакеры выделили много ресурсов для создания готовых таблиц ввода пароля, которые приведут к заданному хеш-значению. Итак, для моего примера пятизначный «хэш», у них будет что-то, предварительно рассчитанное для каждого возможного хэша от «00001» до «99999». Их значение для «12345» может не соответствовать моему «p4 $$ w0rd», но это не имеет значения: если он создает тот же хэш, это достаточно хорошо. Хакер может использовать это для поиска уязвимой базы данных и обнаружения действительного набора учетных данных для каждого пользователя. По этой причине вам также потребуется соль ваших паролей, прежде чем вы их используете. Когда вы соедините пароль, вы изменяете переданную строку перед ее хэшированием. При аутентификации моего примера пароля вместо проверки на «p4 $$ w0rd» вы должны сначала добавить соль моей учетной записи пользователя и хеш-результат. Если взломщик знает мой хэш и может найти вход, который будет генерировать мой хэш в таблице, он больше не будет полезен для него, потому что вы измените его ввод таким образом, чтобы разорвать все предварительно вычисленные хэш-результаты. Это возвращает его к грубой силе, угадывая каждый пароль.

Важно также знать, что не все алгоритмы хэширования созданы равными. Некоторые алгоритмы хеширования, такие как md5, создаются специально для быстро, так что вы можете использовать их для быстрого сравнения больших блоков текста с образцом знаний. Эти алгоритмы очень плохой для использования с паролями, потому что хакер может быстро догадаться о множестве возможных паролей. Вам нужен алгоритм хэширования, который очень медленный медленный, так что хакеру очень долго (возможно, столетиям) нужно угадать реальный пароль даже с супер-быстрым или специализированным оборудованием. Лучшие алгоритмы могут быть динамически настроены, так что по мере того, как аппаратное обеспечение становится быстрее и быстрее с течением времени, алгоритм становится медленнее и медленнее. Примерами этих алгоритмов являются «bcrypt» и «scrypt».

Наконец, наиболее важный урок состоит в том, чтобы не пытаться самостоятельно создать систему аутентификации. Проблема с аутентификацией заключается в том, что легко построить что-то, что кажется для работы, но по-прежнему ошибочны в тонких способах, так что вы можете найти год спустя, что вы были взломаны шесть месяцев назад. Система может даже пройти ряд хорошо написанных модульных тестов, но все же есть эти тонкие недостатки. Вы всегда хотите как можно больше полагаться на предварительно написанные модули аутентификации, доступные для вашей платформы. Вот почему все более популярны схемы аутентификации, которые позволяют вам регистрироваться через Facebook, Twitter, OpenID и т. Д.

+0

Я не понимаю, почему это было ниспроверено, +1 от меня для деталей – chrisw

Смежные вопросы