Тогда это магия вуду)))
Надеюсь записывал данные в переменную $_SESSION и использовал эту переменную ты не в 1-ом файле?
Нет. Задача-то и была записать переменную в одном файле, а вывести в другом после отправки поста. (Добавление)
Проверил всю папку - везде закомментировал старт сессии и автостарт выключен
Всем привет!
Сейчас вот столкнулся с такой штукой.
Задача в общих чертах такова:
есть модуль авторизации, который выводит форму или приветствие вверху страницы
если юзер ввел неверные данные, не ввел все или вообще нажал кнопку регистрации, то хочу выводить разные формы в область контента, то есть в совсем другой див.
Ну с выводом форм кое как разбираюсь. Но вот еще возникла необходимость выводить над формой сообщение. К примеру, если пользователь ввел некорректные данные или не заполнил поля, то выводится одна и та же форма, которая лежит в отдельном файлике. Однако, нужно над формой писать разные сообщения, типа введены не все данные и данные не верны.
Долго думал, как передать из модуля авторизации переменную с сообщением. И решил попробовать через сессию. И какого же было мое удивление, что строка записалась в $_SESSION без session_start(). То есть я не стартовал сессию, а просто написал
$_SESSION['auth_incorrect'] = 'Данные не верны';
Это нормально? Можно ли вообще пользоваться $_SESSION для передачи данных между перегрузками страницы? К примеру написать class MessageHandler{}, который будет ловить месседжи и ерроры в $_SESSION ??
Есл нужно выводить именно форму - то делаете отдельную страницу авторизации и при случае редиректите туда. Если нужно просто вывести сообщение об ошибке - то напишите модуль SystemMessage() который будет аккумулировать системные сообщения от разных частей системы и выводить их в указанном месте.
Да, такой модуль нужен обязательно. А здесь нужно именно форму. То есть, если пользователь ввел что-то не то, то передается гет:
index.php?mod=auth&error=incorrect - некорректные данные, выводим форму
index.php?mod=auth&error=empty_field - заполнены не все поля, вывод формы
index.php?mod=auth&option=register - клик по ссылке регистрации, вывод другой формы
index.php?mod=auth&option=recovery - клик по ссылке восстановления пароля, вывод еще одной формы
index.php?mod=auth&error=block - N-ое кол-во попыток входа. Здесь уже можно вывести сообщение с помощью предложенного вами модуля.
А вот все формочки я думал сделать в модуле авторизации. Как например сейчас у меня в одном файле лежит форма, а в другом приветствие.
Ну помогите еще пожалуйста.
Сделал как выше написано. В диве на странице написал ModController('mod_auth'). В классе подключается файлик модуля авторизации. Код модуля авторизации в конце принимает решение, что подключить - форму авторизации или приветствие.
А как бы сделать, чтобы при некорректных данных, выводилась форма, но только не в изначальный див, а в див контента?
makar3000
Ну это понятно - двойная проверка. Я имею ввиду, что я буду вынужден после смены алгоритма юзать двойную проверку. И после смены я смогу лишь попросить пользователей сменить пароли. А если я к примеру буду вырезать из sha512 32 символа и их писать в БД, то я даже не узнаю, где хеш md5, а где sha512.
Вот поэтому я и хочу сейчас определить метод хеширования.
в любом случае способ шифровния всегда можно поменять
Кстати...
К примеру я использую md5($pass) - уже есть 100 пользователей в БД. И тут я решил использовать hash("sha512", $pass) - как проверять те хеши, которые генерировал md5?
если доступа к Бд нет то достаточно простого MD5
а если есть то никакое шифрование не поможет.
не заморачиватесь с проблемами которых нет
Я тоже так думаю. Но вопрос в том, стоит ли повышать время шифрования. Усложнится ли задача взломщика, если у него есть БД, хеши, соли и мой алгоритм. То есть он будет делать банальный перебор. Но перебор будет долгим за счет алгоритма. Вот мне и интересно, как долго нужно шифровать - 0.3, 0.5, 1... сек
Многие пишут, что украв куку сессии можно как-то что-то нехорошее наделать. В общих чертах - сессии не совершенны.
Украв куку сессии, он не сможет увидеть ни содержание сессии ни изменить ее.
Можешь еще добавить какие-то дополнительные хэши в сессию/куку и затем сверять их.
Понятно, мануал я читал.
Я так понял, что нет смысла извращаться с шифрованием, но и ограничиваться однократным md5 без соли тоже нельзя.
Уникальная соль пользователя хранится всегда рядом с паролем, так как нет смысла ее скрывать, если она действительно для каждого уникальна. Методы шифрования в алгоритме тоже по большому счету не имеют значения. Если алгоритм украден, то все.
То есть не важно, прогнал я пароль 5 раз через md5 или по разу через разные методы. Пусть я даже несколько раз порезал и склеил разные хеши и еще раз все захешировал - плевать.
Я так понял, важно время выполнения хеширования. Пусть это даже будет прогон через md5 100000раз. Потом по словарю проверять будет уже долго.
Из этого я делаю вывод, что нужно увеличить время хеширования, что немного увеличит безопасность, даже если украли алгоритм.
Вопрос: какое время оптимально для шифрования. Выше я привел пример, который выполняется примерно 0,3 сек. Но на время влияет и железо, так ведь? У меня на ноуте 1.6 ГГц.
И еще, немного я непонял про crypt(). Вроде как механизм шифрования имеет зависимость от системы. То есть при переносе сайта алгоритм может просто отказаться работать или будет работать не так и все хеши можно будет выбросить.
А что насчет hash(). К примеру если я буду использовать hash() и sha512, на всех ли системах это будет работать.
Но самое главное, каково оптимальное время шифрования. Можно ведь и на md5 запустить цикл.А в цикле можно много чего делать со строкой. В последствии взломщик для подбора будет вынужден использовать именно мой - долгий алгоритм.
PS
Конечно же, это не главное. Главное то, нужен ли кому-то мой сайт. Если нужен очень, то поломают. Вопрос в том, как максимально затруднить процесс, чтобы не ломали все кому не лень.
смысл шифровать пароль есть в БД чтобы потом сравнивать при авторизации
Я имею ввиду при регистрации нового пользователя, его пароль шифровать как-то так.
caballero пишет:
а зачем в это вообще лезть? как работает сессия не имеет значения - вы можете зранить там что угодно включая пароли
Многие пишут, что украв куку сессии можно как-то что-то нехорошее наделать. В общих чертах - сессии не совершенны. Это не мое мнение. Ну да ладно, пусть будет PHPSESSID, но парочка хешей там не помешает.
Дальше вопрос по кукам.
Что если и имя и значение куки тоже будут какими-то вот такими хешами? В куки уже хешировать какие-то поля из БД.
Теперь сессии. На основе чего генерируется id сессии? Можно же ведь вместо имени сессии записывать такой хеш? Ну и значение тоже хеш чего-то там... юзер агент, ip (любые значения, за которыми не нужно лазить в БД)
Ну и самое главное - везде ли поддерживается sha512? (Добавление)
PS
Ну к примеру вот так (образно)
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 359
