PHP Secure Session
Я создаю приложение, похожее на phpmyadmin (интерфейс управления базой данных). Пользователь должен аутентифицировать себя в базе данных, а приложение должно каким-то образом хранить учетные данные. SSL не вариант для всех установок.
- Идея 1: Пользователь отправляет учетные данные, приложение сохраняет имя пользователя и шифрует пароль с использованием предварительно определенного секретного ключа Blowfish (config.ini.php) - это то, что делает phpMyAdmin.
- Идея 2: Форма входа создает случайный секрет blowfish (javascript), пользователь отправляет учетные данные для входа, приложение шифрует пользователя / пароль и сохраняет их на стороне сервера в сеансе, секретный ключ сохраняется в cookie и отправляется для каждого запроса.
Идея 1: Проблема, если безопасность сервера нарушена. (Ключ находится в конфигурации, данные сеанса в /tmp)
Идея 2: Проблема с атакой "человек посередине". (Ключ + учетные данные отправлены)
Любые другие предложения? Критика?
2 ответа
Указанные вами проблемы не решаемы в абсолютном смысле. Ни один сервер не является на 100% безопасным, и каждая атака "человек посередине" может быть на шаг впереди.
Я предлагаю более конкретно определить требования к безопасности сервера. В противном случае каждое решение будет отсутствовать, потому что в абсолютном выражении они всегда есть. Например, используйте session_save_path() и поместите данные сеанса в другое место, если "/tmp" беспокоит вас.
Когда дело доходит до противодействия атакам "человек посередине", тогда убер-подход будет заключаться в использовании одноразовой клавиатуры, предварительно совместно используемой в автономном режиме. Это то, что делают агентства безопасности - все остальные варианты оставляют ваше приложение в большей или меньшей степени зависимым от благотворительности устройств между вашим сервером и пользовательским агентом. Так что вам нужно определиться с уровнем терпимости.
Одним из достаточно безопасных методов аутентификации является доказательство отсутствия знаний. Требуется, чтобы ваше приложение знало только открытый ключ пользователя. Нет паролей, нет секретов. Дело в том, что когда пользователь хочет войти в систему, ваше приложение должно ответить случайным сообщением, зашифрованным открытым ключом этого пользователя. Если другая сторона отправляет обратно правильное случайное сообщение, то это указывает на наличие соответствующего закрытого ключа. Следовательно, пользователь аутентифицирован. Чтобы предотвратить прослушивание, перед отправкой ответа заставьте пользователя useragent зашифровать правильный ответ с помощью открытого ключа приложения. Однако реализация необходимой функциональности и достойного графического интерфейса для всего этого не будет тривиальной задачей.
Для идеи 1 вы сказали, что даже обычный пользователь имеет доступ к файлу сеанса, это может быть и так, но вы всегда можете указать, где сеанс сохраняет данные и сделать доступным только для вашего домена пользователя / группы (если вы создаете новую учетную запись). за домен). Это гарантировало бы, что кому-то придется использовать уязвимость в вашем коде для получения доступа к этим данным. Таким образом, в конечном итоге все сводится к тому, насколько безопасно вы кодируете свой код (или код, который вы используете).