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

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

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

"изначально" - имеется в виду "при заведении пароля".
 
блин, фиксер, об этом, с пп - второй пост сверху.
про пароль давно уже закончили.
теперь о сессии разговор.
 
В общем. Подведем итог.

Решаемая проблема - защищенная авторизация: даже в случае перехвата пароля, он будет зашифрован. Что можно использовать для достижения задачи:

1. Digest-авторизация.
Преимущество: все делается на уровне .htaccess/.htpasswd, ничего кодить не надо.
Недостатки: не всеми броузерами поддерживается; из php-скриптов невозможно узнать пароль, если заранее не сохранить на сервере соответствия "пароль-хэш" или "пользователь-нешифрованный пароль".

2. Вычисление хэша MD5 на стороне клиента с помощью JavaScript.
Алгоритм описан здесь: http://prosto.pp.ru/Docum/DocumShow.asp?DocumID=335.
Преимущество: отсутствие недостатков метода 1. :) По сути, это не более, чем реализация Digest-авторизации на уровне PHP и JavaScript.
Недостаток: требуется поддержка JavaScript на стороне клиента.

Любые другие PHP/JavaScript-методы - модификации метода №2, суть не отличается - не более чем другая реализация.

В обоих случаях, никто не мешает использовать стандартные PHP-шные сессии. :)



2 Фанат: narod.ru у меня, увы, не грузится, потому посмотреть ту ссылку я не могу...
 
Сам вопрос такой, реально ли средствами javascript у клиента сделать шифрование пароля ?
Нажмите для раскрытия...
генерацию пароля осуществляет сервер, а клиент получает свой ключ, вторая часть ключа хранится на сервере.

Если клиент, есть "солидный клиент", то у него выделенный ip, и этот ипи можно замешивать в ключ при генерации...
я уже писал про это...

второе, если фирма солидная, то она не только может но и должна использовать SSL для передачи пароля (см. основное правило секурити) .
 
фиксер, ну не тупи, а?
народ тут совершенно не при чем.
человек словами написал ВСЕ ТО ЖЕ САМОЕ, что написано на пп.
Принцип описал. Принцип.
То есть искать ничего не надо было.
Этот принцип описан в форуме Избранное еще полгода назад.
И описан в этом треде, если внимательно его читать.
этот твой пп америку не открыл. а ты его преподносишь, как Решение.

Нету никаких "других методов". Я тебе и пытаюсь втолковать, что метод один и тот же, и он описан в этом топиеке задолго до твоего пп. описан и закрыт.

сессии тут вообще никаким боком - в них пароль не передается и их эта проблема (передачи пароля) не касается.
 
Автор оригинала: Фанат
Altex, поясни, пожалуйста, словами - чего именно не даст. зачиту трафика? Она и не обсуждается. Это делает ССЛ.
Защиту от входа под видом юзера - даст.
Нажмите для раскрытия...
У. Я не увидел, что речь про SSL.
 
Фанат

Ммм...
Да вобщем то все давно уже написано...
Нашел бы первым топик в избранном - дал бы ссылку туда.

Тогда я, честно говоря, уже запутался. Мы что обсуждаем-то? :)
 
rsv - защищенную передачу пароля.
реализацию rsa на яваскрипте.

я - основанную на этом авторизацию, более безопасную, чем та, которая применяется сейчас.
Эта тема меня занимает ,и я всегда рад на нее поговорить.
У меня есть несколько готовых рецептов в кармане от прошлых обсуждения - например контроль айпи (кому не нравится - устанавливайте ССЛ, и вперед. кто считает, что легко подделать - варианты в студию).

У меня есть завиральная идея объединения РНР сессия с НТТР авторизацией, при которой недостатки того и другого метода полностью удаляются.
если объединить с шифрованной передачей пароля, то получится малость тяжеловесный, но довольно надежный механизм.
 
:)
Мы обсуждаем то можно ли сделать так чтобы пользователь зарегистировался и пользовался затем ресурсом(логинился много раз после регистрации), а пароль НИ РАЗУ не прошел по сети в открытом виде или в таком виде что его можно расшифровать взглянув на скрипты на стороне клиента или сервера.
Еще раз поясняю что я хотел услышать. Есть два момента. Первый это логин. Когда клиент знает пароль и сервер знает пароль. Благодаря этому и алгоритму md5 им совершенно нет необходимости при авторизации пользователя передавать пароль по сети.
Второй момент это регистрация, когда клиент пароль знает а сервер нет. Суть вопроса в том чтобы при регистрации исключить передачу пароля серверу в явном виде. (операции типа xor не считаются :))
Идея с шифрованием клиентом своего пароля на основе открытого ключа присланного сервером позволяет исключить расшифровку пароля. Таким образом пароль НИ РАЗУ не пройдет по сети в явном (или возможным для расшифровки после взгляда на все иходники клиента и сервера) виде.
Конкретный вопрос. Можно ли реализовать средствами js шивровку пароля на использую открытый ключ, так же просто как и получение хэша MD5?

Еще один момент
Во втором посте было сказано что в принципе реализация шифрования возможна, но не известно сколько времени js будет это шифрование выполнять. Задавая вопрос я нечто подобное предполагал, поэтому и вспомнил про md5. Может быть шифрование не настолько долгое что бы клиент не согласился ОДИН раз при регистрации подождать какое то время (количество времени это тоже вопрос) и потом много раз (при авторизации) использовать быстрый MD5.
 
rsv, я все же не понимаю, что мешает использовать именно тот же md5.js и при регистрации.
Нажмите для раскрытия...
Объясни мне как используя md5 можно передать пароль серверу первый раз?
 
мд5 - односторонний.
сравнить хэши сервер может.
но достать из него пароль, чтобы в базу положить - нет
 
хотя, а почему бы при регистрации не сгенерировать и не выслать пароль по почте?
потом поменяет
 
Altex :-))))))))
Вот что значит - отвечать не подумав :-)

1. почта так же снифыфится. Хотя это уже паранойя, но все же.
2. "потом поменяет" - сам сообразишь? ;-)
 
хотя, а почему бы при регистрации не сгенерировать и не выслать пароль по почте?
Нажмите для раскрытия...
Это как раз принципиальный вопрос. Пароль ни разу не должен появиться в явном виде в сети.И в тоже время должна быть гарантия что сервер его будет знать а при перехвате его не смогут расшифровать.
Если это реализуемо то перед заказчиком ты как разработчик чист. Все что можно со своей стороны ты сделал. Если он начнет вспоминать про сниферов, то это уже проблемы администраторов сети но ни как не твои.
 
Гм.
rsv, если стоит вопрос чистоты перед заказчиком, то вариант единственный - ССЛ.
Сто долларов в таком вопросе, как правильно заметил Александре - не деньги.
 
просто здесь тогда вопрос не технологии, а целесообразности.
Нет смысла изваращаться изгаляться, просить о чем-то юзера, висеть на яваскрипте и так далее.
Гораздо проще и правильнее, если стоит вопрос ответственности перед заказчиком - НАДЕЖНЕЕ (чем самопал на коленке) - ССЛ.

Тут и размышлять не о чем.
 
Заводить первоначально можно вообще по ssh. :)
Дешево и сердито.
 
Войдите или зарегистрируйтесь для ответа.
Сверху