Я понимаю - что существует куча уже готовых библиотек - но мне хочется понять смысл работы на самом простом (но при этом функциональном примере). Ну и созданное своими руками всегда греет душу) Достаточно ли безопасным является такая нехитрася схема - 1) пользователь заходит вводит форму 2) форма проверяется. Если все норм то - 3) создается новая сессия в которую записыватся ID пользователя 4) редирект на туда куда юзер хотел (ну для удобства, и на случай если куки не работают а очень нужно на сайт). Ну и потом при каждом действии которое требует логина - проверяется сессия, если нет - то редирект на форму логина/пароля. Если есть - то просто по ID пользователя берутся нужные данные и делаются нужные дейтсвия без доп проверки. (ну т.е. мы доверяем сессии так как это на сервере и мы сами написали а не пользовательские данные) Или ОБЯЗАТЕЛЬНОМ порядке нужно делать хитрые токены и другие хитроумные схемы. Так как прочитав о них, я не понял их назначения т.к. сессия само по себе хранитьсян а сервере, и она уникальна. (понятно что возможна кража куки с ID сессии с компьютера пользователя, но это не слишком ли маловероятная опасность? ну и при этом злоумышленник получит только ходить под одним пользователем до того момента покан е истечет срок действия сессии) В чем вообще смысл токенов? как идеи. и вторая часть по теме - password_hash() - поясните как он придумывет соль? Нужно ли вручную аппендить соль к паролю?? (в мануале написанно, что параметр соль считается deprecated) Я например хотел реалзовать велосипедный метод по генерации соли к в зависимости от ID пользователя и буков в нике. Но нужно ли? и маленький вопросец - будет ли каким образом меняться механизм работы и уровень защищенности при подлючении SSL? (естевственно в данном контексте - сессии и кука в которой ID сессии храниться, а не шифрование трафика) И достаточно ли для этого подключить сертификат(через хостинг) и прописать принудительный редирект. RewriteEngine On RewriteBase / RewriteCond %{HTTPS} off RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} Знаю ламер - но помогите братушки-ребятушки☻ В интернете и даже в англоязыном секторе очень много разных мнений написанно по этому поводу.
меры безопасности должны быть прямо пропорциональны важности информации на твоем сайте, потому что многие штуки лишь усложняют жизнь клиентам. При желание можно хоть двойной вход через смс можно сделать. Что за токены я даже не знаю. Можно например в сессию писать подсеть клиента и сверять ее тоже. Тогда даже кража не поможет в php 7 соль вроде выпилили. Соль самому генерить НЕ НУЖНО По поводу ссл не знаю ничего, но логика подсказывает мне, что на печеньках и сессиях это никак не отразится.
как реализовал: сам lib который проверяет, был ли авторизован или нет https://github.com/MouseZver/Mouse_Project/blob/master/inc/Application/Controller/User/AuthMe.php --- Добавлено --- Рег: https://github.com/MouseZver/Mouse_Project/blob/master/inc/Page/register/init.php --- Добавлено --- авторизация https://github.com/MouseZver/Mouse_Project/blob/master/inc/Page/auth/init.php --- Добавлено --- тут все хтмлки https://github.com/MouseZver/Mouse_Project/tree/master/views
Интересный пример! Спасибо! Но хотел спросить - а в чем смысл - setcookie ( 'AuthMe', $SID, strtotime ( self::$RAY['RAY']['AUTHME']['LIMIT'] ), '/' ); именно в куке, а не в session_start и $_SESSION["userId"]
Я тогда понял) А будет ли достаточно (что бы не делать отдельную таблица за учетом сессий) - хранить в куках пользователя - имя + hash (например id+имя+хэш-пароля) и сверять эту штуку, если сессий уже уничтожилась?
Я просто руководствуюясь - https://php.ru/forum/threads/logika-raboty-s-chek-boksom-zapomnit-menja.51279/page-2
При заходе пользователя - создавать куку в которой храниться - имя пользователя (или id) и хэш (не просто хэш пароля, а хэш строки id+имя+хэшпароля) эту строку добавить еще одной колонкой в таблицу users. (ну или пересчитывать каждый раз) северять с этой строкой в куке с базой. если это соответсвует то впускать пользователя. Если нет то не пускать. Просто я не понимаю в чем выгода от использования отдельной таблицы в которой записываются сессии?
это таблица *SESS_REMEMBERS* создана чтобы держать не рег инфу пользователя имя пароль пол сколько годиков и т.д. --- Добавлено --- а для восстановления сессии юзера на сайте. Ибо ты на пхп.ру процедуру авторизации каждый раз проходишь ?
Не я это понял) Что там записыывается ssid Но почему нельзя у пользователя в куке его информацию о сессии (так скажем его ункальную подпись). Пароль из нее все равно утащить будет невозможно, а если злоумышленник сможет украть куку то - он сможет в любом случае от имени этого пользователя совершать какие то действия (ну если не привязывать к конкретным параметрам браузера или ip,что не очень хорошо). Т.е. зачем нужна отдельная таблица если эту строку можно просто в куке хранить? В чем плюсы?
Если у тебя там только публичный id и хешпароля, то конечно можно и так по идеи. Но в сессии можно хранить дохрена всего, чтобы ты хотел сохранить в тайне, даже если куку сопрут. Сессии используются не только для авторизации, но и чтобы, например, не таскать все между страницами.
А я понял - т.е. таблица с учета сессий делается для того, что бы хранить какие-то доп данные, и что бы на разныех устройствах при подключении юзера эти доп данные были разными (т.е. не централизованно к юзеру а к каждой сессии отдельно?)
Ты спросил зачем хранить это в сессии в базе, а не напрямую в куках. Я тебе ответил. Зачем ты что-то еще потаенное ищешь там? Хранишь в сессии что душе угодно. в куке - только id сессии!
если ты сверяешь с чем-то, что просто записано в базе, то тогда лучше использовать что-то рандомное, чтобы точно нельзя было подобрать. сверять тоже надо правильно. иначе есть опасность атаки перебором с оценкой времени ответа.
ага, но в чем прикол если сравниваем 100 летний хеш пароля при регистрации и не менял, он будет показывать всегда истину получается. Неужели при регистрации придется еще функцию допилить, пизжу... в сесссию template @последний полученный пароль при авторизации @недавней ?
что? я нифига не понял можно пример? --- Добавлено --- Это функция сравнения строк, которая сравнивает их одинаковое количество времени, не зависимо от того, насколько они разные. Это нужно чтобы избежать подбора чего угодно через большое число попыток, т.к. при каждом ответе по задержке можно судить о том, на каком символе строки не сопадают. И да, рандомная задержка тут не поможет.
18 марта 2010 года некий ИгорьДата зарегестрировался на форуме и ни разу не менял пароль, включая данный момент. Т.е хеш пароль имеет так же и тайм unix, сверяем... 1000 раз введенный пользователем пароль -> зеш пароль === hash-equals ( хеш пароль 18 марта 2010 года ) TRUE TRUE TRUE TRUE TRUE TRUE ... какой толк от функции тогда ? --- Добавлено --- тобишь она запоминает ранее проверочный хеш ?
чувак, она разговор не о хешах просто в "запомнить меня" нужно сверять строки константно по времени хеши тут не при чем толк такой, что при сравнении строк по времени ответа от сервера можно понять, на каком символе спотыкается проверка. это дыра, которая позволяет на длинносрочных секурных хернях подобрать настоящую строку это раз два, то, что я зарегался и никогда не менял пароль не означает, что там тот же самый хеш сидит. Т.к. при каждом логине я ввожу пароль, и если он правильный, то сервер может замутить новый хеш с новой солью. Но от перебора пароля это не спасает. От перебора пароля не спасает ничего.