Соленый хеш будет передан через URL для постоянного входа без файлов cookie

Question

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

У меня уже есть скрытый ввод для работы с формами, но мне также нужны ссылки для добавления строки запроса к их URI.определить сессию.Но если хеш основан только на пароле + соли, то существует угроза безопасности: вошедший в систему пользователь может щелкнуть по внешней ссылке, а владелец внешнего сайта может увидеть URI с хешем в своих журналах реферера.Все, что им нужно будет сделать, это использовать этот хеш, и они будут зарегистрированы.

Поэтому я хочу посолить хэш с учетом времени, ограничив сеанс 10 минутами.Я не могу понять, как это сделать.Конечно, я могу использовать time (), чтобы засолить его, но как проверить, сколько лет сессии основано только на хэше?

Answer 1

Истечение срока сеансов через 10 минут не защищает ваших пользователей от атак перехватов сеансов. Успешно раздражает ваших пользователей, заставляя логин каждые 10 минут. Ваша предложенная схема по-прежнему имеет все виды уязвимостей. Ваши соленые хешированные пароли все еще могут проникать во внешний мир по многим другим каналам; перехват пакетов, промежуточные прокси, отправка пользователями по электронной почте ссылок на страницы или даже сохраненный HTML, и это лишь некоторые из них. Я советую вам не строить свои собственные рамки безопасности, не будучи экспертом в этой области. Даже тогда это решаемая проблема. Просто зайдите с известным надежным решением. Есть много тонкостей в веб-безопасности, которые легко испортить.

Answer 2

Это звучит как очень плохая идея.И сложный тоже.Я определенно не рекомендовал бы это.Вы, вероятно, можете использовать что-то вроде этого:

if (session_id() == "") session_start();

Выше будет в основном проверять, был ли сеанс запущен или нет, и в противном случае начать сеанс.

Поскольку вы планируете распространять среди пользователей,Мне кажется, что весь подход немного отстранен.Я не уверен, чего вы хотите достичь, но вы можете попробовать использовать JS, который вместо этого вызывает ваш PHP-файл для каждой страницы.Это облегчит вам.Если бы вы могли уточнить, какое приложение вы разрабатываете, то, возможно, я мог бы помочь вам лучше.У меня большой опыт в приложениях для массового потребителя, аналогичных тем, что вы делаете.

Answer 3

Это не обязательно плохая идея, но она опасна, если не все сделано правильно.Фактически, это довольно распространенная реализация многодоменного единого входа с использованием кодов аутентификации сообщений на основе хеша .Некоторые основные правила:

1. Никогда не включайте пароль как часть хэша (даже в виде соли)
2. Требуется генерация метки времени как часть хэша, который должен передаваться ВСЕГДА схэш.
3. Каждый сайт, использующий этот хэш, должен иметь свой собственный 32- или 64-байтовый guid для использования в качестве уникальной соли.
4. Передавать конкретные данные в строку запроса, такие как имя пользователя, отметка времени, что-нибудь еще, и HMAC.Таким образом, это выглядело бы примерно так:возможно) получить ключ для генерации сравниваемого HMAC.
5. Использовать алгоритм твердого хеширования (предпочтительно SHA1) для генерации HMAC.Генерируйте ключи закрытого сайта как можно более случайным образом.Не используйте стандартный метод деривации, просто убедитесь, что конечный результат достаточно велик / уникален.