Почему бы не использовать встроенных пользователей MySQL и разрешения для веб-сайта?

Я довольно много искал темы шифрования, хранения паролей, разработки безопасных скриптов PHP и т. Д.

Кажется, есть пара общих тем:

  • «Не пытайтесь писать собственные сценарии шифрования, используйте существующую библиотеку (например, PHPass)».
  • «Не создавайте базы данных MySQL для каждого пользователя, создавайте одну большую базу данных и пишите хороший PHP-скрипт для управления вашими пользователями, паролями и их данными».

Теперь, это я, или эти два не кажутся немного противоречивыми?

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

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

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

Итак, почему бы не создавать пользователей MySQL для каждого пользователя сайта? Зачем откатывать свой собственный PHP-скрипт для создания пользователей, а затем хранить эту информацию в таблице в базе данных, когда MySQL уже предлагает эту функцию? Каковы фактические причины? Считаем ли мы, что использование PHPass (или альтернативы) обеспечивает «безопасное» хранение паролей, чем встроенное в MySQL?

Является ли хранилище внутри базы данных MySQL «небезопасным». Если у вас был локальный доступ к моей машине, но никаких админов или корневых паролей или других коммандов user / pass для моей базы данных MySQL, вы все равно сможете получить все данные в любом случае?

Если создание пользователя MySQL для каждого пользователя веб-сайта считается «приемлемым», то почему бы не создать новую базу данных или таблицу для каждого пользователя и установить разрешения в MySQL, чтобы каждый пользователь мог получить доступ только к своим данным и ничего больше? Конечно, администратор с локальным доступом и корневым паролем может прочитать всю информацию.

Похоже, что по дизайну функциональность создания пользователей и назначение разрешений уже встроена в MySQL, зачем писать скрипт PHP для выполнения того же самого?

///

Следующий вопрос.

Если это необходимо для работы, то для создания PHP-скрипта для создания новых пользователей должен быть пользователь MySQL. Это может привести к тому, что пользователь / пароль будет храниться в открытом тексте, это не так?

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

Это возможно?

    Пользователи MySQL предназначены для пользователей самого сервера MySQL. Эти пользователи должны быть зарезервированы для использования только администратором сервера или приложениями, для которых требуется запуск пользователя (укажите отдельного пользователя для каждого приложения). Система управления пользователями MySQL была построена специально для обеспечения контролируемого доступа к базе данных, работающей на сервере, а не к основанию аутентификации пользователей в веб-приложении. Кроме того, для любых добавлений в базе данных (и создания пользователей) потребуется, чтобы у пользователя было приложение, имеющее эти разрешения для базы данных. Хотя сама по себе не является прямой уязвимостью, если ее можно найти в вашей системе PHP, это может сделать вашу жизнь намного хуже.

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

    Что касается хэширования паролей, используйте bcrypt через функцию crypt () PHP . Храните это в базе данных в таблице пользователей.

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

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

    Или рассмотрите приложения, которые используются для связи между пользователями. Если пользователь A хочет отправить сообщение пользователю B, ему нужно будет что-то записать в таблицу, которую может прочитать пользователь B. Но если каждый пользователь имеет доступ только к своим собственным таблицам, такой таблицы нет. Что вы собираетесь делать, создать базу данных для каждой пары пользователей? И тогда, что касается многопоточных сообщений, как система форума?