Меню
Что нового?

можно ли использовать RSA для шифровки пароля

rsv

rsv

Новичок
можно ли использовать RSA для шифровки пароля

Только сразу камнями не забрасывайте. Про SSL я тоже слышал. Возникла такая идея. Для того чтобы во время регистрации пользователя не передавать его пароль в открытом виде, пхп скрипт генерит (берет готовый) открытый ключ шлет его в с регистрационной формой. У клиента яваскриптом при нажатии сабмита шифруется функциеей типа
reg_form.client_pasw.value=rsa_encript(reg_form.client_pasw.value,reg_form.server_public_key.value)
потом форма отправляется с зашифрованым паролем.
Скрипт на сервере расшифровывает пароль используя private_key ну или как он там называется.
Это только при регистрации, потом при логинах пароль можно вообще не передавать а использовать MD5.
Сам вопрос такой, реально ли средствами javascript у клиента сделать шифрование пароля или может уже кто делал? На сервере понятно можно использовать готовые бинарники.
 
valyala

valyala

Новичок
Сам вопрос такой, реально ли средствами javascript у клиента сделать шифрование пароля или может уже кто делал?
Нажмите для раскрытия...
Реально. Ведь зашифрование в RSA - это всего лишь операция x^e mod n, где пара чисел (n,e) - открытый ключ, x - данные, которые надо зашифровать. Правда, обычно числа эти огромны, яваскрипт - тормозной, поэтому операция зашифрования может "немного" затянуться :)
Не знаю, есть ли готовый код на яваскприте. Я немного интересуюсь криптографией и теорией чисел, поэтому собираюсь написать свой код ради спортивного интереса. Кстати, можешь взглянуть на мою реализацию алгоритма RC5-64 в яваскрипте ( http://valyala.narod.ru/huinya/rc5.html ).

Предложенный тобой способ передачи зашифрованного пароля по открытым каналам связи имеет право на существование. Он позволяет скрыть пароль от пассивных снифферов. Но при использовании несимметричной криптографии всегда возникает проблема "человек посередине". Допустим, между сервером и клиентом установлена программа-сниффер, которая может не только перехватывать сообщения, но и подменять их. Клиент посылает запрос на выдачу открытого ключа, сервер высылает ключ. Но сниффер подменяет его на собственный открытый ключ. Клиент, ничего не подозревая, зашифровывает пароль и отправлет его на сервер. Сниффер перехватывает его, расшифровывает, получает пароль клиента, зашифровывает его с помощью настоящего ключа и отправляет на сервер, который уверен, что пароль пришел напрямую от клиента. Все три участника протокола получили то, что хотели :) .
Чтобы избежать этой бреши в безопасности, клиент должен быть уверен, что открытый ключ действительно принадлежит серверу. Для этого используют публичный центр хранения открытых ключей сервера, подписанных открытым ключом этого центра (обычно такой центр называют сертификационным). В этом случае мы вынуждены доверять этому центру и действительности его открытого ключа.
Так что истинным паранойикам лучше использовать симметричную криптографию :)

Поставленную тобой задачу легче всего решать с помощью SSL. В этом случае не придется изобретать велосипед. Но, если ты - истинный извращенец вроде меня, то реализуй свою идею. Она мне понравилась. Могу даже помочь за небольшое вознаграждение :)

Ты правильно заметил, что при логинах надо использовать хэш-функции вроде MD5. НО! Сниффер перехватывает значение хэш-функции md5(password). Он не знает пароль. Но это не мешает ему выдавать себя за настоящего пользователя. Решить эту проблему можно так: при обращении клиента к страничке логина сервер генерит случайное число rnd_num, отправляет его клиенту, который отправляет серверу значение md5(password + rnd_num). Серверу известны password и rnd_num для данного клиента. Он проверяет корректность присланного хэша. В этом случае сниффер может выдавать себя за настоящего пользователя только в течение сессии. Можно обойти и эту проблему. Например, при каждом запросе генерить новый rnd_num. Но тут возникают новые проблемы, которые обычно ОЧЕНЬ мешают юзерам. Поэтому приходится искать компромисс между юзабилити и безопасностью.
 
Фанат

Фанат

oncle terrible
Команда форума
valyala, спасибо за интересную заметку.
от себя добавлю, что во-первых, можно использовать HTTP digest авторизацию и возложить работу по шифрованию на браузер.
во-вторых, реализация MD5 на яваскрипте не раз приводилась на этом форуме.
в-третьих, если так уж стоит вопрос конфидециальности, что нужна защита от снифера, то SSL особых проблем юзеру не создает ;-)
в-четвертых, если после защищенной авторизации.
передавать только идентификатор сессии, и контролировать ее по IP то это будет довольно хорошей защитой - как ты думаешь?

кстати, об извращениях. в поиске по слову "мутант" можно найти весьма яркий образчик. Который к шифрованию особого отношения не имеет, но весьма перспективен с точки зрения протокола НТТР.
 
rsv

rsv

Новичок
valyala, заметка действительно интересная :)
вообще говоря вопрос возник после того как я увидел реализацию md5 на js. Сразу же попробовал с этим делом сделать логин без передачи пароля получилось без проблем. Вот и подумал что если вдруг есть подобная реализация RSA шифрования которая делается так же легко, то можно было бы вообще исключить передачу пароля по сети в открытом виде. (Это заказчику надо :) для успокоения души) Хотя если начать вспоминать про сниферов то наверно лучше вообще не заморачиваться с самодеятельностью и действительно пользоваться ssl. Хотя тут на форуме была ветка в которой вроде как огласили алгоритм при котором передаются только хэши и сниферы могут перехватывать сколько хотят но им это не поможет, правда я так и не понял до конца в чем там суть, поскольку по моему мнению там всеравно есть возможность выдать себя за пользователя, имея возможность перехвата трафика :)
 
Фанат

Фанат

oncle terrible
Команда форума
эту возможность тебе только что описал еще раз valyala
тебе стоит внимательно перечитать его слова
Решить эту проблему можно так: при обращении клиента к страничке логина сервер генерит случайное число rnd_num, отправляет его клиенту, который отправляет серверу значение md5(password + rnd_num). Серверу известны password и rnd_num для данного клиента.
Нажмите для раскрытия...
 
fixxxer

fixxxer

К.О.
Партнер клуба
Все это очень напоминает HTTP Digest
так может не изобретать велосипед?
 
Фанат

Фанат

oncle terrible
Команда форума
fixxxer, есть одно но.
Насколько я ничего не понимаю, пых нам поддерживает только васик, но не дайджест. А в этом случае сильно сужается применимость.
или я туплю, а от пыха ничего не требуется?
 
rsv

rsv

Новичок
эту возможность тебе только что описал еще раз valyala
Нажмите для раскрытия...
Это и ежу понятно что так надо использовать md5, именно это я и сделал когда увидел его js версию.
Я говорю о том что если снифер может перехватывать трафик (в обеих направлениях) то он может придуриться клиентом и тогда как написал valyala про rsa все трое получили то что хотели
 

Alexandre

PHPПенсионер
а ты контролируй сессию по ip
Нажмите для раскрытия...
а думаешь поможет?
перехватили переданный пароль, знаем ip, который подделать можно - входим на сервер под клиентом...
а как же сотни диал-апщиков? у которых ip меняются?
 

Altex

Новичок
Автор оригинала: Фанат
а ты контролируй сессию по ip
Нажмите для раскрытия...
]
Насколько я понимаю, если сниффер работает приведенным valyala выше способом, то это ничего не даст.
 
fixxxer

fixxxer

К.О.
Партнер клуба
С digest ручками надо хедеры распарсить, по идее...
Щас поищу инфу, я с этим тоже на уровне "читал пару раз" знаком. :)

Да, кстати, а md5 разве не есть основанная на RSA хэш-функция, или я чего-то не понимаю?
 

Alexandre

PHPПенсионер
можно ли использовать RSA для шифровки пароля
Нажмите для раскрытия...
только зачем это делать на стороне клиента?
RSA представляет ассиметричный алгоритм который имеет два ключа: публичный и приватный.
После авторизации клиент получает публичный ключ, а приватный остается на сервере.
в состав алготитма генерации ключа, можно включить и тот же ip,
и каждый раз при приходе публичного ключа можно его проверять на валидноть ip
 

Alexandre

PHPПенсионер
и еще одно важное правило секьрити:
для передачи ключей необходимо использовать только надежные *(доверительные) каналы т.е. SSL

Если есть SSL - то это тот же RSA, может не будем велосипед изобретать, а просто работать па SSL?
поддержка SSL стоит около 100 уе в год - это не деньги для компании, которая собирается что-то секретное передавать.
 
Фанат

Фанат

oncle terrible
Команда форума
rsv, бедные диалап юзеры не коннектятся каждые 5 минут. И если обеспечение секретности того стоит, то его не заломает ввести пароль снова. Ферштеен?

Alexandre Ты пишешь в тему, которая посвящена неперехватываемой передаче пароля о том, что его перехватят! Я тебя умоляю - если ты не в состоянии понять, о чем идет речь - ну не пиши тогда!

И что сотни диалапщиков? У них айпи меняется 10 раз за сессию?

Altex, поясни, пожалуйста, словами - чего именно не даст. зачиту трафика? Она и не обсуждается. Это делает ССЛ.
Защиту от входа под видом юзера - даст.
 
Фанат

Фанат

oncle terrible
Команда форума
Alexandre, где ты здесь прочел про компанию, которая что-то секретное?
Ну где? Ну почему, почему на форумах люди отвечают на что угодно, но любые свои фантазии - но только не на сам поставленный вопрос?

Защита пароля от перехвата нужна не только таки компаниям.
А, в теории - любой парольной защите.
И если ее можно сделать надежнее - это надо сделать.
Не только компании.
Здесь и обсуждается этот вопрос. А не твои фантазии.
 
Войдите или зарегистрируйтесь для ответа.
Сверху