Полная Версия: Авторизация
| Цитата (maximka787 @ 22.06.2015 - 08:24) |
| Зацените, очень важно ваше мнение: |
выкинуть все нафиг
| Цитата (maximka787 @ 22.06.2015 - 08:24) |
| Страница авторизация: 1.1 Пользователь ввел логин и пароль, если запись в БД есть, то создаем S_SESSION['id']. 1.2 В таблицу сессий добавляем session_id() и USER_AGENT. 1.3 Создаем куки файл с одним значением - зашифрованным ключом sha1(salt1 + user_id + user_agent + salt2) 1.4 В таблицу автологина сохраняем то же ключ куки и каждое поле по отдельности (key, user_id, user_agent, salt1, salt2) |
оставить пункт 1.1 все остальное бред. Если хочешь привязать сессию к IP или юзерагенту, тогда и храни их в сессии на кой тут сдалась БД?
А вот это изобретение "хитрых ключей" я вообще не понял, для чего оно?
Как Сергей выше написал твоя главная проблема, это не понимание матчасти, почитай статейки и поймешь что ты изобретаешь велосипед. Причем ладно бы изобретал с нуля, но у тебя параллельно юзается и нативный механизм, и какая то непонятная надстройка с БД и куками, зачем это всё?
| Цитата (maximka787 @ 22.06.2015 - 08:24) |
| Логаут 3.1 Удаляем все сессионные переменные, куки. |
На куки можно забить
| Цитата (maximka787 @ 17.06.2015 - 22:15) |
| Да я всегда хранил пароль в md5. Недавно перешел на sha1. |
начни отсюда
killer8080 Ты разрушил мой мир((
Меня вообще интересовало всего 2 важных момента: Защитить сайт от подмены SESSION['id'], чтобы юзер НИКАКИМ образом не сделал что-то от лица (ID) другого. И авто логин, без которого - Цитата: "сейчас уже сайты даже не делают"
1. Ну к примеру сессию с привязкой к юзер агенту я уберу. ОК. Обойдемся без БД. (просто так бы я видел сколько юзеров работает в данный момент с сайтом). Да и паранойя это, кража сессий..
2. На счет матчасти, я все время работал только по SESSION['id'], без БД и прочей нечести. Хватало. Но когда встал НАСТОЙЧИВЫЙ вопрос сделать авто логин, начал заново перечитывать инфу из "статеек" и пришел к выводу, что почти все кодеры хранят сессии в БД, проверяют куки и делают много работы. Так что "На куки можно забить" я б рад, просто авто логин без этого не делается.
3. "А вот это изобретение "хитрых ключей" я вообще не понял, для чего оно?". Тут просто всё. При авторизации я сгенерировал ключ, не принципиально как именно (согласен, перегнул), но сделал и отдал юзеру в куки это одно 40 значное значение. Важен сам факт создания в БД 2 колонок key, user_id. Когда юзер пришел на сайт снова, у него сервер сначала смотрит ключ (ну мало ли сохранен). Рас, и нашел, проверил по базе и определил чей это id и стартонул сессию SESSION['id']. А дальше как обычно. Понимаю, тут может быть жесткая ошибка сладкая для хацкеров (допустим). но по логике вроде не обойти.
_____________
..Работает - не трогай!
Меня вообще интересовало всего 2 важных момента: Защитить сайт от подмены SESSION['id'], чтобы юзер НИКАКИМ образом не сделал что-то от лица (ID) другого. И авто логин, без которого - Цитата: "сейчас уже сайты даже не делают"
1. Ну к примеру сессию с привязкой к юзер агенту я уберу. ОК. Обойдемся без БД. (просто так бы я видел сколько юзеров работает в данный момент с сайтом). Да и паранойя это, кража сессий..
2. На счет матчасти, я все время работал только по SESSION['id'], без БД и прочей нечести. Хватало. Но когда встал НАСТОЙЧИВЫЙ вопрос сделать авто логин, начал заново перечитывать инфу из "статеек" и пришел к выводу, что почти все кодеры хранят сессии в БД, проверяют куки и делают много работы. Так что "На куки можно забить" я б рад, просто авто логин без этого не делается.
3. "А вот это изобретение "хитрых ключей" я вообще не понял, для чего оно?". Тут просто всё. При авторизации я сгенерировал ключ, не принципиально как именно (согласен, перегнул), но сделал и отдал юзеру в куки это одно 40 значное значение. Важен сам факт создания в БД 2 колонок key, user_id. Когда юзер пришел на сайт снова, у него сервер сначала смотрит ключ (ну мало ли сохранен). Рас, и нашел, проверил по базе и определил чей это id и стартонул сессию SESSION['id']. А дальше как обычно. Понимаю, тут может быть жесткая ошибка сладкая для хацкеров (допустим). но по логике вроде не обойти.
_____________
..Работает - не трогай!
Ну и последний вопрос, мужики, не игнорьте)
Я разобрался со всеми механизмами сессий
На счет автологина все же важно еще понять..
Когда клиент первый раз логиниться, стартует сессия и пошло дело. В момент этой авторизации создается еще и файл куки со 40 значением, это ключ. Набор букв и цифр рамдомный, обернутый sha1.
В БД сохраняется пара `user_id` и `key`, то есть SESSION['id'] и sha1(ключ куки)
ВСЁ!
Когда клиент вновь попадает на страницу Личного кабинета и сессия не начата, проверяется наличие файла cookie. Если файл присутствует и ключ по БД совпал, то стартуем сессию и добавляем SESSION['id'] из значения `user_id` из БД.
Иными словами по 40 значному ключу куки мы проверяем какой это ID и стартуем сессию.
Надежно?
_____________
..Работает - не трогай!
Я разобрался со всеми механизмами сессий
На счет автологина все же важно еще понять..
Когда клиент первый раз логиниться, стартует сессия и пошло дело. В момент этой авторизации создается еще и файл куки со 40 значением, это ключ. Набор букв и цифр рамдомный, обернутый sha1.
В БД сохраняется пара `user_id` и `key`, то есть SESSION['id'] и sha1(ключ куки)
ВСЁ!
Когда клиент вновь попадает на страницу Личного кабинета и сессия не начата, проверяется наличие файла cookie. Если файл присутствует и ключ по БД совпал, то стартуем сессию и добавляем SESSION['id'] из значения `user_id` из БД.
Иными словами по 40 значному ключу куки мы проверяем какой это ID и стартуем сессию.
Надежно?
_____________
..Работает - не трогай!
| Цитата (maximka787 @ 24.06.2015 - 13:20) |
| killer8080 Ты разрушил мой мир(( |
так бывает
| Цитата (maximka787 @ 24.06.2015 - 13:20) |
| Меня вообще интересовало всего 2 важных момента: Защитить сайт от подмены SESSION['id'], чтобы юзер НИКАКИМ образом не сделал что-то от лица (ID) другого. И авто логин, без которого - Цитата: "сейчас уже сайты даже не делают" |
Подменяют не данные сессии, а ключ к ней! Делается это разными способами, либо угон сессионных кук через XSS уязвимости (если таковые есть), либо снифером перехватывают трафик, либо через вирусы. От последних защитится ты никак не можешь, это забота самого юзера. От XSS можно обезопасится включением опции httponly для кук. От сниферов использовать только https, это конечно не даст 100 процентной безопасности, но существенно повысит стоимость взлома при пассивном перехвате (о MITM атаках с подменой сертификатов речь конечно не идёт
)Насчет автологина, да, если он нужен то без бд не обойтись.
| Цитата (maximka787 @ 24.06.2015 - 13:20) |
| 1. Ну к примеру сессию с привязкой к юзер агенту я уберу. ОК. |
да это в общем то не важно, как доп уровень защиты от школоты сойдет
| Цитата (maximka787 @ 24.06.2015 - 13:20) |
| Хватало. Но когда встал НАСТОЙЧИВЫЙ вопрос сделать авто логин, начал заново перечитывать инфу из "статеек" и пришел к выводу, что почти все кодеры хранят сессии в БД, проверяют куки и делают много работы. Так что "На куки можно забить" я б рад, просто авто логин без этого не делается. |
я имел ввиду удалять куки у клиента совсем не обязательно, А насчет автологина, паранойя в безопасности с автологином вообще не совместима, при паранойе нужно ещё сессию к IP привязывать
| Цитата (maximka787 @ 24.06.2015 - 13:20) |
| 3. "А вот это изобретение "хитрых ключей" я вообще не понял, для чего оно?". Тут просто всё. При авторизации я сгенерировал ключ, |
зачем нужно генерировать второй ключ? Сессионного тебе не достаточно? Безопасность от этого выше не станет, если куки угонят, то хоть десять ключей сгенери, это уже не будет иметь никакого значения
| Цитата (maximka787 @ 26.06.2015 - 13:03) |
| На счет автологина все же важно еще понять.. Когда клиент первый раз логиниться, стартует сессия и пошло дело. В момент этой авторизации создается еще и файл куки со 40 значением, это ключ. Набор букв и цифр рамдомный, обернутый sha1. В БД сохраняется пара `user_id` и `key`, то есть SESSION['id'] и sha1(ключ куки) ВСЁ! |
вместо sha1(ключ куки) просто session_id(), и я бы добавил поле last_visit чтоб можно было мусор потом удалять, зачем нужен вечный автологин
Здесь расположена полная версия этой страницы.