Короче говоря, вы думаете об этом:
На стороне сервера у вас есть:
- база данных, с совпадениями логин / пароль.
- скрипт, который принимает 2 параметра (пароль и имя пользователя) и проверяет в базе данных, существует ли пара
Ваша проблема:
Когда ваше локальное приложение вызывает скрипт php на стороне сервера, 2 параметра задаются в виде простого текста. И вы хотите избежать взлома (если ваш сценарий безопасен от инъекций, я вижу только взлом, используемый для подбора аутентификации <= имейте в виду, что я сохраню это предположение во всем посте) </p>
Ваше решение:
- На стороне клиента зашифруйте 2 параметра
- На стороне сервера добавьте соль в ваш скрипт для соли
- Затем расшифруйте 2 параметра и зашифруйте солью
Что я думаю:
Это не решит проблему взлома, кто-то может подделать запросы.
Первое шифрование бесполезно, потому что кто-то может получить ключ, используемый вашим клиентом.
Второе шифрование небезопасно, потому что вы используете одну и ту же соль для всех своих пользователей.
Что я предлагаю:
Примите, что подделку нельзя избежать, если вы не используете безопасный протокол, такой как HTTPS (можете использовать SSL или TLS).
Если вы хотите приемлемую безопасность без HTTPS, я бы реализовал следующее:
- Система токенов, которую вы проверите, чтобы узнать, может ли пользователь выполнить операцию входа в систему
- Имя пользователя, которое не будет зашифровано
- Пароль хэша sha1 хранится в базе данных
- На стороне клиента вы вызываете сценарий и указываете, что имя пользователя не зашифровано, а пароль - как хэш sha1, перефразированный случайной солью (sha1 (sha1 (pass) + salt) (соль сохраняется в сеансе пользователя). на стороне сервера)
- Затем сценарий сравнил бы предоставленный хэш с хэшем пароля базы данных, перефразированный с солью сеанса
Улучшение заключается в том, что злоумышленник должен попытаться перебрать два пароля sha1 последовательно и предоставить действительный токен для выполнения действия входа в систему. Плюс, если вы будете использовать в качестве соли строку, используя шестнадцатеричный символ переменной даже четной длины, злоумышленнику будет сложнее распознать, что значение, получаемое вторым хешем, является хешем sha1, и даже если он знает, что это sha1, он придется протестировать несколько регистров, чтобы попытаться найти правильную часть значения, соответствующего хешу.
Из-за переменной соли один и тот же пароль не будет тем же, если хэшировать:
Представьте, что злоумышленник прослушал хеш и узнал, какой пароль использовался, а затем прослушал другой хеш, созданный с тем же паролем, что и другой, злоумышленник не сможет узнать, что пароль 2 совпадает (немного перебор, но все еще полезен ).
Безопаснее хранить пароль в виде хешированного значения, потому что если злоумышленнику удастся сбросить вашу пользовательскую таблицу, он не сможет сразу использовать пароли, ему придется каждый раз подрабатывать.
Наконец, sha1-хэш безопаснее, чем md5 (я говорю вам об этом, потому что вы использовали тег md5 в своем сообщении)
Недостатком этого метода является то, что пароли не могут быть изменены, поэтому вы не сможете вернуть их своим пользователям, если они их потеряли. Вам нужно будет заставить их установить новый.
Хардкорным способом (все еще без использования HTTPS) будет шифрование вашего пароля и имени пользователя с помощью сильного шифра (например, AES или 3DES) и использование алгоритма безопасного обмена ключами (например, Diffie Hellman one). ) для обмена случайным общим ключом.
Этот метод не блокирует фальсификацию, но затаскивает злоумышленника, потому что он не сможет расшифровать значение (при условии, что он только анализирует сеть). Ключ является случайным и никогда не кодируется жестко в любом приложении, поэтому даже если кто-то обратит ваш клиент, он не сможет получить ключ.
Я бы все равно рекомендовал хранить хэш вашего значения пароля.
Экстремальным способом было бы объединить 2 метода, но это было бы полностью излишним.
Надеюсь, что это даст вам идеи