Нужно ли при логине на сайт шифровать передаваеммые логин и пароль?

[LoveSan]

Даже мыслей небыло что можно не щифровать

[homm]

При логине? Вы серьезно? И как вы шифруете, для каждого сайта с форумом покупаете SSL-сертификат? Или все шифруете на клиенте с помощью JS? А как защищаетесь от перехвата шифра?

[GarretUA]

Вопрос не совсем четкий. Вы собираетесь шифровать их перед отправкой формы?

[notacodemonkey]

При передаче на сервак и формы тут не причём, это может быть сильверлайт/флэкс приложение где для этого используются другие механизмы.

[silentroach]

Видимо, имеется в виду https

[seiros]

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

[niro]

может сразу отправлять пользователя на https и все время работать с ним через этот протокол?

[Psih]

Так и делаем. Аунтефикация принудительно через https :) Благо SSL сертификаты простые стоят копейки

[Evengard]

Есть вообще бесплатные, пожалста: www.startssl.com/?app=1

[zhovner]

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

[notacodemonkey]

Вероятно вы удивитесть но на всем нам любимом ресурсе этого не делают )))
HttpAnalyzer палит логин, пароль и каптчу — они не зашифрован.
И я согласен с тем что тогда не понятно зачем нужен пароль, мало того ещё и каптча…

[kastigar]

капча нужна чтобы обезопасится от роботов, какая разница видит ли ее HttpAnalyzer.

А вообще по шифрованию логина и пароля — не вижу смысла. Есть https. Что еще? Помню со знакомым спорил по поводу предварительного md5 пароля для отправки на сервак. Только потом до него дошло, что в итоге перехватчик будет использовать md5 для авторизации.

[notacodemonkey]

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

[kastigar]

В сильверлайт/флэше — да. Как я написал ниже, не хватает пункта «зависит от платформы», т.к. на js не вижу особого смысла писать шифровщики.

[notacodemonkey]

Каптча от роботов поможет конешно, но с таким отношением к безопасности… к чему борьба с роботами?

[mrgall]

При генерации хеша пароля его можно «посолить» одноразовым токеном с сервера + ІР адресом клиента.
Таким образом перехватчик не сможет воспользоваться хешем.

[evge]

Когда у «жертвы» будут спуфить трафик и токен с сервера и IP жертвы будут известны

[mrgall]

Токен с сервара одноразовый и привязанный к ІР клиента. После того, как легальный пользователь залогинился — он больше не действительный.

[kastigar]

В точку.
Единственное, проблемно будет с flash/silverlight приложениями. Даже если токены и перехватятся, то как ими солить — будет трудно сказать. На каком там уровне декомпилеры — я не знаю.
Еще как вариант защиты — AMF у флэша. но насколько он защищен — я тоже не знаю.

Поэтому вопрос сумбурный очень. Не хватает конкретики или пункта «зависит от платформы».

[nuit]

>Шифровать же пароль совершенно бессмысленно.
зная соль+алгоритм хеширования, слабым звеном будет скорее всего сам пароль, который злоумышленик будет подбирать простым брутфорсом по словарикам.

[nuit]

1. запрос паблик кейя
2. генерация симметричного ключа
3. передача симметричного ключа, зашифрованого пабликом
4. шифруем логин/пароль симметричным и передаём на сервер

Это так же не спасёт от man in the middle, но как показывает практика, сертификаты с этим тоже не справляются.

[nuit]

Радости от соления — ноль, если в большинстве случаев сам пароль похож на «123мойпароль» и злоумышленик, зная алгоритм, соленья и хеш, будет брутфорсом подбирать различные варианты при которых у него будет получаться нужный хеш, который он перехватил по сети вместе с солью. Ах да, вы меня удивляете :)

[nuit]

Видимо вы меня не понимаете :) Цель — узнать реальный пароль. Предположим что пароль простой и у нас есть алгоритм sha-2, соль и результат(всё это пролетело по сети в открытом виде), мы берём словарик типичных паролей и начинаем применять к нему sha-2+соль и сравнивать с результатом(при коллизии мы скорее всего получим нужный нам пароль). Большинство паролей какого-нибудь фэйсбука, еслиб там использовалась такая схема, вскрывались бы с невероятно быстрой скоростью :)

[Andrey_Rogovsky]

Нужно ли мыть яблоки перед едой?

Да, за исключением того что они уже помыты (ssl)

[garex]

А смысл? Если злойумышленник перехватил хэш и успел в момент запроса залогиниться или сбросить пароль, то что?

Абсолютно малопонятно, как шифрование пароля спасёт нас.

Вот HTTPS *возможно* спасёт, но если злойумышленник имеет доступ на комп жертвы, то что тогда?

[nuit]

>но если злойумышленник имеет доступ на комп жертвы, то что тогда?
безопасность всегда была процессом уменьшающим риски, а не магическим инструментом который спасёт нас от всего.

[garex]

Мысль в том, что степень безопасности любой системы определяется степенью безопасности самого уязвимого звена.

Поэтому, если у нас есть более уязвимое звено, то смысла ноль целых ноль десятых шифровать что-то где-то в другом месте.

[nuit]

>Поэтому, если у нас есть более уязвимое звено, то смысла ноль целых ноль десятых шифровать что-то где-то в другом месте.
Вы предлагаете ничего не делать? Расставим слабых звеньев побольше, чтобы негодяй мог выбирать из них.

[garex]

Неее… Это тоже лузер-вариант.

Я предлагаю определить сначала, где надо удар наносить, а потом его наносить.

А так вопрос поставлен типа: «Бить иль не бить?» Общо и малоконкретно.