Следует ли разделять авторизационные данные (соль, хеш пароля) и данные учетной записи пользователя в разные таблицы MySQL?
Обычно в своих мелких проэктах я делаю отдельные таблицы, что имеет следующие преимущества:
- можно разделять доступ к этим данным и защитить соль и хеш от похищения при SQL-инъекции, так как в сценариях, отличных от входа и регистрации, доступ к ним не нужен и пользователю БД, используемому по умолчанию, можно их не давать;
- есть возможность создавать системных/вспомагательных пользователей, из-под которых нельзя авторизоваться;
- немного большее быстродействие в типичных сценариях.
Но в больших проектах, которые я видел, обычно была одна таблица, и кроме того разделение данных со связью один к одному в разные таблицы не считается хорошей практикой. Преимущества одной таблицы я вижу следующие:
- проще поддерживать согласованность данных;
- меньшая избыточность и, как следствие, меньшее занимаемое пространство.
Вряд ли есть универсальный ответ, поэтому в каких случаях лучше иметь одну таблицу, а в каких - две? Какие ещё есть преимущества и недостатки в обеих схемах БД?
Пожалуй ни разу не видел такого варианта.
Смысла вообще не вижу в этом.
можно разделять доступ к этим данным и защитить соль и хеш от похищения при SQL-инъекции
хакер-то не догадается поискать пароль и даже не заметит что его нет во взломанных данных?)
Или инъекция не распространяется на остальные таблицы магически?)
Если уязвимость к SQL-инъекции находится в коде, не связанном со входом или регистрацией, запрос будет исполняться от имени пользователя БД, не имеющего доступа к авторизационным данным даже на чтение.
sim3x: А если сделать достаточно пользователей БД и просто не давать возможность записи туда, куда не надо? Ведь, насколько я понимаю, для получения доступа к админке нужна запись или в таблицу авторизационных данных, или в таблицу сессий, иначе только SQL-инъекцией отделаться не получится, я прав? Или чтение таблицы сессий и брутфорс хеша сессионного ключа (длиной, например, 256 бит) для подстановки в куки - тоже вполне реалистичный вариант?
А вообще это только одно из преимуществ, которые я вижу, и мне интересно узнать, какие ещё преимущества в обеих схемах и когда какую стоит применять.
greenTransistor:
> не имеющего доступа к авторизационным данным даже на чтение.
Примерно то хоть представляете как с этим работать потом? Разделять потаблично или по разным базам доступ и не сломать мозг при работе. Не говоря даже про чисто технические ограничения такого решения.
Только сами себя обманете и сами же дыр из-за сложности сделаете.
Простой
