2015-02-24 2 views
0

У меня есть таблица mysql со столбцами userid, password, hashedpassword. Я использовал для хранения паролей в виде обычного текста в столбце пароля. Теперь я понимаю, что это неприемлемо и хочу теперь хешировать всех и хранить в правильном направлении в поле hashedpassword.Как хэш несколько паролей сразу, эффективно?

Вы будете злиться на сценарий ниже, потому что это ужасно неэффективно. Как вы могли догадаться, он был отключен на моем сервере. Может ли кто-нибудь помочь явно неопытным программистам с надлежащим образом обновить все эти поля в базе данных? Ясно, что подключение к базе данных для каждой записи идиотское: (...

$sql = "SELECT * 
     FROM users"; 
      $result = mysqli_query($connection, $sql); 
      if (!$result) { 
      die("Database query failed: " . mysqli_error($connection)); 
      } else { 
       while ($row=mysqli_fetch_array($result)) { 
        $userid=$row['userid']; 
        $passwordhashed=password_hash($row['password'], PASSWORD_DEFAULT); 
        $sql = "UPDATE users 
         SET hashedpassword='$passwordhashed' 
         WHERE userid='$userid' 
         LIMIT 1"; 
          $update = mysqli_query($connection, $sql); 
          if (!$update) { 
          die("Database query failed: " . mysqli_error($connection)); 
          } else { 
           //we good 
          } 

       } 

      } 
+1

Почему это должно быть сразу? вы можете выполнять несколько обновлений отдельно, и я думаю, что он будет более эффективным. Есть ли какая-то причина, почему это должно быть сразу? –

+0

Скорее всего, это всего лишь одно время, поэтому просто зацикливайте пользователей на свои пароли, хеш и все, затем создайте строку sql или файл, а затем просто выполните его в терминале – Ghost

+1

его одноразовое задание, каково его значение долго это займет –

ответ

0

из любопытства, сколько пользователей строк у вас есть в вашей таблице

я работала систему на шахте сделала некоторое время назад? при обновлении до функции password_hash (из - аналогично - неразумного обычного текстового хранилища), в результате чего я сделал скрипт для обновления пароля новым, используя этот метод хеширования.

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

(И в случае, если вы думаете: «О, это нормально, у меня не будет копии моей таблицы», эта логика мышления также означает, что вам не нужно зашифровывать ваши пароли обычного текста в первую очередь! - MySQL может быть взломан, и вам не нужно об этом знать, если хакер осторожнее и внимательнее, чем кто-то, демонстрирующий свои навыки спам-хауса)

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

0

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

Запускает этот скрипт через командную строку вариант? Это не имеет встроенного тайм-аута, как это делает веб-запрос. Обычно вы выполняете длительные сценарии миграции таким образом, потому что ожидается, что они займут больше времени, чем обычный рендеринг страниц.

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

password_hash функция намеренно медленная. Запуск этого на тысячи пользователей займет много времени, нет никакого способа обойти это. Причина, по которой он намного безопаснее, чем такие вещи, как MD5, обусловлен вычислительной стоимостью хеширования.

Стоит отметить, что LIMIT 1 в вашем UPDATE должен быть ненужным, так как вы обзорное это userid, которые должны иметь UNIQUE ограничения.

Я добавлю, что если вы хотите, чтобы это правильно, вы бы с помощью development framework как Laravel, так как большинство из тех, кто пришел с какой-то authentication system встроенной. Роллинг очень опасен, так как я уверен, что вы начинаете открывать.

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