Итак, сначала отвечу по вопросу, а потом расскажу почему так не надо делать :)

1. В Yii не надо для этого никаких особых изворотов. Соединение с базой описывается через объект CDbConnection . В нём просто надо покопаться... создаём на лету новое соединение и выставляем его как основное соединение, после чего все обращения к базе происходят через это соединение.

2. А не надо так делать, потому как никакого "второго уровня защиты" не получится. Это то же самое, что и требование кодировать пароль в md5 на стороне клиента, защищая сайт от взлома... ЭТО ТАК НЕ РАБОТАЕТ!!! Если я стяну с компа пользователя куки (в частности id сессии), то как БД узнает, что я не тот пользователь, каким представился? А никак :) Она меня пустит на ровне с реальным владельцем аккаунта. Если как-то получится стянуть пароль пользователя, то залогинившись, меня точно так же база пустит к себе с правами пользователя.

Это то же самое, что и повесить на дверь 2 замка открываемых одним ключом :) Если взломщик сможет выточить ключ открывающий первый замок, то и второй открыть будет очень просто (за исключением случаев, когда замок будут взламывать на месте или пытаться с ноги выбить дверь... но это действия явных делитантов). А вот Вам, высверливать ещё одну дырку, потом ставить новый замок... потом, если дверь надо будет сменить, новая дверь будет металлическая и будет предусматривать только один замок - Вам придётся и её пилить и резать... В случае, если после этого дверь сломается, то производитель Вас же и обвинит в проблеме (и будет прав).

В общем преимуществ - 0, а проблем - выше крыши.

Но, как говорит один из моих бывших руководителей "тебе из погреба виднее" :)

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

Или вон как в swedbank'е работает система входа в личный кабинет (не знаю как у нас, пользовался их услугами за границей), они выдают специальную хренотень, по входу через логин и пароль, ты получаешь сгенерированный сайтом код, который вводишь в эту штуковину, а ответ забиваешь на сайт... ВОТ ЭТО ВТОРОЙ УРОВЕНЬ ЗАЩИТЫ, заполучи что-то одно и у тебя ничего не получится.

Или как openId работает (если правильно помню). При регистрации сайта в системе, тебе выдают логин, пароль и ключ шифрования. Ты даёшь запрос на вход (получение данных пользователя), тебе отправляют код, к которому применяется этот ключ и получается token, который отправляется на сервер, который в свою очередь по тем же правилам генерирует такой же token. И только в случае их совпадения можно попасть в систему.

Однако... заставьте на рядовом сайте без особых конфиденциальных данных пользователя вводить 2-3 пароля и проходить уйму уровней защиты и получите максимум несколько десятков регистрированных пользователей, которым это реально надо. Остальные просто забьют на регистрацию и пойдут на сайт конкурентов с удобной для них системой :)

ScareCrowавторВон, как в банках... Вход не по паролю , а по коду, пересылаемому на телефон после ввода пароля на сайте...


ты в своем репертуаре, да.

Да.. Раньше на этом сайте для меня число сообщений пользователя было очень весомым показателем его опыта (я безоговорочно верил тому, что писали мне люди с 2-3 десятками тысяч сообщений). После общения с тобой, я понял что это явно не показатель. Не хочу никого обидеть (не о глупости/уме пишу, а о бессмысленных сообщениях)... но если собрать все твои сообщения в темах, в которых мы пересекались то, думаю процентов только 5 будет по теме...

Настроения просто нету ) Давай, если тебе есть что сказать по теме - пиши, с удовольствием обсудим... а так - нафига воду мутить лишний раз? :)

SQL-Talker,

Кстати, а пароль то в сессии точно хранить не надо (внимательно первое сообщение перечитал). Иначе опять же заполучив доступ к сессиям мне даже не надо будет ничего ломать... я просто в прямом виде стяну пароль и всё. :) Потому как минимум в md5 его туда писать, а вообще - и в md5 не надо (хоть алгоритм и необратим, есть алгоритмы подбора значений для соответствующего md5 значения).

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

Есть куча других методов взломать сервер и получить доступ к аккаунту любого использующего сайт пользователя.

Элементарно - загрузка файла php через форму с последующим выполнением (при неверных настройках), разного рода инъекции, стягивание куков у пользователя, вирусы-шпионы на компе пользователя.


Со стороны сервера защита на уровне mysql не нужна, так как защищается не именно база, а пользователь.. Потому не дав доступа к базе, но дав доступ к данным вводимым пользователем (если получится свой скрипт на хосте запустить), задача достигнута не будет.
Закрываем запуск пользовательских файлов на сервере, убираем разного рода exec из кода, избавляемся от всех возможностей указать путь файла из командной строки (такие случаи иногда бывают в попытке добиться простоты и универсальности в модулях для знаменитых cms), экранируем все пользовательские данные при обращении в базу, экранируем всё, что вводят пользователи и что показывается другим пользователям (типа как комментарии, в которых может сидеть javascript)... предпринимаем ряд подобных действий и сайт становится непроникаемым (разве только хостер ступит, но это уже его проблемы)

White Owl,

про sessionid я чего-то не догнал. Ниразу такого подхода не видел, расскажи пожалуйста о чём речь идёт, о какой базе сессий.
Может имелось ввиду обычный механизм сессий предоставляемый сервером?

про отдельный сервер авторизации - тоже не понял. А чем поможет то, что авторизироваться пользователь будет на другом сервере? Из этой мысли имеет смысл только (по-моему) принудительная проверка по ip. Это усложнит задачу взломщика, так как ему кроме получения id сессии надо будет сделать запрос именно с ip адреса реального пользователя, с которого был произведён вход. То есть без явной уязвимости в клиентской части (в том числе в клиентском js) сделать ничего не получится (разве только заставить провайдера отрубить пользователя от сети и быстренько занять его адрес, вероятность чего стремится к нулю, так как это уже попахивает взломом системы провайдера).

White OwlДвойная проверка источника.
Бизнес сервер запоминает кого он отправил на сервер авторизации. Сервер авторизации убеждается что клиент к нему был отправлен из легального места. В смысле сервер авторизации знает что клиент может быть к нему прийти только от бизнес сервера и не примет случайных клиентов (http referer). После авторизации клиент перенаправляется обратно на бизнес сервер, который тоже проверяет referer и убеждается что билетик клиент получил именно на легальном сервере авторизации, и именно тот клиент которого он отправил авторизоваться не далее пяти минут назад. Вот этот обратный посыл сэмулировать снаружи сети не так-то просто.
После этого бизнес сервер общается с сервером авторизации по полученному билету, и это общение уже идет обычно внутри LAN и вне досягаемости хакеров.

Этот процесс ничем не отличается от перехода с одного скрипта на другой. Разница лишь в referer, который подделать ничего не стоит. То есть бизнес скрипт и скрипт авторизации - будет делать то же самое. Если и делать что-то подобное, то это должен быть сервер бизнес логики, на котором присутствует форма логина. Но получая данные логина и пароля он их отдаёт другому серверу, который соединяется с сервером sql и производит логин, отдавая назад данные пользователя.

Тогда, что бы добраться до базы, надо взломать 3 сервера... Или найти уязвимость в скриптах. Понимаешь, сейчас сервера никто не ломает напрямую... Уровни защиты такие, что это сделать почти нереально (только с хреновым сис админом). Ломают именно скрипты (ищут в них уязвимости). А если скрипты будут взломаны, то подделать можно почти всё, что угодно (а тем более, если взломаны скрипты на клиенте, с которого достают нужные данные).

Ну например, скорее всего на сайте будет функционал смены пароля или "забыли пароль" )) Взломав клиента, можно подделать эти запросы и поменять пароль, когда это надо будет. Вот и всё.