Простой безопасный вход php/javascript

Question

Я хочу создать безопасный вход в систему, поэтому я хочу зашифровать пароль, прежде чем отправлять его как параметр POST. Я делаю это с помощью функции SHA1 javascript.

Тогда я понимаю, что если кто-то перехватывает зашифрованный пароль, он может использовать его сразу. Отправка его в качестве параметра для сообщения того же URL.

Как я могу быть уверен, что пароль поступает из поля ввода логина? Может быть, с PHP-сессией? Я еще не хочу использовать безопасный http. У кого-то есть простая альтернатива?

Answer 1

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

Вы не можете.

Ближайшая вещь для этого - обычная защита от CSRF ... но это только помешает людям обмануть пользователей в отправке данных со своего сайта на ваш сайт. Он не будет защищать пароли.

Я еще не хочу использовать защищенный http. У кого-то есть простая альтернатива?

HTTPS является простой вариант.

Answer 2

Отправка пароля SHA1 по сети на ваш сервер эффективно делает SHA1 хэш реальным паролем.

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

HTTPS - единственный реальный способ защитить пароль от отправки в текстовом виде. И пока вы переходите к HTTPS, убедитесь, что вы изменили эти хэши SHA1 на bcrypt.

Если вы беспокоитесь о дополнительных затратах на сертификацию SSL, вы также можете создать самозаверяющий сертификат, если вас не беспокоят ошибки браузера или готовы добавить сертификат в доверенный список (http://resources.arcgis.com/en/help/main/10.1/index.html#//0154000005q6000000).

Answer 3

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

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

объяснение:

Client -> Request -> Сервер

Сервер -> Ответ (отправка уникальное соленое о использоваться с JavaScript как session_id()) -> клиент

Client -> JavaScript Execution -> Шифрование пароля с помощью уникальной соляной

Client -> POST -> сервер

Ser ver -> дешифрование пароля с сохраненной солью -> извлечение пароля

Надеюсь, кто-то исправит меня, если идея выше неверна!

Примечание: AES может быть использован как для JS и PHP

Солт = Key

Доступные инструменты:

AES Advanced Encryption Standard

jsaes: AES in JavaScript

PHP AES DEC/ENC

phpAES

Answer 4

Просьба предоставить миру и всем вашим клиентам одолжение и ПРОДОЛЖИТЬ шифровать пароль перед отправкой его по незашифрованному HTTP.

Есть две стороны этой проблемы, и в этом случае обе стороны - это вы сами и клиент, которым вы обслуживаете. К сожалению, большинство пользователей используют одни и те же пароли для многих сайтов, так как у нас нет емкости памяти для обработки сотен сайтов, с которыми мы входим в систему сотнями паролей, мы, как конечные пользователи, выбираем два или три и продолжаем свою жизнь. Вы, безусловно, ошибаетесь, если вы отправляете свои пароли клиентов через HTTP, не зашифровывая их сначала, и есть на самом деле что-то, что нужно получить. Доверяйте своим клиентам, чтобы их пароли, вероятно, такие же, как то, с чем они входили в банк, не попадали в руки хаков или, что еще важнее, руки любого, кто связан с разработкой веб-сайта, потому что вредные ИТ-сотрудники действительно существуют и очень легко получить эти пароли, поскольку они отправлены в ваше приложение для обработки на стороне сервера ...

Мне было бы неловко думать, сколько веб-разработчиков прочитали эту статью и решили не шифровать на стороне клиента, что должно быть одной из первых вещей, которые мы делаем, это защита для пользователей, а не для себя ... Защита вашей базы данных может осуществляться с помощью множества процедур, и каждый аналитик безопасности имеет свое мнение о том, что делать или не делать, соленый-spunked-болталась-нибудь. шифрование на стороне клиента не должно обсуждаться.