Я внедряю простую систему входа в систему в веб-приложении, где не обрабатывается и не хранится критическая или личная информация, и я хочу обеспечить защиту от прослушивания для передачи данных входа в систему.
Я уже использую httpsмодуль apache, но иногда недоступен из-за ограничений доступа к порту и некоторых других проблем, поэтому,
Чтобы не усложнять работу и все же предлагать достаточно хорошую защиту в этих случаях, вот моя мысль о быстроми дешевый протокол, и мой большой вопрос по этому поводу заключается в том, если (и почему, если хотите), это хороший или большой нет-нет, чтобы сделать этот обходной путь:
В форме входа в систему клиент получает 2 текстовые строки произвольной длины (не слишком короткие и не слишком длинные) (которые сервер генерирует и сохраняет $ _SESSION var только для одной проверки) вместе с открытым ключом gpg сервера.
Перед отправкой на сервер пользователь + строка1 и пароль + строка2 javascript, закодированный в формате gpg с помощью открытого ключа сервера.
Сервер восстанавливает переданную информацию для входа в систему gpg, расшифровывает с помощью закрытого ключа и удаляет строки, хэширует проверку на наличие совпадений, сохраненных для этого пользователя, возвращая ошибку входа в систему / предоставляя доступ к приложению с профилем этого пользователя доконец сеанса.
Я понимаю, что это защищает только информацию для входа в систему (а не от любой атаки "человек посередине", подделывающей сервер, если бы мне это понадобилось, я бы просто принудилhttps), который в сочетании с некоторыми базовыми методами защиты от кражи сессионных сеансов должен препятствовать доступу пассивных перехватчиков к системе с украденными учетными данными, если я прав.
Должен ли я реализовать это или это пустая трата времени и ресурсов?