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

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 той случайной строки, а сервер проверяет и говорит всё ли верно, удаляя запись из сессии в любом случае.
Поделитесь опытом, кто как реализовывал такую защиту? Стоит ли пытаться реализовать ассиметричный алгоритм шифрования работающий разумное время?
 

zerkms

TDD infected
Команда форума
1. https?
2. что мешает генерить какой то id в сессии и его же передавать в форму как соль к хешу?
 

Gorynych

Посетитель PHP-Клуба
...записывает эту связку в сессию, и отдает клиенту. А клиент, в свою очередь, передает на сервер MD5(строка+MD5(пароль)+MD5(строка)), и ID той случайной строки, а сервер проверяет и говорит всё ли верно, удаляя запись из сессии в любом случае.
ну и как это все работает в итоге? Единожды устанавливается сеанс? Так он и так устанавливается :) Как при повторном визите на сайт происходит идентификация того, что я - это я?

чеснслова - от прочтения вышеизложенного не уловил
 

WP

^_^
zerkms
1. Не везде есть.
2. Чтобы не возникало путаницы, какой хлеб какой солью посыпан =)
Gorynych
Не понял тебя. В случае удачной проверки пароля, в сессию записывается логин пасс, а потом сверяется каждый раз. При повторном визите на сайт используется кука со спец-кодом =)
 

svetasmirnova

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

WP

^_^
Тогда стоит подумать и о том, вдруг юзер выпьет йаду.
 

Gorynych

Посетитель PHP-Клуба
WP


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

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

-~{}~ 20.06.06 10:09:

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

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

svetasmirnova

маленький монстрик
>Тогда стоит подумать и о том, вдруг юзер выпьет йаду.
Совершенно справедливо. И пошлёт тебе в открытом виде все куки, которые ты ему записал, как уже сказал Gorynych.
 

Rammstein

PHPClub::News
А если на замлю упадёт большой метеорит?!!! Вы этого не предусмотрели!!!
 

WP

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

Gorynych

Посетитель PHP-Клуба
Rammstein - сразу чувствуется, что Вы не первый день на этом форуме. Отличное знание традиций: главное в ответе не содержание, а форма. Особенно - язвительная, ага?

-~{}~ 20.06.06 10:34:

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

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

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

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

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

в чем изюминка?
 

_vampiro_

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

Пока вся трабла для взломщика в необходимости формирования двух МД5 при переборе. то есть в увеличении произв. мощностей.
 

Фанат

oncle terrible
Команда форума
идея с MD5 на клиенте сто раз на форуме обсуждалась.
и, насколько я понимаю - прекрасно работает. несмотря на замечания типа последнего, от _vampiro_
 

Gorynych

Посетитель PHP-Клуба
Фанат - да фиг с ним, с MD5.

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

про то, что хранить (MD5 или не MD5) на стороне клиента... Ну, блин, надеюсь идей записывать в куку пару логин:пароль пока никого не посещяло?
 

WP

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

Rammstein

PHPClub::News
Gorynych
ага :)

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

leeroy

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

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

Это вариант хорошей безопасности , но не 100%...
 

WP

^_^
Rammstein
Еще можно использовать другие алгоритмы =)
leeroy
Смиалсо. Что это даст?
 
Сверху