[ Поиск ] - [ Пользователи ] - [ Календарь ]
Полная Версия: Варианты авторизации
Страницы: 1, 2, 3, 4
killer8080
Цитата (Медведь @ 14.02.2016 - 21:10)
Цитата (FatCat @ 7.02.2016 - 20:45)
Пароль шифруется и хранится в базе зашифрованный. По мне, md5 достаточно, но кто хочет, может с солью, не принципиально.
Дальше к зашифрованной строке пароля добавляю айпишник, и снова md5 - получаю идентификатор сессии, который пишу в БД в таблицу сессий и в куки.

$res  = md5(пароль);
$res .= $_SERVER['REMOTE_ADDR'];
$avt = md5($res);
$user_session = session_id();

Записать в таблицу ($avt, $user_session);
Записать в куки($avt);


Как то так?

много лишних движений.
Если нужно привязать сессию к IP, достаточно просто записать его в сессию и потом сравнивать. Ненужно почем зря хеши вычислять.
FatCat
Принцип такой.
Но у меня сессии в БД. Пароль хранится в таблице паролей, а для авторизации таблица сессий.

_____________
Бесплатному сыру в дырки не заглядывают...
Игорь_Vasinsky
на один айпи не стоит уповать, у нас район города на одном айпи сидит.
нужно ещё к чему нить привязаться.

_____________
HTML, CSS (Bootstrap), JS(JQuery, ExtJS), PHP, MySQL, MSSql, Posgres, (TSql, BI OLAP, MDX), Mongo, Git, SVN, CodeIgnater, Symfony, Yii 2, JiRA, Redmine, Bitbucket, Composer, Rabbit MQ, Amazon (SQS, S3, Transcribe), Docker
killer8080
Цитата (FatCat @ 15.02.2016 - 05:13)
Принцип такой.
Но у меня сессии в БД. Пароль хранится в таблице паролей, а для авторизации таблица сессий.

Хранилище сессий тут роли не играет, какой смысл замешивать ip в идентификатор, если его можно просто хранить в той же таблице с сессиями?
FatCat
Цитата (killer8080 @ 15.02.2016 - 11:38)
какой смысл замешивать ip в идентификатор

Чтобы в случае угона куки не могли авторизоваться с другого айпишника.

Вероятность, что угонщик куки окажется с одинаковым айпи весьма мала.

_____________
Бесплатному сыру в дырки не заглядывают...
Миша
Мысли вслух. Для начала нужно отсечь перебор аккаунтов с помощью одного пароля, для этого вешаем на конкретный IP количество неудачных попыток входа. В связи с тем, что IP можно изменить, аналогичное нужно сделать и на перебор паролей под конкретный аккаунт, делаем количество неудачных попыток входа под конкретный аккаунт.

Что касается самой авторизации, как выше отметил Игорь, IP доверять нельзя, у многих он динамический (вводить пароль 10 раз blink.gif ) или на одном IP может сидеть небольшой посёлок.

Из всего этого у нас имеется блокировка на тупой перебор ) Дальше печеньку или сессию, многие предлагают последнее, так и поступим )) Хотя нагрузка на сервер, ну да ладно. Что туда запишем? Ваши предложения )

_____________
Принимаю заказы, писать в ЛС
Миша
В сессию записать:

Пользователь в таблице авторизации (id при каждой авторизации) + user agent?

Если произойдёт подмена, то скидываем?

_____________
Принимаю заказы, писать в ЛС
FatCat
Цитата (Медведь @ 16.02.2016 - 13:43)
для этого вешаем на конкретный IP количество неудачных попыток входа

То есть, поле в таблице и специальный код только для защиты от брута?

ИМХО, любой посетитель, создающий избыточную нагрузку на сервер - это вредный посетитель, и его нужно блокировать.
И не важно, брутит ли он пароли, или ворует информацию в сплог, или просто линки считает. В таблице сессии пишется time() от каждого запроса любой страницы. Меньше 2 секунд от записанного до текущего запроса - предупреждение о недопустимости двойных кликов по ссылкам и минус единичку в карму. Набрал -50 в карме - бан на 10 суток.

_____________
Бесплатному сыру в дырки не заглядывают...
Миша
Буду знать ) А как с пауками поисковиков? И что касается второго пункта?

В случае верной пары, логин и пароль, записать в таблицу авторизации id пользователя.
В сессию записать id авторизации + user agent.

_____________
Принимаю заказы, писать в ЛС
FatCat
Цитата (Медведь @ 16.02.2016 - 18:08)
как с пауками поисковиков?

Так же как с зарегистрированными - для них нет проверки на нагрузку.
Мы их и видим на главной в списке посетителей по именам.

_____________
Бесплатному сыру в дырки не заглядывают...
Миша
Цитата (FatCat @ 16.02.2016 - 19:49)
Цитата (Медведь @ 16.02.2016 - 18:08)
как с пауками поисковиков?

Так же как с зарегистрированными - для них нет проверки на нагрузку.
Мы их и видим на главной в списке посетителей по именам.

Поделитесь, как вы находите этих пауков? )

_____________
Принимаю заказы, писать в ЛС
FatCat
Цитата (Медведь @ 17.02.2016 - 04:45)
как вы находите этих пауков?

Есть список основных ботов. Для начала по списку.
Дальше отслеживать айпишники, создающие большую нагрузку, пробивать по gethostbyaddr и решать: если "полезный", то добавлять к списку полезных ботов, если нет, то банить наравне со шламмерами.

_____________
Бесплатному сыру в дырки не заглядывают...
Миша
Цитата (FatCat @ 17.02.2016 - 07:58)
Цитата (Медведь @ 17.02.2016 - 04:45)
как вы находите этих пауков?

Есть список основных ботов.

Понял уже, что у вас есть, поэтому и спрашиваю, может поделитесь )

_____________
Принимаю заказы, писать в ЛС
FatCat
Цитата (Медведь @ 17.02.2016 - 07:09)
поделитесь

if ( preg_match( '/(YandexBlogs|googlebot|google-proxy|slurp@inktomi|ask jeeves|lycos|whatuseek|ia_archiver|aport|yandexbot|stackrambler|yahoo|msnbot|webalta|Mail.Ru|bingbot| mj12bot|exabot|baiduspider|hosttracker|AhrefsBot|SputnikBot|BLEXBot)/i', $s_user_agent, $match ) )


_____________
Бесплатному сыру в дырки не заглядывают...
killer8080
Цитата (FatCat @ 15.02.2016 - 22:33)
Чтобы в случае угона куки не могли авторизоваться с другого айпишника.

но для этого необязательно его совать в хеш.

Цитата (FatCat @ 15.02.2016 - 22:33)
Вероятность, что угонщик куки окажется с одинаковым айпи весьма мала.


куки уводят двумя способами: через XSS дырку (если есть), либо сниффингом. От первого можно защитится флагом httponly (ну и само собой уязвимостей не допускать smile.gif ), от второго только шифрование трафика. Сниффинг происходит чаще всего на последней миле, и она очень часто бывает за NAT-ом, так что привязка ip не особа полезна, а в случае с автологином и не допустима. лучше уж тогда переходить на https.


Цитата (Медведь @ 16.02.2016 - 14:43)
Дальше печеньку или сессию, многие предлагают последнее, так и поступим )) Хотя нагрузка на сервер, ну да ладно.

Я вот не пойму откуда такое стойкое предубеждение против сессий? Какая нагрузка? Неужели ты правда думаешь что десереализация маленького файлика создаёт такой напряг серверу? Поверь это далеко не самое узкое место. wink.gif Но если такая уж паранойя по поводу одного лишнего обращения к hdd. ну так вынеси хранилище на tmpfs.
Цитата (Медведь @ 16.02.2016 - 14:43)
Из всего этого у нас имеется блокировка на тупой перебор )

а что такое тупой перебор? Как ты его себе представляешь? Попробуй для начала посчитать какое количество запросов подбора в секунду выдержит твой сервер, прежде чем упасть, и какое количество комбинаций нужно перебрать, и сколько в твоем случае на это уйдёт времени. wink.gif
Быстрый ответ:

 Графические смайлики |  Показывать подпись
Здесь расположена полная версия этой страницы.
Invision Power Board © 2001-2024 Invision Power Services, Inc.