Ваш первый процесс входа в систему правильный и соответствует современным стандартам безопасности, за исключением того, что вы можете выбрать другую функцию хеширования вместо sha1.
Sha1 очень быстр, и поэтому атаки грубой силой для взлома хеша происходят быстрее. Таким образом, если ваши хеши (база данных) и токен (исходный код) утекли, пароли могут быть взломаны.
Одна из мер противодействия - использовать более медленную функцию хеширования (см. Ответ Джимса на статью об этом)
Но, конечно же, лучше всего не пропускать хэши в первый раз.
Возможность для функции запомнить меня состоит в том, чтобы позволить пользователю хранить cookie сессии дольше. Например, Magento и Zend Auth делают это.
Это, однако, очень уродливо, потому что вы, вероятно, получите сотни тысяч сеансов, хранящихся на ваших серверах, даже для пользователей, которые никогда не возвращаются.
Гораздо более элегантный способ хранить эту информацию на стороне клиента.
Sidenote: Конечно, вы не должны помещать слишком много файлов cookie на клиента, поскольку они передаются при каждом запросе страницы. Но cookie для входа в систему - это очень веский случай. Хорошей практикой является сохранение файла cookie для входа в систему на стороне клиента и заполнение сеанса сервера данными, сохраненными в базе данных, при входе в систему, который отмечен в сеансе. Таким образом, вы устраняете непрерывные запросы к базе данных и имеете хороший реестр пользовательских данных. Конечно, запись должна выполняться в базу данных и сеанс напрямую или лучше в базу данных, а затем каким-либо образом сбрасываться в приложение (полностью или постепенно).
Помещение хеша в файл cookie клиента не похоже на "обычный текст". Однако на многих уровнях это ужасно, ужасно и небезопасно.
Есть несколько разных подходов, но в основном они снова включают хеширование.
Самым распространенным и простым является что-то вроде размещения cookie с user_id=john
и user_token=HASH($userid.$appsecret)
на клиенте. Или хранить их как один в одном cookie.
Это довольно безопасно, но я предпочитаю следующий метод:
Создать строку, которая содержит:
userid ; user agent ; first two ip segments ; current timestamp ; your application secret token
Запустите его через хорошую функцию хеширования и сохраните cookie на клиентском компьютере пользователя, который выглядит как
auth=userid;timestamp;hash-of-the-above
Когда клиент входит в систему с помощью cookie, вы заново создаете строку сверху, но берете отметку времени и идентификатор пользователя из cookie. Создайте хэш и посмотрите, соответствует ли он. Затем вы проверили, что это файл cookie, сгенерированный для этого сегмента IP-адреса, и этот пользовательский агент в указанное время
Sidenote: первые два сегмента ip редко меняются с динамическими isp. Вы также можете их оставить, это для дополнительной безопасности.
В чем главное преимущество этого метода?
Клиент или вы можете сделать недействительными все файлы cookie для входа в систему, установив метку времени. Только кулинария, которая была сгенерирована впоследствии, принимается. Вы также можете реализовать тайм-аут.
Это хорошо, если вы хотите «удаленный выход из системы» с общедоступного компьютера, на котором вы забыли выйти из системы или что-то в этом роде.
Я думаю, что функциональность очень важна, и с этим методом вам не нужно отслеживать файлы cookie для единого входа (как это делает Google).
Надеюсь, это поможет вам.
Вы можете масштабировать этот метод до любого уровня безопасности и настроить его под свои нужды.