Безопасность при передаче пароля из формы.

  • Автор темы Автор темы WP
  • Дата начала Дата начала

WP

^_^
Безопасность при передаче пароля из формы.

Обычно, для обеспечения ввода пароля используют <input type="password">, и стандартные средства, в таком случае пароль, как известно, передается в открытом виде, при этом многие популярные броузеры сохраняют его на компьютере пользователя, и их просмотр не составляет труда с помощью спец. программ, или хуже того, троянских коней. Не говоря уже о spyware, и прослушивании трафика. Меня такой расклад явно не устроил и я стал думать как от этого защититься.
Для того чтобы броузер не считал парольное поле парольным, я сделал его текстовым, и сделал цвет символов идентичным фону, поэтому не видно что там написано.
Для передачи используется следующая схема: сначала клиент (броузер) запрашивает специальную строку (через AJAX), сервер генерирует её псевдо-случайным образом (32 символа a-z A-Z 0-9), а также ID этой строки (8 символов a-z A-Z 0-9), записывает эту связку в сессию, и отдает клиенту. А клиент, в свою очередь, передает на сервер MD5(строка+MD5(пароль)+MD5(строка)), и ID той случайной строки, а сервер проверяет и говорит всё ли верно, удаляя запись из сессии в любом случае.
Поделитесь опытом, кто как реализовывал такую защиту? Стоит ли пытаться реализовать ассиметричный алгоритм шифрования работающий разумное время?
 
1. https?
2. что мешает генерить какой то id в сессии и его же передавать в форму как соль к хешу?
 
...записывает эту связку в сессию, и отдает клиенту. А клиент, в свою очередь, передает на сервер MD5(строка+MD5(пароль)+MD5(строка)), и ID той случайной строки, а сервер проверяет и говорит всё ли верно, удаляя запись из сессии в любом случае.
ну и как это все работает в итоге? Единожды устанавливается сеанс? Так он и так устанавливается :-) Как при повторном визите на сайт происходит идентификация того, что я - это я?

чеснслова - от прочтения вышеизложенного не уловил
 
zerkms
1. Не везде есть.
2. Чтобы не возникало путаницы, какой хлеб какой солью посыпан =)
Gorynych
Не понял тебя. В случае удачной проверки пароля, в сессию записывается логин пасс, а потом сверяется каждый раз. При повторном визите на сайт используется кука со спец-кодом =)
 
Для того чтобы броузер не считал парольное поле парольным, я сделал его текстовым, и сделал цвет символов идентичным фону, поэтому не видно что там написано.
Сильно. А то, что юзер может таблицу стилей отключить, ты не подумал?
 
Тогда стоит подумать и о том, вдруг юзер выпьет йаду.
 
WP


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

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

-~{}~ 20.06.06 10:09:

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

тогда единовременной традиционной передачи пароля не будет (мы с этим боремся, да?), а при передачи данных формы для проверки использовать переданный логин и накопленный (на стороне сервера) пароль. Понятно, что надо будет уметь различать управляющие символы типа Backspace и т.п.
 
>Тогда стоит подумать и о том, вдруг юзер выпьет йаду.
Совершенно справедливо. И пошлёт тебе в открытом виде все куки, которые ты ему записал, как уже сказал Gorynych.
 
А если на замлю упадёт большой метеорит?!!! Вы этого не предусмотрели!!!
 
Gorynych
> ну и в чем изюминка этой системы?
Если перехватят, не смогут подставить те же данные и авторизироваться, т.к. соль будет другая, и взломать хеш будет проблематично.
это не изобретение велосипеда? Я просто пока реально не понимаю чего ради используется столько ухищрений? Или весь огород ради того, чтобы вводить его не в поле типа password, а в текстовое?
Это две разные вещи, нестандартный input и передача пароля. Первое служит для того чтобы у человека на компьютере не ловили (autocomplete="off" тоже стоит), а второе ^^.
если весь огород городится ради того, чтобы избежать традиционного способа передачи пароля, то почему бы не обрабатывать каждое нажатие в соответствующем поле и передавать его (тем же асинхронным методом) сразу на сервер (посимвольно, парами номер символа - символ) заменяя в поле ввода на звездочки? А на стороне сервера накапливать ввод в какой-то переменной сессии (по тупому - в массив, где индексы - номера символов)?
И что это даст? Элементарно всё перехватить можно, и головной боли больше юзеру и программеру чем взломщику.
> тогда единовременной традиционной передачи пароля не будет (мы с этим боремся, да?),
Кто "мы"? Лично я с единовременной передачей не борюсь, я против передачи в открытом виде.
svetasmirnova
> Совершенно справедливо. И пошлёт тебе в открытом виде все куки, которые ты ему записал, как уже сказал Gorynych.
Интересно, что это даст взломщику =)
 
Rammstein - сразу чувствуется, что Вы не первый день на этом форуме. Отличное знание традиций: главное в ответе не содержание, а форма. Особенно - язвительная, ага?

-~{}~ 20.06.06 10:34:

WP
головной боли пользователю не заметил, хотя придумывал навскидку. Сильной головной боли программисту - то же.

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

если ресь о борьбе с открытой передачей, почему не https-то? В предлагаемом решении я пока уловил только отказ от использования поля типа password (которое может сохраняться браузером) и много-много ухищрений.

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

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

в чем изюминка?
 
Я так понял-идея в том, что пасс нельзя напрямую отсниффить. Однако, любой сниф имеет логи, а в них мы легко находим как переданый серверу "запрос" на "случайная строка+ИД", так и посланый от клиента "MD5(строка+MD5(пароль)+MD5(строка))" далее врубаем перебор по МД5 (тут строка из лога + мд5("тут перебор")+мд5(тут тоже строка))

Пока вся трабла для взломщика в необходимости формирования двух МД5 при переборе. то есть в увеличении произв. мощностей.
 
идея с MD5 на клиенте сто раз на форуме обсуждалась.
и, насколько я понимаю - прекрасно работает. несмотря на замечания типа последнего, от _vampiro_
 
Фанат - да фиг с ним, с MD5.

я лично просто не могу понять всех остальных изощрений со строками и таким вводом: ради чего все это? Если брать в рассчет (мне показалось, что автор темы это учитывает) прослушивание трафика, то не важно, как ты обмениваешься данными с сервером - синхронно или а синхронно, трафик можно отследить.

про то, что хранить (MD5 или не MD5) на стороне клиента... Ну, блин, надеюсь идей записывать в куку пару логин:пароль пока никого не посещяло?
 
Gorynych
А я заметил.
не понимаю, в чем суть вашей борьба с открытой передачей, если есть ввод и передача пароля? Кстати, отключенные стили - это ладно, а вот отключенные хранимые куки - это более реально (в том числе - если я периодически пользуюсь для доступа к ресурсам какими-нибудь интернет-кафе).
> Кстати, отключенные стили - это ладно, а вот отключенные хранимые куки - это более реально (в том числе - если я периодически пользуюсь для доступа к ресурсам какими-нибудь интернет-кафе).
Ну и что? Я вообще не понимаю, причем тут куки?
_vampiro_
0_~
Gorynych
Я же всё описал, такое поле для того чтобы броузер не хранил пароли в кеше, и spyware обычно ловит формы в которых input type=password присутствует. Да, я учитываю перехват. Трафик отследить можно, но придется взламывать хеш.
 
Gorynych
ага :)

WP
Совет: по возможности используйте https, т.к. происходит шифрование всего трафика. Если уж совсем никак, то тогда только MD5... Ну, и ждать пока кто-нибудь тут изобретёт что-то новое - мягко говоря, бессмысленно :)
 
Если ты хочеш реальной безопасности , то https и когда юзер регистриться , то просить его ввести любое слово , а потом сделать ,чтобы при входе он вводил несколько букв из этого слова...

Например : введите 2,3,4 буквы из вашего кодового слова...

Это вариант хорошей безопасности , но не 100%...
 
Rammstein
Еще можно использовать другие алгоритмы =)
leeroy
Смиалсо. Что это даст?
 
Сверху