Правильный процесс входа - PullRequest
1 голос
/ 05 марта 2011

Раньше мне не приходилось заниматься процессом входа в систему, поэтому для меня это новая территория, и все, что я нахожу в Google, - это противоречивые методы обработки этого процесса, поэтому я надеялся, что кто-то может помочь прояснить ситуацию.

Пока у меня есть соленый хеш SHA1, созданный из смешивания имени пользователя, пароля и моей солевой переменной. Когда пользователь входит в систему, его учетные данные хэшируются, тогда этот хэш отправляется в sql и, если найден, возвращается с идентификатором пользователя (или чем-то еще). Итак, я знаю, что они аутентифицированы. С этим я могу обработать их сеанс с переменными сеанса.

Это верно до сих пор?

Во всяком случае, я хотел иметь возможность «запомнить меня» и хотел сохранить что-то в cookie, но не уверен, что поместить туда, поскольку, насколько я знаю, хранение хэша было бы довольно почти так же, как ввод их имени пользователя и пароля в виде простого текста

Я запутался, кто-нибудь может пролить свет?

Заранее спасибо

Ответы [ 5 ]

2 голосов
/ 05 марта 2011

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

Хэши общего назначения, такие как SHA1, не подходят для хеширования паролей, поскольку они оптимизированы для очень быстрой работы, когда требуется что-то очень медленное. Для обсуждения этого см. Как безопасно хранить пароль .

Во всяком случае, я хотел иметь возможность «запомнить меня» и хотел сохранить что-то в cookie, но не уверен, что поместить туда, поскольку, насколько я знаю, хранение хэша было бы довольно почти так же, как ввод их имени пользователя и пароля в виде простого текста.

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

1 голос
/ 05 марта 2011

Ваш первый процесс входа в систему правильный и соответствует современным стандартам безопасности, за исключением того, что вы можете выбрать другую функцию хеширования вместо 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).

Надеюсь, это поможет вам.

Вы можете масштабировать этот метод до любого уровня безопасности и настроить его под свои нужды.

1 голос
/ 05 марта 2011

Мне нравится тот факт, что вы использовали соль для хэширования, но я не думаю, что необходимо использовать имя пользователя для хэширования только пароль + соли должно быть достаточно. Специально это повлечет за собой перефразировку, если вы захотите вариант сменных имен пользователей для вашей системы.

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

http://it.toolbox.com/blogs/securitymonkey/howto-securing-a-website-with-client-ssl-certificates-11500

0 голосов
/ 06 марта 2011

Если ваша платформа (веб-сервер и т. Д.) Поддерживает Дайджест-аутентификацию HTTP , я настоятельно рекомендую вам использовать ее. Он был разработан людьми, которые знают о безопасности больше, чем кто-либо из нас. Он не отправляет пароли по сети. Он поддерживается всеми современными веб-браузерами, включая мобильные устройства. Если в браузере хранится пароль, это происходит прозрачно во время подключения, что дает вам возможность «запомнить меня», не прибегая к каким-либо файлам cookie.

Единственное, что он не делает, это позволяет вам использовать красивую форму - пользователь получит диалоговое окно для входа в браузер.

0 голосов
/ 05 марта 2011

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

Токен запоминания довольно прост. Допустим, вам нужна функция запомнить меня, которая действует в течение 14 дней.

На ваш сайт приходит незнакомец без аутентифицированного сеанса:

  1. Проверьте, есть ли токен Запомнить меня в куки
  2. Если да, проверьте, можете ли вы найти этот токен «Помни меня» в своей базе данных, и убедитесь, что столбец «Действителен до» все еще действителен (сравнение по дате)
  3. Если вы найдете действительный токен, вы можете установить идентификатор пользователя и аутентифицировать его сеанс
  4. Если вы не можете найти действительный токен, при необходимости перенаправьте пользователя на страницу входа в систему

Когда пользователь заполняет форму входа и успешно его аутентифицирует:

Создать токен, используя соответствующую функцию хеширования. Маркер, который вы хэшируете, может выглядеть как «[Timestamp] --- [userpwd]», так что он (почти) определенно уникален! Сохраните токен и дату, пока токен не станет действительным (например, +14 дней с этого момента), в вашей базе данных, связанной с идентификатором пользователя. Если есть токен с истекшим сроком, замените его, потому что вам не нужно хранить токены с истекшим сроком действия.

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

Вот и все!

...