Комментарии 29
Мартышка и очки. Осталась хоть одна область в которой не попытались использовать блокчейн?
ах Моська, знать она сильна…
А вы, друзья, как ни садитесь, с блокчейном вы не пригодитесь.
Про мартышку было всё таки ближе к истине — очень много тех кто крутит блокчейн и та и сяк, стараясь присобачить хоть как то к своему бизнесу, чтобы срубить бабла.
А вот на identity зря ругаетесь — здесь как раз блокчейн очень даже применим — крайне удобно самому управлять своими идентификационными данными и аккаунтами, не завися ни от каких внешних сервисов.
А вот на identity зря ругаетесь — здесь как раз блокчейн очень даже применим — крайне удобно самому управлять своими идентификационными данными и аккаунтами, не завися ни от каких внешних сервисов.
OAuth от гугл, фейсбука итд еще хорош и тем, что усложняет массовую регистрацию ботов, т.к. нужно попотеть еще с регистрацией там.
Пользователь имеет возможность восстановить доступ в случае утечки его основного ключа (но не в случае утечки ключа восстановления).Ну вот и получается, что если ты потерял код/забыл пароль, то всё — аккаунт ты уже никак не восстановишь. Если информация на сайте не ценная, то хрен бы с ним. А если у тебя там куча всяких подписок, то начинаются танцы с бубном — докажи, что владеешь. И уже админ будешь решать — перекидывать ли доступ, или нет, и вот снова включается человеческий фактор, блокчейн не нужен.
OAuth от гугл, фейсбука итд еще хорош и тем, что усложняет массовую регистрацию ботов, т.к. нужно попотеть еще с регистрацией там.Если хотите заставить пользователя попотеть, всегда можно воспользоваться технологией типа этой github.com/poanetwork/poa-popa. Пользователь получает открытку по почте, вводит код с нее, профит. Бот не пройдет.
По факту защититься от ботов пока еще никто не смог. Все принимаемые меры просто удорожают создание аккаунта. В Ethereum если вы хотите сделать создание аккаунта дорогим, вы можете просто требовать перечислить эфир при его создании.
Ну вот и получается, что если ты потерял код/забыл пароль, то всё — аккаунт ты уже никак не восстановишь.Потерять бумажку из сейфа примерно так же сложно как потерять номер телефона. А попробуйте гугл аккаунт восстановить без доступа к телефону, даже если помните пароль, но Google хочет убедиться что вы это вы. Это не придуманный кейс, это реальная проблема из моего опыта. Нерешенная.
НЛО прилетело и опубликовало эту надпись здесь
Нужно просто уметь отправить транзакцию в Ethereum. Если использовать тестовую сеть то от начала установки метамаска до первого логина — где то минута, да и то — это чтобы записать seed фразу. Если нужна боевая сеть, то потребуется сам эфир, где то на одну транзакцию (это от нескольких центов до доллара, в зависисмости от нагрузки на сеть)
Система аутентификации на сайтах EmerSSL от Emercoin работает с 2015 года, но, увы, особой популярности не сыскала.
Считаю, что сервисы Emercoin круты, и, вероятно, обгоняют своё время.
Считаю, что сервисы Emercoin круты, и, вероятно, обгоняют своё время.
EmerSSL — классная, давно про нее знаю, она куда изящней и технологичней централизованной системы сертификатов. Мы тоже думаем, что для децентрализованной identity еще рано, равно как и для широкого использования смарт-контрактов. Люди только освоили восстановление аккаунтов по емейлу и не желают тыкать ни во что, сложнее чем лайк или «login with Facebook». Но как прижмет, уверен, научатся быстро.
НЛО прилетело и опубликовало эту надпись здесь
То что не говорят на хакатоне Ethereum:
Главная проблема в Ethereum это throughput и именно количество транзакций в секунду. Эта величина если мне не изменяет память, ничтожна мала. Так что какой смысл такой системы в продакшене. Можно конечно смотреть в сторону Hyperledger, но это тоже не вариант на мой взгляд, для такого рода задач.
Ну нет, проблема пропускной способности в данном случае сильно преувеличена. Про это написано в статье.
Сеть Ethereum не очень быстро проводит транзакции (при создании аккаунта пользователю может быть придется подождать несколько минут), но доставать данные и осуществлять проверку аутентификации пользователя можно очень быстро.Вы в фейсбуке регистрируетесь несколько минут(надо же ввести день рождения, почту, пригласить друзей, рассказать где учился, где работал… сексуальную ориентацию наверное скоро надо будет указать) один раз в жизни и в Ethereum регистрируетесь несколько минут один раз в жизни. Потом вы много раз быстро входите в систему. И с эфиром это работает так же быстро за счет существующей инфраструктуры сети, потому что для проверки подписи не нужно отправлять транзакций в сеть, нужен только доступ на чтение.
Как раз для identity скорость сети эфира вполне себе нормальная — перевыпуск ключа — ситуация крайне редкая и эфир без проблем потянет. Если каждый пользователь перевыпускает ключ раз в полгода, то никаких нагрузок на сеть не будет. А проверяется авторизация off-chain и тут можно как угодно разгонять сервис, хоть до миллиона запросов в секунду — это ж просто проверка подписи, она не требует ходить в эфир.
Hyperledger для персональных identity — точно не вариант. Ценность identity в том, что я сам контролирую свои аккаунты и никто не забанит мой аккаунт и не отключит. Hyperledger — штука централизованная, я бы ей точно не доверил свою identity. Вместо него можно публичную MySQL поставить — толку будет столько же.
Ну а про «throughput» — чесгря не очень здорово, когда люди обсуждают количество транзакций в секунду, так, как будто это единственное число, которым блокчейны меряются. Никто из системных архитекторов не оперирует одним лишь числом транзакций в секунду — эта метрика годится для какого нибудь примитивного API с приблизительно одинаковым паттерном использования, во всех остальных случаях количество транзакций в секунду имеет смысл обсуждать только под конкретные задачи, с указанием всех условий и точным описанием того, что считать «концом» транзакции, какова цена отката, и еще десятка важных параметров. Оно зависит от типа транзакций (большие или маленькие), характера транзакций (требуют исполнения серьезных кода или нет), устойчивости к разделению сети, от типа финализации блоков (например в биткоине и эфире математически, пропускная способность может быть 0 транзакций за тысячу лет, ибо алгоритм консенсуса — вероятностный). Никто не спорит про скорость обработки транзакций в блокчейне, разумеется она медленней на порядки, чем в централизованных сервисах, но за это вы получаете независимую от кого бы то ни было и неоспоримую обработку ваших данных, и для identity этот фактор гораздо важнее, чем скорость.
Hyperledger для персональных identity — точно не вариант. Ценность identity в том, что я сам контролирую свои аккаунты и никто не забанит мой аккаунт и не отключит. Hyperledger — штука централизованная, я бы ей точно не доверил свою identity. Вместо него можно публичную MySQL поставить — толку будет столько же.
Ну а про «throughput» — чесгря не очень здорово, когда люди обсуждают количество транзакций в секунду, так, как будто это единственное число, которым блокчейны меряются. Никто из системных архитекторов не оперирует одним лишь числом транзакций в секунду — эта метрика годится для какого нибудь примитивного API с приблизительно одинаковым паттерном использования, во всех остальных случаях количество транзакций в секунду имеет смысл обсуждать только под конкретные задачи, с указанием всех условий и точным описанием того, что считать «концом» транзакции, какова цена отката, и еще десятка важных параметров. Оно зависит от типа транзакций (большие или маленькие), характера транзакций (требуют исполнения серьезных кода или нет), устойчивости к разделению сети, от типа финализации блоков (например в биткоине и эфире математически, пропускная способность может быть 0 транзакций за тысячу лет, ибо алгоритм консенсуса — вероятностный). Никто не спорит про скорость обработки транзакций в блокчейне, разумеется она медленней на порядки, чем в централизованных сервисах, но за это вы получаете независимую от кого бы то ни было и неоспоримую обработку ваших данных, и для identity этот фактор гораздо важнее, чем скорость.
Класс, спасибо. Я не с теми "спецами" по блокчейну до этого видимо общался.
Как насчет ситуации когда пользователь меняет личные данные, типа фамилии или адреса итд, они тоже случаются не часто, но может ли это быть своего рода вектором атаки на такого рода систему?
В теории может. Тут есть естественная защита, в виде комиссии за любую транзакцию, т.е. спамеру дорого будет стоить любая массированная атака на Ethereum, поэтому просто валить тупыми транзакциями по изменению данных бессмысленно. Но если этот контракт является более сложным, например оплачивает работу валидаторов данных, то атака типа «автматически валидировать всё и получать за каждое действие награду» вполне реальна и опасна, никаких возможностей остановить ее у децентрализованных сетей нет, любая валидная транзакция будет выполнена. Невозможность останавливать такие атаки — одна из серьезных проблем блокчейна.
Лучше сделать EOS смартконтракт, а затем запустить с использованием API eos-js. И никаких метамасков не надо…
Для хакатона по Ethereum было бы большим вызовом сделать проект на EOS :-)
Если серьезно, аналог metamask для EOS это scatter, и как реализовать без него что-то подобное я не очень представляю. Пользователь должен использовать свой кошелек, eos-js это только прослойка в браузере между кошельком и блокчейном, так же как web3 в Ethereum.
Сам по себе EOS хорош, но говорить что на нем однозначно делать лучше имхо как-то преждевременно.
Если серьезно, аналог metamask для EOS это scatter, и как реализовать без него что-то подобное я не очень представляю. Пользователь должен использовать свой кошелек, eos-js это только прослойка в браузере между кошельком и блокчейном, так же как web3 в Ethereum.
Сам по себе EOS хорош, но говорить что на нем однозначно делать лучше имхо как-то преждевременно.
Для эфира точно так же можно использовать web3.js без всякого метамаска. Правда от необходимости иметь эфир для отправки транзакций и ставить подпись на транзакцию это не спасет. Большой разницы на фронтенде между EOS и Etheereum нет.
Про web3.js слышал, но мельком. А может и не слышал. Благодарю — изучу.
А что касается ETH для отправки транзакции — да. В EOS, кажется, можно не платить пользователю за транзакцию, Так как DApp приобретают ресурсы. Только вот, как было сказано в одном ответе на мой комментарий, о том, чтобы делать что-то для EOS, говорить рано. Хотя я планирую изучать то, как делать смартконтракты для того блокчейна, потому что считаю перспективным направлением.
А что касается ETH для отправки транзакции — да. В EOS, кажется, можно не платить пользователю за транзакцию, Так как DApp приобретают ресурсы. Только вот, как было сказано в одном ответе на мой комментарий, о том, чтобы делать что-то для EOS, говорить рано. Хотя я планирую изучать то, как делать смартконтракты для того блокчейна, потому что считаю перспективным направлением.
Любой может изобрести криптосистему, которую сам не сможет взломать.
Конкретно эта система уязвима против атаки «Человек посередине». Смотрим описание протокола, два последних пункта, с модификацией между ними от MIM:
> Пользователь, находясь на сайте (frontend), подписывает сообщение при помощи плагина > MetaMask и отправляет его в backend;
Злоумышленник, сидящия на канале связи, пропускает через себя подпись пользователя, потом отсекает пользователя, имитируя разрыв соединения
> Сайт (backend) проверяет подпись, и если все в порядке, активирует сессию пользователя > в соответствии со своей выбранной логикой.
Да, подпись верна, и злоумышленник получает сессию, которую ему любезно создал пользователь.
Мне тут могут заявить, что соединение с сервером делается по https, и мол злоумышленник просто так не вмешается. Беда в том, что MIM-злоумышленник может сам сделать соединение с сервером по https, а соединение с клиентом — по обычному http. Есть ещё ряд трюков, которые позволят злоумышленнику вмешаться, ибо рассмотренный в статье протокол никак не поддерживает не то чтоб атомарность сессии https, а даже никак не реагирует на protocol downgrade.
В общем — удачи, она Вам понадобится.
Конкретно эта система уязвима против атаки «Человек посередине». Смотрим описание протокола, два последних пункта, с модификацией между ними от MIM:
> Пользователь, находясь на сайте (frontend), подписывает сообщение при помощи плагина > MetaMask и отправляет его в backend;
Злоумышленник, сидящия на канале связи, пропускает через себя подпись пользователя, потом отсекает пользователя, имитируя разрыв соединения
> Сайт (backend) проверяет подпись, и если все в порядке, активирует сессию пользователя > в соответствии со своей выбранной логикой.
Да, подпись верна, и злоумышленник получает сессию, которую ему любезно создал пользователь.
Мне тут могут заявить, что соединение с сервером делается по https, и мол злоумышленник просто так не вмешается. Беда в том, что MIM-злоумышленник может сам сделать соединение с сервером по https, а соединение с клиентом — по обычному http. Есть ещё ряд трюков, которые позволят злоумышленнику вмешаться, ибо рассмотренный в статье протокол никак не поддерживает не то чтоб атомарность сессии https, а даже никак не реагирует на protocol downgrade.
В общем — удачи, она Вам понадобится.
Злоумышленник, сидящия на канале связи, пропускает через себя подпись пользователя, потом отсекает пользователя, имитируя разрыв соединенияНе очень понятно в чем отличие этой атаки в случае c OAuth 2 и c Ethereum.
Да, если злоумышленник контролирует канал пользователя и может даунгрейдить соединение до http, он прочитает подписанное сообщение (либо с тем же успехом перехватит access token). Или просто отловит пароль, если у вас парольная аутентификация + идентификатор сессии вообще без всяких OAuth.
Частично может закрыть эту проблему использование куки с флагом Secure чтобы она не ходила по открытым каналам.
В статье по вашей ссылке вижу что EmerSSL использует SSL чтобы оградить трафик пользователя от прослушки. Ну так и в этой схеме ничто не мешает использовать SSL, только вы сами же и утверждаете что это небезопасно.
SSL не позволяет устроить MIM-атаку, так как для успешной атаки MIM должен обладать приватным ключом от сертификата или внедрить себя клиенту в список доверенных корней (в статье об этом сказано). То есть в обоих случаях — получить полный доступ к машине пользователя до злых действий.
Также EmerSSL не позволяет сделать downgrade session, ибо в отличие от куков, сертификат и подпись handshake передаётся только внутри https и в случае downgrade клиент ничего подписывать не будет.
Также EmerSSL не позволяет сделать downgrade session, ибо в отличие от куков, сертификат и подпись handshake передаётся только внутри https и в случае downgrade клиент ничего подписывать не будет.
Вот ваши слова которые я понимаю так что SSL не спасает от MITM.
Вы рассказываете какой крутой EmerSSL, с этим я не спорю, он крутой. Но приведите вектор атаки который будет работать с описанной в статье схемой и не будет работать с OAuth 2 (приведёте такой который и там и там работает — вам же лучше, заработаете денег по bug bounty программе нескольких уважаемых компаний).
Мне тут могут заявить, что соединение с сервером делается по https, и мол злоумышленник просто так не вмешается. Беда в том, что MIM-злоумышленник может сам сделать соединение с сервером по https, а соединение с клиентом — по обычному http.Теперь вы говорите что SSL спасает от MITM. Если спасает, то я все же не понимаю в чем проблема описанной схемы с точки зрения безопасности?
в отличие от куков, сертификат и подпись handshake передаётся только внутри httpsЭто неверно, Secure-куки передаются только по https.
Вы рассказываете какой крутой EmerSSL, с этим я не спорю, он крутой. Но приведите вектор атаки который будет работать с описанной в статье схемой и не будет работать с OAuth 2 (приведёте такой который и там и там работает — вам же лучше, заработаете денег по bug bounty программе нескольких уважаемых компаний).
> Теперь вы говорите что SSL спасает от MITM.
SSL спасает от MIM. Но спасает только если SSL — атомарен, то есть сессия прямая между клинетом и сервером. В случае, когда MIM делает два tls-соединения, или же http-MIM-https — то не спасает.
В случае клиентского сертификата, именно клиент и именно серверу доказывает владение приватным ключом через chap в handshake. Попытка разбить как-то эту сессию приводит к неуспешному handshake.
> Это неверно, Secure-куки передаются только по https.
Ха! Это если сервер сказал браузеру, что кука Secure. А человек посередине, который вместо сервера, вам такого скажет…
Про уязвимость Oauth2 vs client SSL — с ходу сказать не могу, надо разбираться. Но замечу, что в оригинальной статье выше слова SSL/HTTPS не встречаются ни разу, а OAuth2 — дважды, и один раз — в контексте часто применяемого конкурентного продукта, а второй — при сравнении трудоёмкости.
Также не встречается ни «Cookie», ни «Secure cookie». То есть, по факту, доработка протокола идёт в процессе этой вот дискуссии, и вот уже Вы заявляете, что Ваш протокол основан на OAuth2, со всеми его механизмами. Хорошо, если так, но из статьи этого не было видно.
Но покамест я вижу, что критически важные детали протокола появляются в процессе дискуссии. Ситуация напоминает анекдот:
Винни-пух сижит, жуёт пирожок. Подбегает Пятачок:
— Винни! Дай пирожок!
— Это не пирожок, это пышка!
— Винни, дай пышку!
— Это не пышка, это булочка!
— Винни, дай булочку!
— Отвали, свинья! Сама не знаешь, чего хочешь!
SSL спасает от MIM. Но спасает только если SSL — атомарен, то есть сессия прямая между клинетом и сервером. В случае, когда MIM делает два tls-соединения, или же http-MIM-https — то не спасает.
В случае клиентского сертификата, именно клиент и именно серверу доказывает владение приватным ключом через chap в handshake. Попытка разбить как-то эту сессию приводит к неуспешному handshake.
> Это неверно, Secure-куки передаются только по https.
Ха! Это если сервер сказал браузеру, что кука Secure. А человек посередине, который вместо сервера, вам такого скажет…
Про уязвимость Oauth2 vs client SSL — с ходу сказать не могу, надо разбираться. Но замечу, что в оригинальной статье выше слова SSL/HTTPS не встречаются ни разу, а OAuth2 — дважды, и один раз — в контексте часто применяемого конкурентного продукта, а второй — при сравнении трудоёмкости.
Также не встречается ни «Cookie», ни «Secure cookie». То есть, по факту, доработка протокола идёт в процессе этой вот дискуссии, и вот уже Вы заявляете, что Ваш протокол основан на OAuth2, со всеми его механизмами. Хорошо, если так, но из статьи этого не было видно.
Но покамест я вижу, что критически важные детали протокола появляются в процессе дискуссии. Ситуация напоминает анекдот:
Винни-пух сижит, жуёт пирожок. Подбегает Пятачок:
— Винни! Дай пирожок!
— Это не пирожок, это пышка!
— Винни, дай пышку!
— Это не пышка, это булочка!
— Винни, дай булочку!
— Отвали, свинья! Сама не знаешь, чего хочешь!
То что мы делали аналог OAuth но без централизованного провайдера сказано в первом абзаце. Просто там упоминается фейсбук. Если вам так легче, приведите вектор атаки который сработает для сайта который использует вход через Ethereum, но не сработает для сайта который использует вход через Facebook.
А если любите юмор, то вот вам подходящая история про хакера и солонку в столовой xakep.ru/2006/12/16/35784.
А если любите юмор, то вот вам подходящая история про хакера и солонку в столовой xakep.ru/2006/12/16/35784.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Делаем web-аутентификацию через блокчейн