Сморите по регламенту сайта, каков официальный срок действия пароля (если нет такого, то определяетесь с этим).
1. Создаете в базе новое поле под bcrypt пароль, а также дату смены пароля.
2. Делаете авторизацию использующую как md5, так и bcrypt если последняя задана.
3. Разрабатываете систему оповещения для пользователей, у которых истек срок действия пароля.
4. Ставите дату пароля такой же как и дату регистрации пользователя, если не использовали это раньше.
5. При смене пароля пишете только bcrypt, md5 не используете, лучше сделать поле-флаг, что пользователь менял пароль уже по новой технологии.
В течение пару периодов срока действия пароля будет постепенный переход на новый хэш.
Активных пользователей придется как-то стимулировать, чтобы сменили пароль.
Неактивные будут восстанавливать пароль, например, по email, если они вернутся на ваш ресурс и вы решите когда-нибудь больше не поддерживать md5 хэш.
PS: Принудительно заставлять менять пароль пользователю - это не самый оптимальный вариант. Заменяйте хэш пароля по новому алгоритму, как только получили от пользователя исходный пароль, который валиден по старому алгоритму, например, в процессе авторизации.

Городские локальные сети существовали лишь благодаря особенности первых тарифных сеток провайдера.
Как правило, тарифы были сильно лимитированы по скорости, либо по объему трафика, но это касалось только тех случаев, когда трафик абонента шел из IP адреса, не принадлежащего провайдеру. Для обмена с внутренними IP адресами провайдер, как правило, не учитывал лимиты тарифа, и позволял практически свободно пользоваться этим преимуществом.
Второй особенностью было то, что провайдер не только мог предоставлять услуги подключения к Интернету, но и предоставлять услуги хостинга, предоставления доменного имени третьего уровня, других внутренних сервисов, например, облачный диск.
Два этих фактора давало возможность создать сайт в пределах локальной сети провайдера и разместить на нем каталог торрентов, а отсутствие тарифных ограничений внутри сети позволяло выгодно гонять peer-to-peer трафик. Таким образом это позволило жить и процветать торрентам в таких сетях.
Еще одной особенностью такого сайта торрента - был свой белый список диапазонов IP адресов в аккурат соответствующий провайдеру. Его полагалось указывать в торрент-клиенте, чтобы не хватануть тарифный трафик, если кто-то чужой зарегистрируется на сайте, и начнет что-то скачивать и отдавать.
Еще у учетной записи каталога торрента был рейтинг - соотношение отданного к скаченному, чтобы стимулировать пользователей оставаться на раздаче и создавать свои раздачи.
Сейчас такие ресурсы создавать не имеет смысла - потому, что не каждый провайдер имеет услуги хостинга, ужесточилось законодательство в отношении выкладываемого в сеть материала, тарифные планы дешевы, чтобы купить себе скорость близкую к технологической скорости канала, и нет различий какой трафик поступает.

Выносите даты в отдельную таблицу:
Название таблицы: location_event_dates
id - идентификатор даты;
location_event_id - идентификатор из таблицы location_event (то, что у вас в вопросе)
event_date - одна из дат события (в формате даты, а не строки!)
Тогда будет нормальный поиск:

select le.id, le.locationid, le.eventid,
          led.event_date
from location_event le
join location_event_dates led on led.location_event_id = le.id
where led.event_date between :begin_date and :end_date