вот что у тебя в репе написано((

В репе нету ответа.

Вопрос плохо сформулирован: имеется в виду защита от SQL-инъекций или разграничение прав доступа пользователей базы данных?
Если первое, то в общих словах фильтровать входящие данные, можно также пустить все запросы через GreenSQL.
Если второе, то переместить таблицу с паролями в базу данных, доступной только для привилегированного пользователя.

__________________
<? Raz0r.name — блог о web-безопасности

И третье, закрыть доступ к БД для всех кроме локалхоста и/или сервера с сайтом.

__________________
Я отдал бы немало за пару крыльев,
Я отдал бы немало за третий глаз
За руку на которой четырнадцать пальцев
Мне нужен для дыхания другой газ..

Мой блог:http://qwazar.ru/.

Тема: Основная концепция настроек безопасности сервера

Общие условия:

• Выполнять запуск под уникальными UID/GID.
• Учетная запись администратора должна отличаться от стандартного "имени" и иметь сложный/индивидуальный пароль.
• Разрешать лишь необходимые модули.
• Полное отсутствие учетных записей с анонимным, либо тестовым доступом.
• Файлы конфигурации должны применяться по возможности для сведения атак к минимуму.
• Использование chrooted среды.
• Доступ должен осуществляться через межсетевой экран.
• Контроль средств администратирования БД.
• Фильтрация всех запросов и их содержания со стороны клиента.
• Доступ к БД должен осуществляться локально.
• При работе (будь то администратирование, либо удаленное резервирование) с БД данные не должны передаваться в открытом формате.
• Изменение, удаление используемых по стандарту таблиц, префиксов в БД способных скомпромитировать систему.

Я бы добавил, что если СУБД используется одновременно несколькими сервисами/сайтами, то под каждый сервис/сайт использовать отдельную учетную запись с максимально ограниченными и минимально необходимыми правами доступа к СУБД.