Инженеры из компании Facebook разработали (https://www.facebook.com/notes/protect-the-graph/improving-a.../) новый протокол DelegatedRecovery (https://github.com/facebookincubator/DelegatedRecovery/), предназначенный для восстановления забытых паролей. Протокол предоставляет сайтам возможность делегирования функций восстановления учётной записи через рабочую учётную запись, контролируемую тем же пользователем, но размещённую в другом сервисе. В качестве эксперимента в ограниченном виде данный протокол опробован в GitHub для организации восстановления доступа при наличии рабочей учётной записи в Facebook, в случае утери телефона или носимого токена, применяемых в двухфакторной аутентификации на GitHub.Протокол нацелен на устранение дополнительных угроз, возникающих при использовании традиционных схем восстановления паролей, манипулирующих известными для конкретного пользователя фактами из разряда "девичья фамилия матери" или использующими отправку кода восстановления через email/SMS (например, при отправке кода восстановления по SMS аккаунт может быть захвачен через получение контроля за смартфоном). DelegatedRecovery позволяет обойтись без привязки к email или номеру телефона, применяя в качестве фактора для восстановления контроля над учётными данными наличие доступа к другому доверительному сервису. Например, для восстановления входа в GitHub может использоваться учетная запись в Facebook.
Суть метода в предварительной генерации и сохранении на стороне другой системы специального токена, содержащего криптослепок параметров аутентификации (в рассмотренном примере GitHub по запросу пользователя может создать слепок учётных данных этого пользователя, после чего этот слепок необходимо сохранить в аккаунте этого же пользователя в Facebook). Все данные в токене зашифрованы и сторонний сервис (в примере Facebook) не может получить доступ к информации. В случае если пользователь потеряет контроль над учётной записью в GitHub он может воспользоваться этим токеном для подтверждения своих прав на учётную запись.
После инициирования процесса восстановления доступа, пользователь может войти в Facebook и отправить в GitHub проверочный токен, который имеет фиксированное небольшое время жизни и по числу возможных попыток восстановления. Кроме содержимого ранее сохранённого токента, ключ восстановления также снабжается цифровой сервиса, подтверждающей, что данные отправлены тем же пользователем, который когда-то сохранил токен.
В настоящее время для изучения и обсуждения доступен черновой вариант спецификации (https://github.com/facebookincubator/DelegatedRecovery/blob/...) протокла, который поставляется под лицензией Creative Commons Attribution 4.0. В ближайшее время планируется опубликовать код эталонной реализации протокола для различных языков программирования, которая позволит внедрить новый метод восстановления доступа на собственном сайте.
URL: https://www.facebook.com/notes/protect-the-graph/improving-a.../
Новость: http://www.opennet.ru/opennews/art.shtml?num=45947
А это разве не равносильно использованию одного пароля на нескольких сайтах? И вообще мордокниге не стоит доверять.
Я так понимаю, нет, потому что если кто-нибудь восстановит твой пароль на Гитхабе взломав твой аккаунт в Фейсбуке, при следующем входе на Гитхаб ты заметишь, что пароль был изменён.
Это как бы уже поздно.
Да и метаданные собирать удобно
Это проверка на тупость похоже
> проверка на тупостьпользователям фб можно сразу внедрять
Взломал один сервис - взломал все. Наверно еще будут и подсказки, для каких других сервисов тут есть токены. Удобно.Ну и даже стыдно упоминать, насколько это было бы удобно для рекламщиков и прочих датамайнеров.
> Взломал один сервис - взломал все.Скорее наоборот. Сейчас взломав email пользователя (например, устроив перехват через MITM) или внедрив троян на смартфон злодеи сразу получают контроль над всеми аккаунтами пользователя.
Метод Facebook поддерживает rate limit, который не даст разом атаковать все аккаунты. И вообще, подразумевается, что восстановление будет через _доверительный_ сервис, аутентификация в котором производится по брелку с токеном. Украсть брелок значительно сложнее, чем затроянить телефон. Плюс, так как аутентификация двухфакторная, нужно как-то узнать и первый фактор.
> через _доверительный_ сервисНу вот же, положила (с).
> Украсть брелок значительно сложнееЭто кому как, карманникам труда не составит, а потом продавать эти ключи на развес.
А если человек по подозрительным сайтам не ходит и откуда попало ускоряльщики интернета не ставит, то попробуй затроянь.
Запатентовали небось, а потом будут трясти бабло с тех, кто сдуру решил использовать эту хипстерскую фигню.
норм. технология. осталось только доверительный сервис найти
У жентельменов принято верить на слово.
значит, традиционная схема с мылом уже тоталитарная, а то же самое, только вместо мыла пейсбук - уже православно и демократично. Ведь так же всё в один спасительный сервис упирается
> значит, традиционная схема с мылом уже тоталитарная, а то же самое, только
> вместо мыла пейсбук - уже православно и демократично. Ведь так же
> всё в один спасительный сервис упираетсяплюсую. нет ничего хуже для интернета, чем централизация. не понимаю, почему большинство админов и прогеров поддерживают подобные новомодные инициативы? неужели настолько отупела ит сфера?
В первую очередь на это ведутся обычные пользователи. А админам просто некуда деваться с подводной лодки. Идти против пользователей - терять бабло.
а что, фейсбук уже можно запустить локально на своем сервере поддиваном?
Вообще, аутентификация всюду через гугл-гитхаб-фейсбук несколько напрягает. Недавно тестировали DC/OS, чтобы поставить на свой кластер - там вход в админку либо через гугл, либо через гитхаб, либо live.com [1]. На наш собственный кластер. Мы не можем войти без благословения гугла. Опции "использовать обычный логин с паролем" или "локальный LDAP" в community-верси просто нет. Можно только отключить аутентизацию вообще. И это свободный софт. Всем пох, никто не форкнет и не пропатчит. Мы тоже (просто выкинули ънтырпрайз в помойку и поставили обычный mesos + marathon).https://dcos.io/docs/1.7/administration/id-and-access-mgt/im...
Просто с точки зрения гугла собственные кластеры не нужны!
Вдогонку: Apache Mesos использовал привычную терминологию master/slave. Потом в багтрекер прибежали Воины Социальной Справедливости и потребовали везде заменить слово slave на agent. Потому что слово slave вызывает ассоциации с притеснением и страданием и может отпугнуть пользователей. Теперь Apache Mesos использует терминологию master/agent. На работе все новички путаются, кто из них кто, старые скрипты сломались, бинарник mesos-slave тоже переименовали, зато Социальная Справедливость восстановлено. Желаю им персонального ада с чертями-феминистками.
Ну сделай свой форк и там поиском замени везде master/agent на white/nigger и радуйся себе.
Я, пожалуй, на днях форкну мир и сделаю всё хорошо.
> Вдогонку: Apache Mesos использовал привычную терминологию master/slave. Потом в багтрекер
> прибежали Воины Социальной Справедливости и потребовали везде заменить слово slave на
> agent. Потому что слово slave вызывает ассоциации с притеснением и страданием
> и может отпугнуть пользователей. Теперь Apache Mesos использует терминологию master/agent.
> На работе все новички путаются, кто из них кто, старые скрипты
> сломались, бинарник mesos-slave тоже переименовали, зато Социальная Справедливость восстановлено.
> Желаю им персонального ада с чертями-феминистками.Угу, комплексы англоговорящих влияют на весь мир :-(
Терминология изначально имела глупое название Хозяин-Рабы с дальнейшим описанием что можно хозяевам и чего нельзя рабам. Рано или поздно это нужно было изменить.Представь: Сердюков-ыдло. Когда Сердюков говорит, все должны молчать. Когда Сердюков передаёт данные, все должны ждать и слушать. Никто не может перечить Сердюкову. Сердюков всегда прав. Сердюков решает какие приоритеты получит каждый из ыдла. Сердюков даёт право на управление и отбирает его когда сочтёт нужным.
Ну как, приятно читать?
Эта терминология старше, чем ты.
Это не значит, что она хорошая. Взять привычное Вырезать-Скопировать-Вставить. Почему "вырезать"? Нажав "скопировать" оно уже куда-то скопировалось? Вставить откуда? Терминология неправильная, но привычная.В конце 80-х в некоторых программах была более удачная "Убрать в карман", "Копировать в карман", "Вынуть из кармана". Но она, к сожалению, не прижилась.
Или "ОК" в формах. Нерусское слово от которого уже сложно будет избавиться.
За бугром дела не лучше: Cut-Copy-Paste это их придумка. И разделять синонимичные OK-Yes тоже.
Проблемы сами не решаются. И я рад что хоть кто-то выкинул наконец Хозяин-Раб. Хотя замену подобрали не лучше Хозяин-Агент. Какой агент? Причём здесь хозяин?
"Вырезать-скопировать-вставить" термины совершенно прозрачные, это ваши личные закидоны.
Термин может быть интуитивно понятным или не быть таковым. Вы придумали "прозрачный термин" - что это? Как определить "прозрачность" термина и в чём она измеряется?
> Почему "вырезать"?Потому, что объект из этого места исчезнет. Ваш КО.
> Нажав "скопировать" оно уже куда-то скопировалось?
В буффер обмена, можешь назвать его карманом, если твоему мозгу так удобно. Ваш КО.
> Вставить откуда?
Из буффера обмена. Ваш КО.
> В конце 80-х в некоторых программах была более удачная "Убрать в карман",
> "Копировать в карман", "Вынуть из кармана". Но она, к сожалению, не прижилась.Потому что занимает много места, при этом не неся дополнительной смысловой нагрузки.
> Или "ОК" в формах. Нерусское слово от которого уже сложно будет избавиться.
А зачем? Всем, кроме альтернативно одаренных было понятно его значение еще в 90-е. Оk считается одним из самых известных слов мира.
> Причём здесь хозяин?
Потому, что он отдает команды рабам, которые их исполняют. Можно конечно заменить его на русское приказчик, а рабов на крепостных или холопов, ну или на начальник и подчиненные. А вот с агентами конечно полная лажа.
Буфер.
МО.
> Почему "вырезать"?Потому что когда из газеты вырезаешь ножницами какой-то кусок, у тебя он есть, а в газете его больше нет. Собственно, отсюда и значок ножниц.
> В конце 80-х в некоторых программах была более удачная "Убрать в карман",
> "Копировать в карман", "Вынуть из кармана". Но она, к сожалению, не
> прижилась.Для кого более удачная? По чему мнению более удачная? Почему кто-то считает, что более удачная?
Почему копируется именно в карман, а не в барсетку или не в авоську? В чей карман копируется, мои карманы остаются пусты?
Да, вполне
> Терминология изначально имела глупое название Хозяин-Рабы с дальнейшим описанием что можно хозяевам и чего нельзя рабам. Рано или поздно это нужно было
> изменить.Рано или поздно нужно бы подучить английский.
master - это ещё и ведущий. А slave - ведомый.Вообще ситуация напоминает хохму, когда какой-то политик возмущается, какую рекламу ему показывают на сайте. Забывая, что реклама зависит от его же посещений.
master и slave - многозначные термины с кучей значений. Какое значение первым всплывает в голове, зависит от того, что у человека на уме. Со стороны ситуация с master/slave выглядит, как будто кучка озабоченных людей видят везде особые знаки и борются с ними.
То есть в этом случае, получив утекший пароль от фейсбука, можно будет замечательно лишиться учёток от гитхаба и чего-то ещё.Это примерно как все сервисы зарегать на один ящик на хотмейле...
Спасибо, НЕНУЖНО.
Что-то участились всякие инициативы по выуживанию учетных данных.Восстановление забытого пароля проще простого работает через почту. Все что нужно, так это возможность добавления альтернативных имейлов.
Каких таких альтернативных емейлов?
как это каких - email1@google.com, email2@google.com, email123@google.com... ой, пароль забыл...
"для восстановления входа в GitHub может использоваться учетная запись в Facebook." - Спасибо.
Ребята изобрели OpenID, чо.
> Ребята изобрели OpenID, чо.если бы :-(
Весь смысл openid (при всей его неуклюжести и уродстве) был в том, что его можно было настроить на _собственный_ сервер. (ну, с поправкой на то, что работающих, надежных и недырявых реализаций серверной стороны так никто в паблик и не выложил) Весь смысл пихания во все дыры мордокниги - чтоб ты думать забыл, что у тебя может быть что-то свое.
(искал я тут hardware token, совместимый с ssh/rdp/хоть чем нибудь, плевать - и при этом не хранящий пароли на себе и не использующий внешний сервер в режиме "скрипт к нему обратился, и получил ответ" (то есть серверу никто не мешает подтвердить не твой, а кого надо доступ. а при падении/блокировке/банкротстве ты вообще идешь нах)... угадай, сколько нашлось?)
> угадай, сколько нашлось?ну и?
заинтриговал
> ...(ну, с поправкой
> на то, что работающих, надежных и недырявых реализаций серверной стороны так
> никто в паблик и не выложил)А как же поиск по строке self hosted openid? Или я не то ищу, о чём вы говорите?
> А как же поиск по строке self hosted openid? Или я не
> то ищу, о чём вы говорите?ищешь то, только не найдешь. Лично у меня оно возвращает стопиццот ссылок на около-wordpress. На самом деле есть еще для drupal модуль. Нутыпонял, да?
То есть это чтоб пописывать комменты не жыжышным или каким-там еще модно юзером, а гордым владельцем stand-alone бложека. А авторизовать этим что-то важное - упаси Б-же.Причем в самом протоколе все наоборот, оно изначально как раз задумывалось как вот в темном углу реально защищенный ящик, который занимается только авторизацией, а вот наши чудесные сайтики, которыми мы можем подписываться с его помощью - отдельно.
Но никому было не надо. Есть (была?) реализация на перл, ужасная как смертный грех.
>> А как же поиск по строке self hosted openid? Или я не
>> то ищу, о чём вы говорите?
> ищешь то, только не найдешь. Лично у меня оно возвращает стопиццот ссылок
> на около-wordpress. На самом деле есть еще для drupal модуль. Нутыпонял,
> да?Нет. У меня возвращает три-четыре реализации и хауту по настройке. ЧЯДНТ?
> То есть это чтоб пописывать комменты не жыжышным или каким-там еще модно
> юзером, а гордым владельцем stand-alone бложека. А авторизовать этим что-то важное
> - упаси Б-же.Разницу пояснишь?
> Нет. У меня возвращает три-четыре реализации и хауту по настройке. ЧЯДНТ?гугль у каждого свой. Ты никогда не ДЕЛАЛ, вот что не так.
Я в свое время пытался разобраться с перловым Net-OpenID-Server - но сдался, обнаружив что там внутри адская вермишель (друпальский модуль в свое время использовал его как основу, но патченый-перепатченый). Есть более-менее работающая питоновская либа, по беглому погляду - съедобная, но это - либа, сервер там надо написать самому, это за пределами моей толерантности к питону и допустимых затрат времени. (там есть proof-of-concept, но он не для работы ни разу - учти, это сервер, торчащий в интернет, навстречу всем досам и попыткам взлома, а прикрывает он самое ценное - твой идентити) Ну и есть аж несколько реализаций на php, ужасных как весь php. Вордпрессу сойдет.
>> То есть это чтоб пописывать комменты не жыжышным или каким-там еще модно
>> юзером, а гордым владельцем stand-alone бложека. А авторизовать этим что-то важное
>> - упаси Б-же.
> Разницу пояснишь?разницу между подписью под комментом и ключом от акаунта э...да пусть даже на гитхабе? Что, это надо пояснять? Поясняю: я тут свою подпись даже и не собираюсь авторизовывать никак. Если кто другой подпишется - посмотрю, что написал. Если интересное - о, это я, мля буду! (а если сам какую фигню спорол - то это, конечно, месть завистников, каждый может три буквы подставить в from ;) А если от моего имени кто-то дерьма накоммитит в мой проект - я рискую растерять всех пользователей или коллег, и долго потом отмывать репутацию (потому что если ты даже логин от гитхаба не уберег, какой же блин ты туда код-то пишешь ;-) А то и незаметно анальный зонд получить (а когда обнаружат - еще и хрен докажу, что не мое), если это что-то стоящее было.
Или что хранить второе в (пусть своем, под столом стоящем) сервере на wp,drupal,jango-чтонибудь или еще какой невероятной мешанине скриптов и модулей имени сотни тысяч обезьян - плохая идея, еще даже худшая чем хранить его в мордокниге?
(слово на букву Р характеризующее надежность данных систем, тут является бранным, кто б мог подумать ;-)А было задумано (авторами стандарта) - ровно наоборот. Ставим маленький надежный сервер (который ничего, кроме подтверждений авторизации не делает и обычным веб-хостом не является), а на бложеге и прочих местах - тупо ему доверяем, кода подтверждающего авторизации там не держим. Но нету, увы.
что за бред ??? а чем это отличается от "фейсбук, сгенери мне хеш32гигабайта, я его положу под подушку на флешке, а когда потеряю пароль - я по нему в тебя войду" ???
> что за бред ??? а чем это отличается от "фейсбук, сгенери мне
> хеш32гигабайта, я его положу под подушку на флешке, а когда потеряю
> пароль - я по нему в тебя войду" ???тем что не в тебю, а в ею. То есть чтоб восстановить просраный гитхабовский логин - нужно залогиниться в мордокнигу _и_ применить флэшку.
А минус- что тебе предлагается поверить, что в процессе генерации этой флэшки у факинбука не образовалось такой же, или эквивалента, позволяющего в этом процессе, при надобности какой, обойтись и без твоего участия заодно.
Ну и до кучи, в бездонные закрома мордокниги, помимо прочих знаний что ты ел на завтрак и каков любимый цвет твоих презервативов, попадет знание о том, ключи от чего именно ты так хранишь - пока это гитхаб, хрен бы, в общем, с ним, но все равно неприятно. А если не поверить пункту 1 - то еще и доступ к содержимому того, что там лежит.
Мда, идиоты. Это ничем не отличается от привязки к мылу или телефону.
Так и не понял, в чём отличие восстановления пароля через привязанный эмейл или телефон. В чём новизна метода-то?
В том, что facebook будет знать о тебе немного больше. а если серьезно - Хыпстеры, инновации ради инноваций! Потом сделают красивую презентацию и будут впаривать различным интернет-компаниям через "верха", которые в технической части ни черта не смыслят.
Граждане! Храните пароли в KeePassX и делайте автоматические бэкапы!
keepassx2
К сожалению, во второй версии он испортился.Исчез генератор паролей с кнопкой "генерировать", вместо него теперь список из одиннадцати паролей, которые при повторном открытии списка остаются те же.
Исчезла возможность генерации удобно произносимых паролей.
Я не знаю, что заставило авторов сделать эти "улучшения". Была очень хорошая программа, и они её испортили.
> К сожалению, во второй версии он испортился.
> Исчез генератор паролей с кнопкой "генерировать", вместо него теперь список из одиннадцати
> паролей, которые при повторном открытии списка остаются те же.
> Исчезла возможность генерации удобно произносимых паролей.
> Я не знаю, что заставило авторов сделать эти "улучшения". Была очень хорошая
> программа, и они её испортили.Можно KeePass2 поставить. Начальный небольшой гемор с моно, и дальше всё работает.
> Можно KeePass2 поставить. Начальный небольшой гемор с моно, и дальше всё работает.Работает, да. Но генератор паролей такой же ущербный. Для меня он был одной из ключевых фишек KeePassX.
Вышел из положения, скачав из репозитория убунты .deb пакет с прошлой версией и заблокировав его обновление в синаптике.Также скачал с офсайта виндовый бинарник KeePassX (ввиду отсутствия линуксового), но он в wine не запускается.
в опциях нажимаешь любую вкл/выкл и пароли перегенерятся
Вспоминая ICQ, увод шести/пятизнаков, где доверительным сервисом была почта... Понанимали школоту, они теперь думают, что самые умные!
Раньше протокол аськи не фишровался, и с помощью простого tcpdump можно было прослушать логин и пароль по сети - это раз.
А во вторых, они хранились в открытом виде локально - это два.
Было два варика украсть акк, ставить хаб в сети и слушать траффик icq или закинуть торяна.
Такой чуши от FB даже не ожидал... да ещё и github им содействует...
Вместо мыла и телефона, которые являются самыми надёжными средствами восстановления доступа, они пытаются наврать хомячкам, что они, мол, ненадёжны и лучше делегируйте нам право войти на любую вашу учётку, начиная с github-а - это гораздо надёжнее и безопаснее.
ну пусть кому-то удобнее использовать фесбук вместо емейла
но если я вдруг потеряю несколько привязанных к нему аккаунтов сразу, то мне придется часами ждать, когда он соизволит восстановить очередной доступ? ибо рейт-лимит
Насколько я понимаю, можно будет делегировать восстановление пароля от одного сервиса другому сервису, а не только почте/телефону/девичьи фамилии материи.Было бы интересно, если бы можно было делегировать произвольному сервису, в т.ч. поднять свой сервис и делегировать восстановление ему.
На практике же скорее всего будет ограниченный список кому можно делегировать, без ввода произвольного значения.
> Насколько я понимаю, можно будет делегировать восстановление пароля от одного сервиса другому
> сервису, а не только почте/телефону/девичьи фамилии материи.
> Было бы интересно, если бы можно было делегировать произвольному сервису, в т.ч.
> поднять свой сервис и делегировать восстановление ему.
> На практике же скорее всего будет ограниченный список кому можно делегировать, без
> ввода произвольного значения.На практике списка не будет, объявят — и жри, что дают.
Сама спецификация на протокол, написанна в стиле RFC, думаю, что её внесут, как RFC в последствии, не налагает ограничений на то, кто будет выступать в роли провайдера восстановления, что хранит токен.
вы наверное с api перепутали. rfc нужен был когда сеть была децентрализована, для чтобы все участники работали согласовано. а сейчас когда сетью рулят несколько корпораций и все завязывается под их нужды и сервисы, на rfc будут класть большой и толстый прибор.
> вы наверное с api перепутали. rfc нужен был когда сеть была децентрализована,
> для чтобы все участники работали согласовано. а сейчас когда сетью рулят
> несколько корпораций и все завязывается под их нужды и сервисы, на
> rfc будут класть большой и толстый прибор.RFC никогда и не был обязательным к исполнению, это не стандарт, это РЕКОМЕНДАЦИЯ по определению!
RFC может при определённых условиях стать Internet Standard (STD), если оно изначально было опубликовано в статусе "Standards Track".
Тут можно посмотреть список RFC, которым присвоен статус Internet Standards (STD): http://www.rfc-editor.org/standards
Я нечего не перепутал, я прочитал спецификацию, что указана в теме, указал, что она оформлена в стиле RFC, указал, что в нём нет указание на то, что вы не можете выступать для себя провайдером восстановления.А будут или не будут разночтения этого RFC среди тех, кто будет реализовывать данный протокол, я не знаю. В идеале их быть не должно, но, как показывает практика других RFC, они бывают и достаточно часто.
Это имело бы хоть-какой-то смысл, если бы восстановление шло по авторизации только от нескольких сервисов одновременно, ну или по схеме 3 из 4 итп
