Насколько безопасна эта модель аутентификации?

Question

У меня есть учетная запись пользователя 'center center', в которой отображаются все подписки и членства клиентов, которые они имеют в моей компании. Это на https://secure.example1.com/membercenter/.

У меня есть другой сайт, который является действительным участником. Это на http://www.example2.com/. (каждый сайт в другом домене, хотя это один и тот же выделенный сервер.

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

Итак, что я придумал, это:

Когда пользователь щелкает ссылку «Логин» для своего членства, я создаю хэш md5 его метки времени userid + unix и добавляю его в таблицу базы данных вместе со своим идентификатором пользователя и меткой времени.

Затем я перенаправляю на http://www.example2.com/login?hash=(the хэш).

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

При запуске этого хэш-сценария входа в систему сначала удаляются все строки старше 5 минут, а затем проверяется пройденное хеш-значение. Если он находит хеш, он регистрирует пользователя, а затем удаляет хеш, который использовался из таблицы. Это означает, что в таблице никогда не будет хэшей старше 5 минут. Единственный раз, когда (должны) быть какие-либо хэши в таблице остаются, это если пользователь каким-то образом не переходит с secure.example1.com на www.example2.com после нажатия на ссылку (скажем, интернет отключается справа). во-вторых, решение проблем DNS, example2.com и т. д.). 5-минутный срок действия означает, что они могут сидеть там и перезагружать перенаправленный URL-адрес до тех пор, пока они не войдут, или пока не пройдет 5 минут.

Когда пользователь перенаправляется, он видит значение хеш-функции.

Каждый раз, когда нажимается ссылка для входа с сайта secure.example2.com, вычисляется и сохраняется новое значение хеш-функции.

Мой вопрос ... я что-то упускаю из виду? Как бы вы сломали или взломали это? Я только что создал зияющую дыру в безопасности на своих сайтах?

Спасибо, ТАК Hive Mind!

РЕДАКТИРОВАТЬ: это в дополнение к обычной модели захода на www.example2.com и входа в систему с помощью имени пользователя / пароля.

EDIT2: Ответ tobyhede re: прослушивание хеша. Злоумышленник также должен помешать пользователю получить доступ к сценарию входа в систему на сайте www.example2.com, поскольку хэш удаляется после использования. Если бы они смогли это остановить, им бы пришлось использовать хеш в течение пяти минут, иначе он будет автоматически удален.

EDIT3: Re: Злоумышленник генерирует свои собственные хэши: хакер должен будет вставить эти хэши в базу данных и включить действительный идентификатор пользователя (ни один из пользователей не знает их идентификатор пользователя). Как они это сделают? Поскольку хэш используется только один раз, а затем немедленно удаляется, я не уверен, что любая из нижеприведенных атак будет работать.

Answer 1

Все, что нужно сделать, это перехватить URL-адрес с помощью хэша, и он получит доступ к вашей системе. Вы действительно должны передать хеш через SSL, используя HTTP POST.

Answer 2

Хотя вы не можете сделать такую ​​схему полностью водонепроницаемой, есть ряд вещей, которые могли бы ее улучшить:

• Используйте случайное начальное число вместо метки времени unix при генерации ключа
• Убедитесь, что реферер в запросе на вторую страницу является первой страницей
• Убедитесь, что источник двух запросов один и тот же

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

Answer 3

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

Вы должны придумать решение, которое содержит что-то, что не так легко угадать злоумышленнику. По сути, вы хотите иметь в своем хеше секрет, который злоумышленнику почти невозможно угадать. Вот почему использование соли (случайных битов) в вашем хэше - путь.

Полагаю, вам известны атаки на хэши MD5 и SHA-1 ? В MD5 на самом деле существует вероятность коллизий хешей (http://merlot.usc.edu/csac-s06/papers/Wang05a.pdf), поскольку SHA-1 предположительно все еще безопасен, но есть также атаки радужных таблиц против обоих хэшей.

Создание хэша с солью, идентификатором пользователя и звуковой меткой времени возможно для вашего решения. Я также предлагаю вам удалить хэш после использования.

Answer 4

Если злоумышленник знает, что пользователь собирается войти в систему, злоумышленник может сгенерировать хэш (или серию хэшей с немного отличающимися временными метками) и войти в систему, прежде чем пользователь сделает это. Немного лучшим решением является замена хеша случайно сгенерированным токеном. Затем злоумышленнику придется перехватить запрос пользователя на вход в систему на сайте example2.

Пока вы используете HTTP вместо HTTPS на сайте example2, ни одна схема не будет безопасной. Например, например, вы нашли идеальную схему входа для сайта example2, которая является безопасной. Однако после входа в систему запросы от пользователя будут отправлять информацию о сеансе либо в URL, либо в заголовках запросов (например, куки). Эти запросы могут быть перехвачены, и злоумышленник может украсть информацию о сеансе. В худшем случае для злоумышленника вы будете связывать сеансы с их исходным IP-адресом, а злоумышленнику потребуется подделать исходный IP-адрес.