-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
можно ли использовать RSA для шифровки пароля
- Автор темы rsv
- Дата начала
В общем. Подведем итог.
Решаемая проблема - защищенная авторизация: даже в случае перехвата пароля, он будет зашифрован. Что можно использовать для достижения задачи:
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 у меня, увы, не грузится, потому посмотреть ту ссылку я не могу...
Решаемая проблема - защищенная авторизация: даже в случае перехвата пароля, он будет зашифрован. Что можно использовать для достижения задачи:
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 у меня, увы, не грузится, потому посмотреть ту ссылку я не могу...
Alexandre
PHPПенсионер
генерацию пароля осуществляет сервер, а клиент получает свой ключ, вторая часть ключа хранится на сервере.
Если клиент, есть "солидный клиент", то у него выделенный ip, и этот ипи можно замешивать в ключ при генерации...
я уже писал про это...
второе, если фирма солидная, то она не только может но и должна использовать SSL для передачи пароля (см. основное правило секурити) .
фиксер, ну не тупи, а?
народ тут совершенно не при чем.
человек словами написал ВСЕ ТО ЖЕ САМОЕ, что написано на пп.
Принцип описал. Принцип.
То есть искать ничего не надо было.
Этот принцип описан в форуме Избранное еще полгода назад.
И описан в этом треде, если внимательно его читать.
этот твой пп америку не открыл. а ты его преподносишь, как Решение.
Нету никаких "других методов". Я тебе и пытаюсь втолковать, что метод один и тот же, и он описан в этом топиеке задолго до твоего пп. описан и закрыт.
сессии тут вообще никаким боком - в них пароль не передается и их эта проблема (передачи пароля) не касается.
народ тут совершенно не при чем.
человек словами написал ВСЕ ТО ЖЕ САМОЕ, что написано на пп.
Принцип описал. Принцип.
То есть искать ничего не надо было.
Этот принцип описан в форуме Избранное еще полгода назад.
И описан в этом треде, если внимательно его читать.
этот твой пп америку не открыл. а ты его преподносишь, как Решение.
Нету никаких "других методов". Я тебе и пытаюсь втолковать, что метод один и тот же, и он описан в этом топиеке задолго до твоего пп. описан и закрыт.
сессии тут вообще никаким боком - в них пароль не передается и их эта проблема (передачи пароля) не касается.
rsv - защищенную передачу пароля.
реализацию rsa на яваскрипте.
я - основанную на этом авторизацию, более безопасную, чем та, которая применяется сейчас.
Эта тема меня занимает ,и я всегда рад на нее поговорить.
У меня есть несколько готовых рецептов в кармане от прошлых обсуждения - например контроль айпи (кому не нравится - устанавливайте ССЛ, и вперед. кто считает, что легко подделать - варианты в студию).
У меня есть завиральная идея объединения РНР сессия с НТТР авторизацией, при которой недостатки того и другого метода полностью удаляются.
если объединить с шифрованной передачей пароля, то получится малость тяжеловесный, но довольно надежный механизм.
реализацию rsa на яваскрипте.
я - основанную на этом авторизацию, более безопасную, чем та, которая применяется сейчас.
Эта тема меня занимает ,и я всегда рад на нее поговорить.
У меня есть несколько готовых рецептов в кармане от прошлых обсуждения - например контроль айпи (кому не нравится - устанавливайте ССЛ, и вперед. кто считает, что легко подделать - варианты в студию).
У меня есть завиральная идея объединения РНР сессия с НТТР авторизацией, при которой недостатки того и другого метода полностью удаляются.
если объединить с шифрованной передачей пароля, то получится малость тяжеловесный, но довольно надежный механизм.
rsv
Новичок
Мы обсуждаем то можно ли сделать так чтобы пользователь зарегистировался и пользовался затем ресурсом(логинился много раз после регистрации), а пароль НИ РАЗУ не прошел по сети в открытом виде или в таком виде что его можно расшифровать взглянув на скрипты на стороне клиента или сервера.
Еще раз поясняю что я хотел услышать. Есть два момента. Первый это логин. Когда клиент знает пароль и сервер знает пароль. Благодаря этому и алгоритму md5 им совершенно нет необходимости при авторизации пользователя передавать пароль по сети.
Второй момент это регистрация, когда клиент пароль знает а сервер нет. Суть вопроса в том чтобы при регистрации исключить передачу пароля серверу в явном виде. (операции типа xor не считаются
)Идея с шифрованием клиентом своего пароля на основе открытого ключа присланного сервером позволяет исключить расшифровку пароля. Таким образом пароль НИ РАЗУ не пройдет по сети в явном (или возможным для расшифровки после взгляда на все иходники клиента и сервера) виде.
Конкретный вопрос. Можно ли реализовать средствами js шивровку пароля на использую открытый ключ, так же просто как и получение хэша MD5?
Еще один момент
Во втором посте было сказано что в принципе реализация шифрования возможна, но не известно сколько времени js будет это шифрование выполнять. Задавая вопрос я нечто подобное предполагал, поэтому и вспомнил про md5. Может быть шифрование не настолько долгое что бы клиент не согласился ОДИН раз при регистрации подождать какое то время (количество времени это тоже вопрос) и потом много раз (при авторизации) использовать быстрый MD5.
Хм.. Тогда, похоже, все решается объединением
http://phpclub.ru/talk/showthread.php?postid=256796#post256796
с
http://prosto.pp.ru/Docum/DocumShow.asp?DocumID=335
rsv, я все же не понимаю, что мешает использовать именно тот же md5.js и при регистрации.
http://phpclub.ru/talk/showthread.php?postid=256796#post256796
с
http://prosto.pp.ru/Docum/DocumShow.asp?DocumID=335
rsv, я все же не понимаю, что мешает использовать именно тот же md5.js и при регистрации.
rsv
Новичок
Это как раз принципиальный вопрос. Пароль ни разу не должен появиться в явном виде в сети.И в тоже время должна быть гарантия что сервер его будет знать а при перехвате его не смогут расшифровать.
Если это реализуемо то перед заказчиком ты как разработчик чист. Все что можно со своей стороны ты сделал. Если он начнет вспоминать про сниферов, то это уже проблемы администраторов сети но ни как не твои.
просто здесь тогда вопрос не технологии, а целесообразности.
Нет смысла изваращаться изгаляться, просить о чем-то юзера, висеть на яваскрипте и так далее.
Гораздо проще и правильнее, если стоит вопрос ответственности перед заказчиком - НАДЕЖНЕЕ (чем самопал на коленке) - ССЛ.
Тут и размышлять не о чем.
Нет смысла изваращаться изгаляться, просить о чем-то юзера, висеть на яваскрипте и так далее.
Гораздо проще и правильнее, если стоит вопрос ответственности перед заказчиком - НАДЕЖНЕЕ (чем самопал на коленке) - ССЛ.
Тут и размышлять не о чем.