Как защитить от взлома сессии и куки?

Здравствуйте, подскажите как защитить от взлома сессий и куки.Везде ищу не могу найти.У меня есть код но я не думаю что он безопасный
Пароль и логин зашифрован с помощью md5 и sha256
я знаю что можно поставить защиту на проверка браузера через $_server и по ip но не думаю что это поможет защитить сайт?

0

А зачем в сессии нужен логин и пароль?

0

Сообщение от viktor1998 Здравствуйте, подскажите как защитить от взлома сессий и куки.Везде ищу не могу найти.У меня есть код но я не думаю что он безопасный PHP 1 2 3 4 5 6 7 if($log==$quer['login'] && $lpass==$quer['pass']) { $_SESSION['login']=$quer['login']; $_SESSION['pass']=$quer['pass']; header("location: "); exit(); } Пароль и логин зашифрован с помощью md5 и sha256 PHP 1 2 $_POST['login_1']=sha(md5(x($_POST['login_1']))); $_POST['pass_1']=sha(md5(x($_POST['pass_1']))); я знаю что можно поставить защиту на проверка браузера через $_server и по ip но не думаю что это поможет защитить сайт?

viktor1998, Можете генерировать случайную строку с помощью sha1 или md5 от конкатенации любых данных:
Добавлено через 1 минуту

Сообщение от viktor1998 Здравствуйте, подскажите как защитить от взлома сессий и куки.Везде ищу не могу найти.У меня есть код но я не думаю что он безопасный PHP 1 2 3 4 5 6 7 if($log==$quer['login'] && $lpass==$quer['pass']) { $_SESSION['login']=$quer['login']; $_SESSION['pass']=$quer['pass']; header("location: "); exit(); } Пароль и логин зашифрован с помощью md5 и sha256 PHP 1 2 $_POST['login_1']=sha(md5(x($_POST['login_1']))); $_POST['pass_1']=sha(md5(x($_POST['pass_1']))); я знаю что можно поставить защиту на проверка браузера через $_server и по ip но не думаю что это поможет защитить сайт?

viktor1998, И почитайте эту страницу: https://vk.com/dev/api_nohttps

0

Сообщение от qwertyyyyyw Пароль и логин зашифрован с помощью md5 и sha256

Сообщение от viktor1998 $_POST['pass_1']=sha(md5(x($_POST['pass_1'])));

хеширование хеша довольно бессмысленное занятие, тем более что для шифровки паролей столет существует ф-я password_hash(), а хешировать логин вообще незачем

Сообщение от viktor1998 на проверка браузера через $_server и по ip

не помешает, на случай если уведут id сессии.. можно отсечь запрос с левого сайта. хотя не панацея.
Нужно отказаться от опции rememberMe на сайте и время от времени регененрировать id сессии. От пионэров слегка обезопаситесь.

0

Сообщение от viktor1998 Здравствуйте, подскажите как защитить от взлома сессий и куки.

В третий раз напишу как это делается. Уровень защиты данного метода - средний. Можно сделать и лучше, но кому это надо?
Вы же не делаете систему для банка?

В базе -(таблице users) храним:уникальный id записи, логин пользователя, хеш пароля пользователя, соль (случайная комбинация, например !34Hdff^7), идентификатор сеанса.
При создании нового пользователя, где пользователь указывает логин и пароль - создаем случайную соль.
С использованием этой соли и введенного пользователем пароля создаем хэш пользователя, используя алгоритм и функцию необратимого шифрования.
Например
Все эти данные заносим в БД в таблицу users.

При входе в систему пользователь вводит логин и пароль.
Система вычисляет хеш пароля и ищет совпадения в БД - таблице users. Ищет такой хэш и имя пользователя.
Если находит - вносит в поле идентификатор сеанса таблицы, в запись этого пользователя случайное значение (например @3232!sddf).
Это же значение вносит в куку пользователя.
Далее ищет значение из этой куки пользователя в БД. Нашли - мы знаем кто это. Иначе - неизвестный пользователь, гость.

Обратите внимание, что в куке хранится значение никак не компроментирующее пароль.
Если куку похитит злоумышленник, то он получит временный доступ. И не получит никакой информации об логине/пароле. Вообще никакой. Более того, как только пользователь выйдет и снова войдет в систему - злоумышленник потеряет доступ.

Если злоумышленник получит доступ к БД и получит хэш пароля, то он его не расшифрует. И никакие таблицы, подбор ему не помогут.
Это гарантируется солью вида !34Hdff^7. Долго перебирать (смотри теорию вероятностей+комбинаторику).
К тому же злоумышленник не знает алгоритма. А алгоритм может быть любой. Значит злоумышленнику нужен доступ к файловой системе.
Имея такие доступы - перебирать пароли не имеет смысла.

Добавлено через 4 минуты

Сообщение от a-fw хеширование хеша довольно бессмысленное занятие

Круто сказали. Плакала вся криптография. Там проходы какие то. По двадцать раз через функции прогоняют что то. Зачем?
А вы так раз - бессмысленно.
Почему не бессмысленно, я написал выше. А ещё есть понятие криптостойкости.

Сообщение от a-fw сессии

куки, только куки. Сессии зло.

0

Сообщение от useruser хеш пароля пользователя, соль

дедушкины рецепты столетней давности не актуальны

Добавлено через 50 секунд

Сообщение от useruser Сессии зло.

Это кто-то из великих сказал?

Добавлено через 8 минут

Сообщение от useruser По двадцать раз через функции прогоняют что то. Зачем?

Дураки потому что
sha(md5(x($_POST['pass_1']))); ни чем сложнее для подбора чем просто sha('stroka'); . Потому что нам не нужно подбирать строку. нам нужно подобрать хеш... который всегда 256 битный.. независимо от того сколько раз вы там чегото кудато прогнали

0

Сообщение от a-fw дедушкины рецепты столетней давности не актуальны

Аргумент.

Сообщение от a-fw Потому что нам не нужно подбирать строку

Плохо дело... Не доходит.
Я вам настоятельно советую изучить криптографию.

Сообщение от a-fw нам нужно подобрать хеш

Ну ок. С помощью SQL инъекции (XXS атаки или черной магии - выберете сами) вы смогли извлечь хэш.
Что делать с ним будете? Скрипту нужна строка, которую по алгоритму он преобразует в хэш.
И этот хэш сравнит с хэшем в базе.
Скрипач...т.е. хэш нам не нужен. Вообще. Зачем вам нужен этот набор бессмысленной ерунды?

0

Сообщение от useruser Скрипту нужна строка, которую по алгоритму он преобразует в хэш.

для брутфорсера все равно как вы хешируете, просто пользуясь вашей терминологией при одном прогоне строка для получения хеша будет "вася", а при двух прогонах "петя". Количество вариантов хеша всегда определяется сложностью алгоритма обладающем минимальной "битностью". Так что я погорячился насчет 256 битного хеша. Количество всех вариантов хешей полученых с помощью sha(md5) ровно такое же с
как и вариантов полученных с помощью md5 без извращений. Поэтому лучше хешировать простым sha($string) вариантов будет больше, а вероятность коллизий - меньше. А еще лучше не заниматься велосипедостроительством, а воспользоваться возможностями php о которых я писал выше

0

Очень мутная схема... Я так и не понял зачем нужна "соль"...

Сообщение от a-fw для брутфорсера все равно как вы хешируете

Против брутфорса есть другие защиты - блокировка пользователя на пол часа после неправильных 3-5-10 комбинаций. С последующим нарастанием времени блокировки. Можно после 3х неправильных капчу показать.

Сам сейчас пишу "с нуля" авторизацию. Пошел по другой схеме - после успешной авторизации выдаю юзеру РАЗОВЫЙ кллюч, абсолютно случайный, но не повторяющийся. Достаточно длинный для опасности подбора md5(rand(9999))+md5(rand(9999));
Ключ пишется в куки. И в базу "напротив" юзера. У меня для сессий отдельная таблица - туда и пишу. Вместе с датой последнего обращения (подсчет времени бездействия) и сроком автовыхода (например час, сутки или неделя). Украсть куку реально, но еще идет привязка к броузеру, ОС и IP. Если IP еще может сменится(у меня хостинг иногда переключает), то ОС+Броузер вряд-ли...

ИМХО эта заготовка подойдет даже для банка... 10 минут бездействия может выбить. Но активная работа (смена страниц) продлевает сесию, но в пределах суток... можно контролировать количество одновременных сессий. Весь контроль ТОЛЬКО на сервер! Можно привязаться еще и к сессии для безопасности (я так понял что сессию тяжелее перенести, но комп/хостинг может сам ее сбросить)

0

Сообщение от Tester64 Очень мутная схема... Я так и не понял зачем нужна "соль"...

Сообщение от Tester64 После успешной авторизации выдаю юзеру РАЗОВЫЙ кллюч, абсолютно случайный, но не повторяющийся. Достаточно длинный для опасности подбора md5(rand(9999))+md5(rand(9999)); Ключ пишется в куки. И в базу "напротив" юзера.

Где то я это уже видел

Сообщение от useruser Если находит - вносит в поле идентификатор сеанса таблицы, в запись этого пользователя случайное значение (например @3232!sddf). Это же значение вносит в куку пользователя.

Сообщение от Tester64 Очень мутная схема... Я так и не понял зачем нужна "соль"...

Я вижу, что в отличии от a-fw вы начинаете понимать. Вам объясню.
Вся эта схема - чистой воды выдержка из криптографии и необратимости функций. Перед нами стоит задача сделать так, что бы злоумышленник по хешу не подобрал пароль.

Вот даже назвали соль. Специально. Соль бросают в суп. Вы можете бросить соль в суп? Да. Это легко.
А достать из супа соль? Уже проблематично. В данном случае суп - это наш хеш с солью, многочисленными приправами из md5 (вот зачем по сто раз прогоняют). И в результате мы получим наш суп - хеш. Этакую смесь из всего подряд.
И черт там разберёшь, сколько соли в него кинули. А хакеру это нужно. По смеси восстановить все ингредиенты.
Это нелегко (а иногда невозможно при текущих вычислительных мощностях), даже зная рецепт супа (алгоритм). (Привет криптосистеме с открытым ключом)
В теории вероятности и криптографии часто приводят пример с красками. Но вроде и я привёл не плохой пример.
Экспромт, между прочим.

Если заинтересовало, можете почитать криптографию, криптоанализ. Про шифры, их историю.
Тогда точно вот такого, как сказал a-fw

Сообщение от a-fw Количество вариантов хеша всегда определяется сложностью алгоритма обладающем минимальной "битностью".

вы уже точно никогда не скажете.

0

0

0

0

0

0

Сообщение от useruser Перед нами стоит задача сделать так, что бы злоумышленник по хешу не подобрал пароль.

Еще раз перечитайте мою "схему"! Хакеру НЕЧЕГО "перебирать"! Пока он не получит ПОЛНУЮ базу пользователей с паролями с моего сервера!

Еще раз:
1) вы передаете мне логин/пароль в $_POST['login'] и в $_POST['pass'] из формы ввода. (не знаю можно ли этот этап перехватить, но вроде все так делают. В крайнем случае попробую https)
2) сервер сверяет ваш пароль со своей внутренней базой и если все правильно вам выдается абсолютно случайный ключ! Не привязанный ни к логину, ни к паролю. Ломать его бесполезно! В крайнем случае можно привязать к логину и числу из rand. Считается что на защищенном сервере утащить базу с логинами и md5(пароля) не возможно.
3) вы кладете этот временный ключ себе в куки. с таймером хоть на 10 лет.
4) когда надо убедиться что вы залогинены, я получаю вашу куку с ключем и сверяю с таблицей зарегистрированных. Если этот мега-ключ найден в таблице, то я знаю что вы за юзвер. (параллельно могу убедиться что ключ "не перемещали" - ip+brozer+OS)
5) в той-же МОЕЙ таблице и реальный срок окончания сессии. Через (допустим) час очередная страница при проверке авторизованности вдруг обнаружит что нет. Или (позднее) это сделает аякс-проверяльщик встроенный в таблицу.
6) когда вы хотите логАут, то просто я удаляю вашу сессию из МОЕЙ таблицы.

? ну и где здесь можно "взломать"? Брутфорс отсекается через 3-5-10 попыток на пол часа/час/сутки или капчей.
Выданный вам ключ сессии для куков не несет никакой инфы, кроме логина для лучшего удержания уникальности - типа md5("вася_as0dd20dls").md5("вася_$%@02ld 90skjsdi").md5("вася_woc,wos-2-230@").

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

p.s. я не читал "криптографию" и даже не смог найти адекватное обьяснение механизмов авторизации "не школьного уровня" и не на чужом API(типа ВКонтактовских получили ключик от нас, а мы обеспечим вас всем остальным). Все сам придумывал или "догадывался" на основе чужих API... И готов выслушать любую критику!

Сообщение от useruser Где то я это уже видел

Я уже 3ю неделю это пишу... уже не первый вопрос даже ЗДЕСЬ задаю...

0

Tester64, использую практически ту же схему авторизации. Интересно было бы услышать её конструктивную критику, поскольку аналогов впринципе и не вижу.

0

Сообщение от Tester64 2) сервер сверяет ваш пароль со своей внутренней базой

Дальше можно не читать Для вас, похоже и придумали password_hash().
Вы храните пароль в БД в открытом виде?

Сообщение от Tester64 ? ну и где здесь можно "взломать"? Брутфорс отсекается через 3-5-10 попыток на пол часа/час/сутки или капчей.

Вы в принципе понимаете, как взламываются сайты? Базы, основы?
Самое распостраненное - SQL инъекция. Реже xss атака. Погуглите. Там материала на 10 минут. А можно и глубже изучить тему и даже попробовать. Интересно же.
Ещё реже ломают через - уязвимость ПО, стороннего ПО, переполнение памяти (смещение адресов).
Хотите по школьному, брутфорсом? Программ миллион и все используют анонимайзеры. Но так не ломают.

Уважаемые участники сообщества, тут люди хранят в БД пароли в открытом виде.
Не ожидал такого.

Сообщение от Jodah Интересно было бы услышать её конструктивную критику

Так как пароль хранится в БД в открытом виде, такая система авторизации рай для хакера. Просто рай.
Предположу, что все логины и пароли будут успешно украдены из БД через SQL инъекцию в результате недостаточной фильтрации данных, в следствии низкой компетенции разработчика. И это не я выдумал - это прописная истина и азы.

0

Возможно некоторые "специалисты работавшие долгие годы в сфере информационной безопасности сдипломом" осилят адаптированную статейку http://habrahabr.ru/post/194972/Хотя вряд ли, они настолько суровы что даже инструкции к языку не читают

0

0