Comments 36
Даже мыслей небыло что можно не щифровать
Вопрос не совсем четкий. Вы собираетесь шифровать их перед отправкой формы?
Да, с чего это такой странный вопрос?
Пароль шифровать всегда и обязательно! Если можно не шифровать пароль, значит аутентификацию вообще нет смысла проводить.
Пароль шифровать всегда и обязательно! Если можно не шифровать пароль, значит аутентификацию вообще нет смысла проводить.
может сразу отправлять пользователя на https и все время работать с ним через этот протокол?
Так и делаем. Аунтефикация принудительно через https :) Благо SSL сертификаты простые стоят копейки
Есть вообще бесплатные, пожалста: www.startssl.com/?app=1
Вероятно вы удивитесть но на всем нам любимом ресурсе этого не делают )))
HttpAnalyzer палит логин, пароль и каптчу — они не зашифрован.
И я согласен с тем что тогда не понятно зачем нужен пароль, мало того ещё и каптча…
HttpAnalyzer палит логин, пароль и каптчу — они не зашифрован.
И я согласен с тем что тогда не понятно зачем нужен пароль, мало того ещё и каптча…
капча нужна чтобы обезопасится от роботов, какая разница видит ли ее HttpAnalyzer.
А вообще по шифрованию логина и пароля — не вижу смысла. Есть https. Что еще? Помню со знакомым спорил по поводу предварительного md5 пароля для отправки на сервак. Только потом до него дошло, что в итоге перехватчик будет использовать md5 для авторизации.
А вообще по шифрованию логина и пароля — не вижу смысла. Есть https. Что еще? Помню со знакомым спорил по поводу предварительного md5 пароля для отправки на сервак. Только потом до него дошло, что в итоге перехватчик будет использовать md5 для авторизации.
Возможно имеет смысл шифровать не только логин и пароль, если проводить операции с электронной валютой. В сильверлайт приложениях можно использовать хоть AES, вместо мд5. Если передавать зашифрованное сообщение с временной меткой внутри перехват зашифрованных данных не поможет.
Каптча от роботов поможет конешно, но с таким отношением к безопасности… к чему борьба с роботами?
При генерации хеша пароля его можно «посолить» одноразовым токеном с сервера + ІР адресом клиента.
Таким образом перехватчик не сможет воспользоваться хешем.
Таким образом перехватчик не сможет воспользоваться хешем.
Когда у «жертвы» будут спуфить трафик и токен с сервера и IP жертвы будут известны
Токен с сервара одноразовый и привязанный к ІР клиента. После того, как легальный пользователь залогинился — он больше не действительный.
В точку.
Единственное, проблемно будет с flash/silverlight приложениями. Даже если токены и перехватятся, то как ими солить — будет трудно сказать. На каком там уровне декомпилеры — я не знаю.
Еще как вариант защиты — AMF у флэша. но насколько он защищен — я тоже не знаю.
Поэтому вопрос сумбурный очень. Не хватает конкретики или пункта «зависит от платформы».
Единственное, проблемно будет с flash/silverlight приложениями. Даже если токены и перехватятся, то как ими солить — будет трудно сказать. На каком там уровне декомпилеры — я не знаю.
Еще как вариант защиты — AMF у флэша. но насколько он защищен — я тоже не знаю.
Поэтому вопрос сумбурный очень. Не хватает конкретики или пункта «зависит от платформы».
>Шифровать же пароль совершенно бессмысленно.
зная соль+алгоритм хеширования, слабым звеном будет скорее всего сам пароль, который злоумышленик будет подбирать простым брутфорсом по словарикам.
зная соль+алгоритм хеширования, слабым звеном будет скорее всего сам пароль, который злоумышленик будет подбирать простым брутфорсом по словарикам.
1. запрос паблик кейя
2. генерация симметричного ключа
3. передача симметричного ключа, зашифрованого пабликом
4. шифруем логин/пароль симметричным и передаём на сервер
Это так же не спасёт от man in the middle, но как показывает практика, сертификаты с этим тоже не справляются.
2. генерация симметричного ключа
3. передача симметричного ключа, зашифрованого пабликом
4. шифруем логин/пароль симметричным и передаём на сервер
Это так же не спасёт от man in the middle, но как показывает практика, сертификаты с этим тоже не справляются.
Радости от соления — ноль, если в большинстве случаев сам пароль похож на «123мойпароль» и злоумышленик, зная алгоритм, соленья и хеш, будет брутфорсом подбирать различные варианты при которых у него будет получаться нужный хеш, который он перехватил по сети вместе с солью. Ах да, вы меня удивляете :)
Видимо вы меня не понимаете :) Цель — узнать реальный пароль. Предположим что пароль простой и у нас есть алгоритм sha-2, соль и результат(всё это пролетело по сети в открытом виде), мы берём словарик типичных паролей и начинаем применять к нему sha-2+соль и сравнивать с результатом(при коллизии мы скорее всего получим нужный нам пароль). Большинство паролей какого-нибудь фэйсбука, еслиб там использовалась такая схема, вскрывались бы с невероятно быстрой скоростью :)
Нужно ли мыть яблоки перед едой?
Да, за исключением того что они уже помыты (ssl)
Да, за исключением того что они уже помыты (ssl)
А смысл? Если злойумышленник перехватил хэш и успел в момент запроса залогиниться или сбросить пароль, то что?
Абсолютно малопонятно, как шифрование пароля спасёт нас.
Вот HTTPS *возможно* спасёт, но если злойумышленник имеет доступ на комп жертвы, то что тогда?
Абсолютно малопонятно, как шифрование пароля спасёт нас.
Вот HTTPS *возможно* спасёт, но если злойумышленник имеет доступ на комп жертвы, то что тогда?
>но если злойумышленник имеет доступ на комп жертвы, то что тогда?
безопасность всегда была процессом уменьшающим риски, а не магическим инструментом который спасёт нас от всего.
безопасность всегда была процессом уменьшающим риски, а не магическим инструментом который спасёт нас от всего.
Мысль в том, что степень безопасности любой системы определяется степенью безопасности самого уязвимого звена.
Поэтому, если у нас есть более уязвимое звено, то смысла ноль целых ноль десятых шифровать что-то где-то в другом месте.
Поэтому, если у нас есть более уязвимое звено, то смысла ноль целых ноль десятых шифровать что-то где-то в другом месте.
Sign up to leave a comment.
Нужно ли при логине на сайт шифровать передаваеммые логин и пароль?