что используя md5 можно логинится это давно известно. lj.com.ua еще так делало :)

Блин, второй прецедент, куда разработчики ЖЖ смотрят?
На кой хер они делают MD5(chal + MD5(pass)), если можно делать MD5(chal + pass)?
Видимо, конечно, на базе пароли лежат в хэшах, но это их внутренние %^&* проблемы.

основная идея не на нашего, а на американского хакера, который пароль тырит с компа взглядом: хеш "810a5bdaafc6dd30b1d9979215935871" гораздо сложнее запомнить чем пароль "fuck"

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

Если бы автор хотел стырить пароли, он бы просто не сворачивал их по MD5, только и всего (ну, или сворачивал бы, но неправильно).
А MD5 (chal + MD5 (pass)) - это безопасно (*), хотя и дает возможность аутентифицироваться по MD5 (pass), так как никто из команды ЖЖ, на сколько я знаю, и не гарантировал, что безопасно раздавать посторонним MD5 (pass), и те, кто его просят, могли бы с тем же успехом попросить и сам пароль.

(*) Да, разумеется, более безопасно передавать по сети MD5 (pass), так как его, как правильно заметил white_gym_shoe@lj, хотя бы со взгляда запомнить сложнее. Но это мелочи все.

Андрюх, ты не понял.
Код приведен из настоящего логина, как в ЖЖ сделано.
Ну, или я твое замечание не очень понял.

В исходном коде свертка только пароля.

Ну да, я и имел ввиду, что _в коде lj_ свертка md5 (chal + md5 (pass)) настолько же безопасна, как и md5 (chal + pass), с точностью до легкозапоминаемости пароля/хэша, летяжего мимо атакующего.
Именно передача третьему лицу пароля или md5 от него - эквивалентны.

Ну да, криптостойкость сверток одинакова.

Опять я не так сформулировал.
Так или иначе, если бы было md5 (chal + pass), md5 (pass) был бы менее сенситивен (но все же не совсем безопасен из-за словарных атак), но и аутентифицироваться по нему было бы нельзя.

Ага, но зато более сенситивна стала бы DB на кластерах в Сиэттле или где она там.

Ну да. Впрочем, если уж подломили базу на чтение, то хэшей все равно достаточно, так что можно и не париться :) Чтобы схема, аналогичная shadow passwords, нормально работала, нужно, чтобы на сервер по сети приходил _пароль_, и уже там его сворачивали и сравнивали с хранящимся _хэшем_. Тут же просто роль пароля выполняет хэш (т.е. сенситивность хэша ничуть не ниже сенситивности пароля), и база так и так одинаково уязвима.

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

Кстати, какого хера LJ не сделает логин через SSL?

Через ssl - имхо, причина в том, что у них просто столько лепестричества нету, чтобы питать ту кучу серверов, которая должна будет эти миллионы сессий шифровать и расшифровывать.
Вот для платников могли бы и сделать - просто аутентификация по сертификату в браузере и все, и никаких паролей.

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

Ну и нафиг тогда SSL, если все остальное все равно пойдет cleartext-ом...

Че-то я перестал понимать.
Внутри SSL можно хоть обгоняться cleartext-ом, в чем проблема-то?

Ну да. Но ты ведь, если я правильно понял, предлагаешь уже аутентифицированную сессию гонять уже без всякого SSL? То есть, пароль украсть нельзя, но посидеть под этим логином все еще можно.

Ага.
Ну так а сейчас как от этого защищаются - одноразовую куку выдают?

Ну дык, я в курсе, что сейчас - плохо :)

В принципе, мы сейчас с автором обсуждаем возможность более безопасной переделки кода.
Вроде, речь о фишинге пока не идет, но все же, те, кто в этом участвовал уже - смените пароли на всякий случай. Мало ли...

Безопасно - это сначала просить у ЖЖ форму с challenge-ом, брать challenge, отдавать юзеру, он его _на внешнем, своем собственном, сворачивателе MD5_ сворачивает вместе с паролем, отдает серверу, тот отдает в ЖЖ. И даже тут пользователь должен доверять автору скрипта в том, что тот втихую не поменяет email и не вышлет пароль туда.
Все прочие схемы - небезопасны даже в случае доверенного автора скрипта.

Вообще-то, совсем безопасно - это как делала (http://orie.msk.ru/lj/ljtags.php) orie@lj, во всех остальных случаях все равно остается вопрос доверия к автору утилиты.

Безопасно - это сначала просить у ЖЖ форму с challenge-ом, брать challenge, отдавать юзеру, он его _на внешнем, своем собственном, сворачивателе MD5_ сворачивает вместе с паролем, отдает серверу, тот отдает в ЖЖ. И даже тут пользователь должен доверять автору скрипта в том, что тот втихую не поменяет email и не вышлет пароль туда.

Ага.
А что у тебя в куках, которые livejournal.com сдает, лежит? :)
Ладно, пусть хэша пароля там и нет, но что мешает на сервере сделать логин с бессмертной кукой? И email менять не надо...

Ну да, именно поэтому я и сказал, что вопрос доверия автору скрипта все равно встает в полный рост.

Вообще-то, совсем безопасно - это как делала orie@lj, во всех остальных случаях все равно остается вопрос доверия к автору утилиты.

Ага, просить пользователя выполнить своими руками XML-RPC запрос и прислать результат, желательно, сильно пожав.
Мы такой сервис обсуждаем, что там и правда вилы - нужен логин.
А с логином тоже вилы...

Короче, без помощи от разработчиков LJ все равно ничего хорошего не получится. Нужна схема частичных прав и одноразовых "билетиков".

можно делать два варианта - первый для умных и параноидальных, а второй для глупых и доверчивых ;)

по xml-rpc нельзя поменять эмайл
http://www.livejournal.com/doc/server/ljp.csp.xml-rpc.protocol.html
кстати, я поменял код - теперь всё через auth_challenge.

Кстати, насколько я помню, менять email не шибко-то и поможет.
Там есть такое понятие, как email, введенный при регистрации, и у него, вроде, приоритет.

Ну так никто же не проверяет, не менялся ли он. Я вот, к примеру, долго не замечу. Понятно, что увидев бяку, я всегда смогу вернуть контроль над аккаунтом, но я же просто бяку не замечу.

javascript: hex_md5(challange.value + hex_md5(password.value))
Такой используется у LJ?

Да.

Ладно, вот вам совершенно безопасный вариант использования данного сервиса.
Создается пользователь, точная копия исходного, с такими же френдами, но пустой.
Его логин и пароль подставляются в форму.
Привет.

Ещё проще, пользователь специальный создаётся для сервиса и френдит всех кого хочет узнать дату д.р. Ограничение -- 750 пользователей, но должно хватить (не для paid members).

Вы хотите сказать, что платники могут иметь более 750 френдов?
А вы мне можете хоть одного такого показать?

Раньше (может пару лет назад) точно можно было.

"Это было давно и неправда".
И достигалось не платностью, а баном лишних юзеров.

Вообще непонятна причина давать возможность логина с помощью MD5. Мы когда-то сидели, разбирали это дело – никаких преимуществ по сравнению с посылкой оригинальных паролей.
В общем-то, разводкой изначально занимаются те, кто дает возможность логина, убеждая страшными словами типа md5, hash, digest etc о том, что безопасность выше, хотя это совсем не так.

Кстати, ведь данные о дне рождения так или иначе доступны прямо в userinfo каждому желающему - в чем проблема?
Ну да, HTML надо распарсить, но по сравнению со всеми остальными потугами это такая фигня...

Тут это обсуждается все: http://www.livejournal.com/users/tsvetna/577934.html

И gzip упомянутый, кстати, нихера не поможет, потому что количество значимой информации на userinfo page совершенно безумное по сравнению с датой рождения.

Потому orie и просила выдрать нужный кусок руками :)

Мы как-то забыли выяснить, нахрена вообще кому такой сервис нужен...

нахрена вообще кому такой сервис нужен...
как зачем - ввести логин/пасс и запостить картинко :)

!
этот вопрос надо было в корневой пост вынести... =)

Можно xml парсить, что правильнее: http://www.livejournal.com/users/username/data/foaf

Ну тем более. Просто я не знал, что там в xml отдается, зато был уверен, что в userinfo оно точно есть.

я этому никонорову уже 40 раз объяснял, что этот foaf в данном случае равносилен парсу страницы userinfo, так как отдаёт только ДР одного юзера.
А вместе с тем впридачу пихает список всех френдов. Короче объём данных для получения дня рождения френдов равен примерно 4МБ на сотню пользователей.

мне тут посоветовали рвать соединение после получения даты. можно конечно попробовать, но всё равно огромное количество запросов к серверу.

Да это все херня из-под ногтей.
LJ API, похоже, суровая штука. Ну вот на кой болт ему пароль, чтобы XML-RPC вызов делать?

я тоже не понимаю
http://www.livejournal.com/community/lj_clients/189694.html?nc=4
при том при всём, что функционал довольно-таки ограниченный.

люди! вы такие умные! скажите, я могу как-то пострадать, если тест прошла, но потом сменила пароль?

Нет.
Кстати, сам автор теста советует всем сомневающимся сейчас ровно так и делать.

спасибо!

исправил. теперь идёт через auth_challenge. Проверь. http://java.in.ua/lj/
Так лучше?
Или всё равно есть возможность того что либо я, либо кто-то другой украдёт?

Угу, теперь отлично.
Теперь нельзя говорить о том, что ты можешь украсть пароль при таком механизме логина.
Кто-то другой тоже не может.

Украсть нет, но воспользоваться-то - да.

А от этого, мне кажется, в данном случае нельзя защититься, не поменяв некоторые вещи в движке LJ.

Upd.: пользуйтесь на здоровье, автор сервиса привел механизм логина в соответствие стандартному механизму логина LJ.
Что, отдает юзеру challenge, пришедший от LJ?

Ага.

Да глянь там в жабоскрипт, он теперь такой же, как и у ЖЖ-шного логина.
Как подделать challenge я пока не смог придумать. :)

Ну, challenge не надо подделывать. Достаточно подделать кусок javascript-а :)))))))))))))))))
Но это недостаток и самого LJ тоже - man in the middle take it all, будь этим мэном-в-середине автор утилиты или чудак со сниффером-инжектором в коридоре на моем куске UTP.

Это не просто "очень запарно", а "очень-очень-очень запарно".
Массовую атаку так никто делать не будет.
А целевую атаку проще сделать взяв утюг, ствол, пару железяк и двух друзей.

Ты не понял. Автор утилиты попадает в перечень людей, являющихся этими мэнами, причем не бегая вдоль кабеля с крокодилами.

Хехе.
Это то, о чем мы с Андрюхой Никаноровым в аське говорили.
Вот только я не уверен, что стоит в ЖЖ устраивать full disclosure, народу-то полно, а прецеденты были.

Кому надо - и так понимает. Так что лучше этот самый disclosure, имхо, все же устраивать.

Другое дело, что неплохо бы пролоббировать в LJ team добавления в API на тему тех самых "билетиков частичной одноразовой авторизации", но это уже не в моих силах, да и геморроя с правильной их реализацией будет целый чемодан (чего стоит только само удостоверение пользователя независимым от автора утилиты способом того, какие права дает билетик).

перед созданием логин-пейдж

$c = new xmlrpc_client("/interface/xmlrpc", "livejournal.com", 80);
$f = new xmlrpcmsg('LJ.XMLRPC.getchallenge');
$v = rpc_call($c, $f);
$challengeDate = $v->structmem("challenge");

и заполняем
<input ... >

О, красиво :)
Теперь все ок.
Правда, будучи занудой, я все равно вижу способ такое атаковать как для Вас как автора (что проще), так и для man-in-the-middle :) Можно просто подменять страничку с javascript-ом в то время, пока она летит к пользователю, только и всего. Пользователь же не производит аудит кода _каждый_ раз, когда жмет submit. Но тут спасение только одно - внешний, принадлежащий пользователю, калькулятор MD5 :)))))))

Ну я всё равно на всякий случай пароль поменяла - иногда это же надо делать, а тут повод :)

Алекс, ты ошибся.

Нет, alexsun@lj не виноват.
Я буквально пару дней назад видел ссылку на описание атаки на ЖЖ у кого-то из молодежи. Проверять не стал, поскольку не вдавался в детали, но работает дыра только в IE5 и IE6. Сейчас буду искать...

а) какое счастье, что я пользуюсь файерфоксом
б) говорят, это спектрум отмочил )

Не думаю, что это спектрум, но это точно кто-то, кто его знает.
Кто-то с warnet.ws, статья о баге в IE, по моим воспоминаниям, там и была, но сейчас разве получится ее найти, поисковик перегружен спамом с упоминанием этого сайта.

Вот еще написали: http://www.livejournal.com/community/ljplus/67892.html

А зачем нужен пароль для взятия списка френдов? Насколько я понимаю, логиниться для этого не обязательно. Объясни, пожалуйста. Или это от лени?