Собственно, интересно 

На каком-то форуме видел пример кода, когда пароль от юзера передаются средствами JavaScript в уже зашифрованном (md5) виде. То есть отправка пароля идет не в открытом виде, а уже зашифрованном. На сколько разумен данный подход? Какие подводные ямы? Как сделать, чтобы если у юзера отключен JS, отсылалось обычными средствами браузера.

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

Начну со своего представления хорошей "системы пользователей":

1. После окончания первого этапа регистрации в БД добавляется запись, пароль в sha1, поле `active` = 0
2. Высылается письмо на указанный e-mail с ссылкой подтверждения регистрации. Параметр uid или подобный (по которому различают записи) генерируется из времени регистрации и, допустим, e-mail или имени юзера, $uid = sha1($time  . $name). То есть запросы выглядит примерно так: http://host.zone/index.php?do=registration...ff54455ecfb40e7 .
3. После подтверждения регистрации поле `active` = 1, соответственно когда поле `acitve` было 0, нельзя было войти в систему или были какие-либо ограничения.
4. При авторизации - пароль передаются с помощью JS в уже зашифрованном виде. На сервере сравниваются имя пользователя и хеш. Соответственно, присутствует жестокая фильтрация входящих данных.
5. Если имя пользователя и пароль совпали - начинаем сессию. В настройках PHP - поддержка COOKIE и отсутствие ограничения на использования GET для передачи параметра (чтобы работало у тех, у кого COOKIE отключены). Устанавливаем COOKIE (Имя пользователя и хеш пароля). Если юзер закрыл браузер и зашел заного, проверяем имя пользователя и пароль из COOKIE. Если все ок - создаем новую сессию. Сессия должна быть привязана к IP (по хорошему в настроках аккаунта должна задаваться строгость привязки - к статическому IP или к подсети, ибо бывает очень неудобна жестокая привязка, когда у юзера динамический IP).
6. Юзер вышел - удалили сессия, очистили куки с именем пользователя, паролем и ID сессии.

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

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

Возникает вопрос, может ли злоумышленник перехватить пароль в момент его передачи от клиента серверу? Да, если имеет доступ к одному из компьютеров, которые "ретранслируют" запрос.

В случае, если пароль хешируется на стороне клиента, злоумышленник перехватывает хеш. 

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

Более разумной считаю следующую схему.

На стороне клиента хеш считается не просто от самого пароля, а по следующей формуле:

 

В данном примере считаем, что функция MD5 уже описана.

Значение переменной rand_code формируется сервером случайным образом и для каждой загрузки страницы является различным.
Само значение rand_code передается обрабатывающему скрипту через сессию.

В чем смысл? Смысл в том, что хеш одного и того же пароля, передаваемый серверу будет каждый раз разным за счет случайной составляющей rand_code. Соответственно, перехват передаваемого хеша не позволит с его помощью авторизоваться второй раз.

Почему не сделать просто MD5(rand_code + password)? Потому что в этом случае пришлось бы хранить пароли в базе незашифрованными, что нежелательно.

Вот, по-моему такой подход предпочтительней, т.к. при этом не только скрывается собственно пароль пользователя, но и отсутствует возможность повторной авторизации.

Но все наши идеи рушатся, если у пользователя отключен ява-скрипт. В принципе, можно обойти это очень просто.
Добавить в событие формы onsubmit функцию, выполняющую вычисление хэша по нашей формуле и очищающую значение поля password. Соответственно, если ява-скрипт сработает - мы получим зашифрованный пароль, если нет - получим пароль в открытом виде.

Пример:




Это сообщение отредактировал(а) ewolf - 4.10.2007, 10:27

CyClon, 

куки могут своровать и тогда без разницы, что там хранится - хэш или открытый пароль: этот хэш потом можно подставить себе в куки и представиться Вами =)

ewolf, интересная идея.

а в какой момент она записывается в сессию? Я правильно понял, эта переменная в javascript'e (var rand_code = 29038;) сформирована сервером, а js уже принял ее? Потому что, если это js'овская переменная (сгенерированная Math.random'ом - не важно чем, в общем), то ее надо передать серверу - а вот здесь-то ее и перехватят. А дальше отправят на проверку вместе с хэшем. Ну т.е. - переменная rand была сформирована сервером и сразу же положена в сессию. А на форме логина в js уже выведено значение этой переменной из сессии (aka var rand = '<?php print $_SESSION["rand"]; ?>';, потому что иначе пропадает смысл, если она в js сформирована).

Это сообщение отредактировал(а) dsCode - 4.10.2007, 17:22

Да, не подумал  А другие варианты какие?

Хотя, если даже кто-то утянет куки, в моем случае идет привязка в подсети (или ИП). Пользу сможет получить только сосед Вася, у которого та же подсеть. Но, все-таки, поделитесь идеями 

ЗЫ: Долго не думал над подводными камнями, но как вам такая идея:

1. При регистрации пишется в базу пароль "sha1(sha1($password))"
2. При авторизации первое кодирование выполняется на стороне клиента, второе соотвественно на стороне сервера. И никаких rand_code 

Гениально? :P Или опять туплю? 

Добавлено через 8 минут и 58 секунд
На счет универсальности - думаю так. Если JS у юзера есть, то написанный код будет перехватывать нажатие кнопки, серверу будует отправляться такой пароль:

На сервере проверяется пароль на наличие надписи jsencoded, если она есть - убираем ее и $password = sha1($password);
Если же jsencoded нет, значит у юзера JS был отключен и он пришел в открытом виде, соответственно $password = sha1(sha1($password));

Вроде все просто, главное добиться того, чтобы при отключенном JS данные отправлялись обычным образом, а с включенным - с кодированием.

Это сообщение отредактировал(а) CyClon - 4.10.2007, 18:29

Да нет... Это тоже самое, как если просто хешировать его на стороне клиента, т.к. злоумышленник сможет его просто выслать серверу, не заботясь что уже потом сам сервер с ним будет делать.


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

Вот только все эти ухищрения абсолютно бесполезны пока сам SID передается открытым, т.к. вместо пароля можно просто подослать этот SID. Даже если сессия привязана к IP - это все равно не даст никаких гарантий...

Добавлено через 1 минуту и 47 секунд
Имхо, без двухстороннего шифрования тут никак не обойтись.

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

Но, если злоумышленник снифит траффик, то получается, он по-любому сможет зайти на наш сайт от имени юзера (если нет привязки к ИП).

Да, именно так. Даже если есть привязка, то все равно многие используют прокси сервер и у многих нету выделенного IP... Единственное можно было бы придумать как защитить SID если бы было можно хранить какой-либо ключ на стороне клиента (к примеру, если бы можно было записать куку которая была бы доступна только JS, но не отправлялась бы на сервер). А так единственный вариант - это SSL.

Мы недавно с сотрудниками поднимали аналогичную тему. Затрагивались как вопросы прослушивания траффика с промежуточного роутера, так и с хаба или wi-fi сетей.
Пришли к выводу, что нет ничего надежнее SSL, VPN. Все остальное - так или иначе обходится.
Вариант шифрования пароля в браузере всего лишь усложняет задачу для злоумышленника. Так или иначе, если он смог получить доступ к этому паролю (перехватить траффик пользователя) это значит, что он имеет доступ к любой конфиденциальной информации жертвы.

Кстати, вариант с генерацией рендомного числа в качестве "приправы" для пароля - это число злоумышленник перехватит с таким же успехом, как и пароль пользователя ;)

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

chin, 

я об этом и упомянул, - это в том случае, если число передается запросом. А если оно было сгенерированно (и положено сразу в сессию) до того, как js получил его (var rand = '<?php print $_SESSION["rand"]; ?>';)? Далее rand используется только для генерации "приправы", но само оно (rand) не передается, а возьмется, опять же, из сессии, куда и было положено в начале.

Это сообщение отредактировал(а) dsCode - 8.10.2007, 13:15

Если JS получит код, значит и злоумышленник его тоже получит.
В Вашем случае, хакер получит подстроку в ответе сервера:

chin, т.е. снифится весь траффик включая гет-запросы на получение страницы (не отправка формы)?

dsCode,
А почему бы и нет?