Как защитить пароль при передаче формы на сервер?

Не используя https, при передачи GET или POST запроса, пароль передается в открытом виде. Шифровать с помощью javascript на стороне клиента с открытым колючем? Есть варианты?
  • Вопрос задан
  • 24592 просмотра
Решения вопроса 1
@plasticmirror
передаем на сервер логин
сервер генерит соль и отдает клиенту
клиент солит пароль, считает хэш (sha1 например) и передает хэш
сервак со своей стороны так же солит пароль, считает хэш и смотрит совпадает или нет.

ну и ограничения на сессию.
в итоге перехват трафика дает только доступ к сессии и не раскрывает пароль.
Ответ написан
Пригласить эксперта
Ответы на вопрос 7
FanatPHP
@FanatPHP
Чебуратор тега РНР
Три ответа и куча лайков.
Что характерно, если тех же самых людей спросить, надо ли хэшировать пароли на сервере - все дружно, строем и хором ответят - НУЖНО!

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

Это квинтессенция подобныйх сайтов. Ответ почему-то всегда даётся самый буквальный. При этом вопрос никогда не подвергается сомнению или хотя бы минимальной проверке на осмысленность. Такое ощущение, что отвечающие воспринимают вопрос как экзамен что ли? Или как челендж - ответить любой ценой, пусть даже и неимоверных извращений и ГАРАНТИРОВАННЫХ граблей в будущем. Или - как сейчас - ценой СНИЖЕНИЯ защищенности! Но зато ответ буквальный. И так не только здесь - так практически в любом ответе. Ну никогда ни у кого не твремени задуматься над вопросом - все торопятся отвечать.

Я не знаю, что с этим делать. Такой подход очень вредит как самому сайту, так и тем, кто задает вопросы. Вместо того, чтобы показать правильный подход, ему старательно, сопя и напрягая остатки извилин, помогают выстрелить себе в ногу.

Возможно, одна из причин в том, что в голове у отвечателей отсутствуют реальные знания, а стоит органчик, в который записано несколько прочитанных когда-то ответов. И один из этих ответов выстреливается сразу после прочтения заголовка - даже не углубляясь в текст вопроса. Таких "отвечателей" надо гнать поганой метлой. Пусть самоутверждаются в другом месте. Тем же, кто хочет ответить, рекомендую придерживаться правила:

Перед тем как отвечать, НАДО СНАЧАЛА ПОДУМАТЬ. Посчитать на ход вперед - "а что будет, если сделать, как я советую?" Посчитать на ход назад - "а зачем ему нужно это? Не похож ли этот вопрос на мой собственный, который я когда-то задавал от недостатка знаний?" И попробовать ответить так, чтобы РЕАЛЬНО помочь спрашивающему, а не просто выдать зазубренный ответ.

Возвращаясь к вопросу: нет, нельзя без SSL. Хэширование на сервере важнее.
Можно эмулировать SSL для передачи пароля, но куда проще воспользоваться готовым механизмом. На дворе 2014 год, все основные сайты перешли на шифрование всего трафика вообще. Пора переставать бояться SSL.
Ответ написан
Если вы хотите добиться той же надежности что и при передаче по https, то да - вариант один - реализация асимметрично шифрованного канала на уровне ajax. Не знаю есть ли библы такие.
Если же речь идет не о регистрации (допустим первая передача пароля у вас всегда защищена) то варианты есть.
Например сервер генерит рандомную строку и передает ее пользователю. Пользовтель вычисляет хэш от своего пароля и используя этот хэш как ключ шифрует эту рандомную строку блюфишем например (реализация на js есть точно) и передает вам обратно. Вы со своей сторны используя хэш хранимый на сервере, так же шифруете эту рандомную строку блюфишем. Сравниваете.
Злоумышленнику придется атаковать ключ блюфиша по рандомному исходному тексту и шифротексту. Задача не из простых.
Ответ написан
@sergey_privacy
Админ со стажем, начинающий DevOps
Самый надежный вариант очевиден:
1. При нажатии на кнопку сабмита отсылаем аякс-запрос к серверу
2. Он возвращает открытый ключ
3. флэш или ява шифруют пароль открытым ключом на стороне браузера, отсылают серверу
4. Сервер расшифровывает, хеширует и заносит в базу. Или не расшифровывает, а хеширует и хранит в базе пару: хешированный зашифрованный пароль и закрытый ключ.
Ответ написан
mannaro
@mannaro Куратор тега JavaScript
Умею профессионально гуглить
Ну попробуйте посылать не пароль, а его хеш.
Дальше на сервере работаете с хешем как с паролем и все ;)
Ответ написан
Вы можете использовать как ключ текущее время в миллисекундах. И посылать все на сервер в формате hash1:hash2, где hash2 - зашифрованный timestamp. На сервере расшифровываете timestamp и расшифровываете пароль.

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

Также есть md5 для JS - будете просто сохранять готовый хэш в базу.
Ответ написан
Комментировать
@arab789 Автор вопроса
Сделал перед отправкой пароля хеш md5(т.к. в БД хранятся хеши), затем шифрую хеш с помощью OpenSSL и уже зашифрованный пароль передаю ajax-ом на сервер, там расшифровываю и сравниваю хеши. Подход правильный?
Ответ написан
KOLANICH
@KOLANICH
Знаю JS, PHP, C++, C#
1 Сервер хранит открытый ключ клиента в открытом виде, клиент хранит закрытый ключ клиента, сгенерированный на клиенте специально для этого.
2 Сервер выдаёт криптографически безлпасное случайное число, клиент его подписывает.
3 Сервер проверяет подпись.
Использовать DSA.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы