Аутентификация без имени пользователя / пароля?

Question

Мы создаем мультитенантное приложение PHP.Учетная запись каждой компании будет работать на своем собственном поддомене abcorp.example.com.Приложение позволяет компаниям писать и публиковать контент (часто задаваемые вопросы и т. Д.) Для своих клиентов.

Они скажут своим клиентам посетить: abcorp.example.com/, чтобы прочитать их содержимое.Или же они вставят ссылку на этот URL в свое защищенное веб-приложение.

Однако эти компании могут не захотеть, чтобы кто-то читал контент, перейдя по адресу abcorp.example.com/

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

Моя цель:

1. Если пользователи вводят abcorp.example.com / непосредственно в браузере, они не смогут видеть веб-страницу, потому что они не аутентифицировались и не передавали токен.

2. Избегайте использования имени пользователя и паролей

Другим вариантом будет ссылка URL-аутентификация

Answer 1

Ваша идея "скрытого токена" очень важна для работы сессий . Сеанс может использоваться для идентификации пользователя (т. Е. Отслеживать, что пользователь делает, когда он просматривает сайт), и распространяется , либо передавая идентификатор сеанса вместе в ссылках, либо сохраняя его в печенье.

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

Пожалуйста, прочитайте раздел руководства PHP по сеансам и безопасности .

Answer 2

Конечно, если кто-то сделает токен общедоступным, он откроет доступ тому, кто его найдет.

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

abccorp.example.com /? T = 4rrfwr23rwads3

Каждый токен может храниться в файле или базе данных.

Когда кто-то запрашивает страницу, он проверяет значение $ _GET ['t'] с тем, что хранится на сервере.Если это соответствует, это загружает остальную часть страницы.Конечно, эту переменную нужно будет переносить по всему сайту и включать в каждую ссылку.

Опять же, это не будет очень безопасно.Открытый токен может дать доступ к сайту всему миру.

Answer 3

Сертификация на стороне клиента. Проверить http://en.wikipedia.org/wiki/Mutual_authentication.

Answer 4

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

ссылка может выглядеть примерно так:

abc.example.com /? Д = b5939ca22f5dcf345b4000641995478c5910dbd1607b1bdadcbf4a8618a95211

где дайджест:

$d = hash('sha256', $secret_password.$subdomain);

или включая реферера:

$d = hash('sha256', ($secret_password.$subdomain.$_SERVER['HTTP_REFERER']));

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

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

Answer 5

Вы также можете использовать IP-адрес клиента в качестве токена, предоставляя разные IP-адреса для доступа к различным (частям / экземплярам) системы. Но, к сожалению, это не очень безопасно, поскольку (1) у вас нет возможности узнать, кто стоит за клиентским ПК, и (2) IP-адреса могут быть подделаны. Возможно, вы могли бы разработать дополнительные характеристики; предоставление доступа к IP-адресам только в рабочее время или проверьте браузер клиента (пользовательский агент) и проверьте его на соответствие пользовательскому агенту, официально используемому на клиенте.