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