Как правильно реализовать сессии при авторизции

Тема в разделе "Как сделать...", создана пользователем m1ko, 30 апр 2015.

  1. m1ko

    m1ko Создатель

    Регистр.:
    15 авг 2010
    Сообщения:
    42
    Симпатии:
    3
    Подскажите, как безопасно сделать авторизацию с сессией, и где ее хранить?

    И опасно ли хранить пароль в сессии?
    if (!empty($_SESSION['uid']) && !empty($_SESSION['login']) && !empty($_SESSION['password'])) { }
     
  2. ponchic

    ponchic Писатель

    Регистр.:
    8 авг 2014
    Сообщения:
    1
    Симпатии:
    1
    если пароль будет зашифрован md5(base64(md5())); то безопасно.
    И зачем сессии? Проще сделать в базе данных в таблице с пользователями ещё две колонки (session, datesession)
    Когда пользователь зайдёт, ему сгенериться сессия, и вместе с датой (в мускульном запросе NOW()) запишется в бд, а что бы значения наших полей удалялись можно в крон или планеровщик задач MySql добавить удаление их.
     
  3. Q_BASIC

    Q_BASIC

    Регистр.:
    30 ноя 2013
    Сообщения:
    385
    Симпатии:
    254
    Зачем еще крон? Добавить поле time и туда записывать UNIX time. Потом при получении сессии добавить:
    Код:
    WHERE `time`>".time()-86400."
    Это будет сессия на сутки
     
    ponchic нравится это.
  4. m1ko

    m1ko Создатель

    Регистр.:
    15 авг 2010
    Сообщения:
    42
    Симпатии:
    3
    Это по вашему 100% безопасно?)
     
  5. vitbsd

    vitbsd Постоялец

    Регистр.:
    26 ноя 2009
    Сообщения:
    111
    Симпатии:
    77
    Я сейчас вот тоже пытаюсь реализовать авторизацию правильную. Мысль есть такая, не хранить пароль вообще в сессиях и куках и т.д Генерировать некий ключ, по которому уже искать пользователя в БД. Пароль паролем а вот ВПИСАТЬ куда нибудь уникальный кусочек в куку и играться с ним. Ну и естественно при неверно маске IP - на вход с удалением кук и перегенерированием этого кусочека и т.д
     
  6. m1ko

    m1ko Создатель

    Регистр.:
    15 авг 2010
    Сообщения:
    42
    Симпатии:
    3
    проверка не по маске а по 1 ip если меняется что-то, то не пускать
    + хочу сделать мультисессии как в вк, если есть желание, можем попробовать вместе сделать одно дело.

    Хотя нет не по ip, но и не по маске.. как с телефонным интернетом дела обстоят, хаос начнется походу..
     
    Последнее редактирование: 6 май 2015
  7. artxaker

    artxaker Создатель

    Регистр.:
    25 авг 2009
    Сообщения:
    39
    Симпатии:
    36
    Хранить пароль в сессии или в куке??
    Вобшем, мой подход такой.
    таблица авторизации
    ид.,ид ползователя, токен, номер сессии(случайный уникалный сгенерированный номер), активен до, активен(труе,фолсе),агент(браузер), ип(айпи), тиместамп(последную дату активности)

    Если аунтификация выполнена.
    Генеруется "номер сессии случайный код" етот код хранится в таблице авторизации и в куке, так мы избегаем хранения ид или пароль пользователя в куке или в сесии, генерируем токен мд5(номер сессии + ид пользователя + агент(браузер) + ип(айпи) + соль) и храним его в базе, также храним браузер "активност до" дата по стандарту мускула, "актиен" на 1, и "тиместамп" чтоб узнать пользователь офлайн или онлайн.

    Проверка на куки.
    Если токен не совподает с имееюшим в базе( и или активен = 0,или активность до меньше чемтекушяя дата) то чтото изменилось может ип может браузер то не даем ему доступа
    и удаляем все куки у етого пользователя а в логе если установлен уведомляем пользователя о вторжении(если токен не совпал)
     
    m1ko нравится это.
  8. m1ko

    m1ko Создатель

    Регистр.:
    15 авг 2010
    Сообщения:
    42
    Симпатии:
    3
    Отлично, сам токен на стороне пользователя уже в куках храним?
     
  9. SaVage4Pro

    SaVage4Pro Писатель

    Регистр.:
    2 июн 2015
    Сообщения:
    2
    Симпатии:
    2
    очевидно, имеется в виду хранение в куке не токена, а id сессии, "номер сессии случайный код"

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

    удобоваримые варианты с токенами без фанатизма:
    1. генерить одноразовые токены при загрузке страницы и проверять при обработке post`а, чтобы быть немного более уверенным, что данные пришли именно с формы на сайте (в которую и добавляется временный токен), а не откуда попало, держать же их в БД, которая позволяет много писать и много читать
    2. генерить постоянные (условно) токены, которые записывать в саму сессию один раз при успешной авторизации, а в дальнейшем нам нужно будет проверить записанный в сессию токен с генерируемым проверочным кодом при каждом post-запросе (или даже при каждой загрузке страницы), который составляется так же, как и токен, на основе данных, переданных клиентом, включая браузер и ip-адрес. В случае, если что-то из этих данных поменялось, проверочный код не совпадет с токеном, записанным в сессию и клиенту надо делать перелогин, неважно кто это - настоящий ли пользователь, но зашел из другого браузера или его телефон перескочил на другую точку доступа, или же это злая собака, пытающаяся отправить форму со своей машинки, используя стыренные куки, можно до кучи такой токен сделать и временным, или писать в него какую-нибудь рандомную временную куку, которую обновлять при каждой успешной загрузке страницы

    фантазия ограничивается только возможностями сервера и его предполагаемой и реальной нагрузкой
     
    m1ko нравится это.