Комментарии 74
Поздравляю! Вы сейчас изобрели почти Base64
Почти. Но, в отличие от Base64, в моей программе набор символов для кодирования символов можно задать произвольно в следующей строке:
const string alphabet=«1234567890qwertyuiopasdfghjklzxcvbnmQWERTYUIOPASDFGHJKLZXCVBNM»;
const string alphabet=«1234567890qwertyuiopasdfghjklzxcvbnmQWERTYUIOPASDFGHJKLZXCVBNM»;
Вы в сущности изобрели переход из шестнадцатиричной системы счисления в N-значную, где N — это длина вашей строки. Вроде как эти алгоритмы вообще в школе проходят, а тут целая статья на хабре…
Это не Base64 и не переход между системами счисления. Base64 увеличивает длину входной строки приблизительно на треть. Здесь же длина строки — один к одному. Под длиной входной строки здесь понимается хеш в 32 бинарных байта на выходе из Sha256, а не в два раза большее его hex-представление.
При этом и Base64, и конвертация между системами счисления не теряют данные — исходная строка восстановима вместе со всей ее устойчивостью к перебору. Здесь же мы видим фактическую упаковку хеша Sha256 с потерей данных, что означает, что для брутфорса взлом прямым перебором будет на порядки быстрее, особенно если знать алфавит. То есть данным алгоритмом, так или иначе, снижается надежность Sha256, превращая его фактически в Sha63 или что-то вроде того.
Аналогично можно было просто взять каждый четный или каждый нечетный символ хеша и сократить длину пароля в 2 раза, оставшись на выходе в пределах hex набора символов(что еще более снизит устойчивость к брутфорсу — Sha16 в эквиваленте). Можно и в данном алгоритме на выходе брать четные или нечетные символы, сокращая длину пароля, результат будет тождественен.
Обычно пароли для пользователей так и генерируют — алгоритмами, похожими на алгоритм в статье. Только отличие в том, что принято генерить такие пароли, используя генератор (псевдо-)случайных чисел.
Но все это не важно, т.к. статья по тексту и названию никак не претендует на усиление криптозащиты. И ее(криптозащиты) реализация может быть любой. По поводу того же брутфорса можно долго теоретизировать о том, что на многих сайтах, где вам дают выбрать самому себе пароль, прямо в правилах практически явно указывается алфавит и длина("… не менее 6 символов, можно использовать строчные и прописные латинские буквы и цифры..."), о том, что мало кто сам себе придумывает пароли длиннее 8 символов, и что защита от брутфорса делается не в алгоритме генерации пароля, а в движке сайта(блокировка после N попыток, капча и т.п.), о том, что частенько сайты ломаются не подбором паролей в лоб, да и вообще в обход механизмов аутентикации, ну и много еще о чем.
Как я понял, главный посыл статьи: идея реализовать аутентификацию без хранения базы паролей. То, что нельзя конкретному юзеру сменить пароль, обходится ведением базы разрешенных логинов — просто меняем юзеру в базе логин(соответственно и этот несохраняемый пароль тоже сменится).
Идея сама по себе не нова, но ее мало кто использует из-за определенных неудобств:
То есть, область применения этой идеи достаточно ограничена ее же условностями.
Итого: за напоминание забываемой в последнее время идеи ставлю плюс с натяжкой. Натяжка только потому, что идея не нова и в общем-то не блещет плюсами гибкости для пользователя. Хотя какая нафиг она забываемая — регулярно ее изобретают заново, и так же регулярно от нее отказываются. Значит отсавлю плюс за то, что автор не накосячил в коде своей реализации. Обычно те, кто ее изобретают в очередной раз, косячат тут же в реализации процентах в 90 случаев.
При этом и Base64, и конвертация между системами счисления не теряют данные — исходная строка восстановима вместе со всей ее устойчивостью к перебору. Здесь же мы видим фактическую упаковку хеша Sha256 с потерей данных, что означает, что для брутфорса взлом прямым перебором будет на порядки быстрее, особенно если знать алфавит. То есть данным алгоритмом, так или иначе, снижается надежность Sha256, превращая его фактически в Sha63 или что-то вроде того.
Аналогично можно было просто взять каждый четный или каждый нечетный символ хеша и сократить длину пароля в 2 раза, оставшись на выходе в пределах hex набора символов(что еще более снизит устойчивость к брутфорсу — Sha16 в эквиваленте). Можно и в данном алгоритме на выходе брать четные или нечетные символы, сокращая длину пароля, результат будет тождественен.
Обычно пароли для пользователей так и генерируют — алгоритмами, похожими на алгоритм в статье. Только отличие в том, что принято генерить такие пароли, используя генератор (псевдо-)случайных чисел.
Но все это не важно, т.к. статья по тексту и названию никак не претендует на усиление криптозащиты. И ее(криптозащиты) реализация может быть любой. По поводу того же брутфорса можно долго теоретизировать о том, что на многих сайтах, где вам дают выбрать самому себе пароль, прямо в правилах практически явно указывается алфавит и длина("… не менее 6 символов, можно использовать строчные и прописные латинские буквы и цифры..."), о том, что мало кто сам себе придумывает пароли длиннее 8 символов, и что защита от брутфорса делается не в алгоритме генерации пароля, а в движке сайта(блокировка после N попыток, капча и т.п.), о том, что частенько сайты ломаются не подбором паролей в лоб, да и вообще в обход механизмов аутентикации, ну и много еще о чем.
Как я понял, главный посыл статьи: идея реализовать аутентификацию без хранения базы паролей. То, что нельзя конкретному юзеру сменить пароль, обходится ведением базы разрешенных логинов — просто меняем юзеру в базе логин(соответственно и этот несохраняемый пароль тоже сменится).
Идея сама по себе не нова, но ее мало кто использует из-за определенных неудобств:
- Невозможность смены пароля конкретному логину;
- Невозможность выбора пароля самим пользователем;
- Приходится прятать мастер-пароль как можно дальше и как можно глубже, желательно вообще на другую машину с очень сильно ограниченным доступом, т.к. мастер-пароль является ключем ко всему.
То есть, область применения этой идеи достаточно ограничена ее же условностями.
Итого: за напоминание забываемой в последнее время идеи ставлю плюс с натяжкой. Натяжка только потому, что идея не нова и в общем-то не блещет плюсами гибкости для пользователя. Хотя какая нафиг она забываемая — регулярно ее изобретают заново, и так же регулярно от нее отказываются. Значит отсавлю плюс за то, что автор не накосячил в коде своей реализации. Обычно те, кто ее изобретают в очередной раз, косячат тут же в реализации процентах в 90 случаев.
НЛО прилетело и опубликовало эту надпись здесь
На моей памяти это уже 10 статья подобного рода.
Пруфлинк?
НЛО прилетело и опубликовало эту надпись здесь
я в общем тоже видел на хабре пачку статей подобного рода, но заявление действительно должно быть подкреплено, или заявивший должен быть готов предоставить подкрепление.
А то получается так:
Петрик: «я изобрёл фильтры для воды на наночастицах, очищают всё!»
Учёные: «будте любезны, предоставьте доказательства»
Петрик:«берите и ищите сами, если вам нужно»
Конечно утрирую сильно, но всё же.
А то получается так:
Петрик: «я изобрёл фильтры для воды на наночастицах, очищают всё!»
Учёные: «будте любезны, предоставьте доказательства»
Петрик:«берите и ищите сами, если вам нужно»
Конечно утрирую сильно, но всё же.
Вообще-то не соглашусь. За слова нужно отвечать и в любой момент подтверждать их фактами.
А то так можно любую чушь сморозить, да при этом еще и обвинить собеседника в лени.
Типа «да люди уже 15 лет как Марс заселили, там теперь население около 2 млрд.» А на вопрос о пруфлинке, сослать в гугл, мол ну вы паразит ленивый, ищите сами, а я все сказал и весь такой умный из себя удаляюсь.
Нельзя так.
А то так можно любую чушь сморозить, да при этом еще и обвинить собеседника в лени.
Типа «да люди уже 15 лет как Марс заселили, там теперь население около 2 млрд.» А на вопрос о пруфлинке, сослать в гугл, мол ну вы паразит ленивый, ищите сами, а я все сказал и весь такой умный из себя удаляюсь.
Нельзя так.
habrahabr.ru/post/145166/
habrahabr.ru/post/146100/
habrahabr.ru/post/146196/
И это только июньские :)
habrahabr.ru/post/146100/
habrahabr.ru/post/146196/
И это только июньские :)
Я тоже когда то изобретал этот велосипед: habrahabr.ru/post/115786/ Единственный плюс такой системы это сложность пароля. Существенный минус в том, что у разных сайтов разные требования к длине пароля и потому на практике не обойтись лишь знанием того какой сайт и логин — нужно дописывать ограничения к паролю. Поэтому у меня появился файл с кучей записей такого вида:
skype mylogin S16
skype mypass S16
thebank mylogin S8
thebank mypass S16
Где S8/S16 это длина пароля и название алгоритма. После того как таких записей становится штук 50, очень сложно бывает вспомнить какая длина пароля на том сайте куда я хочу зайти и мне приходится лезть в этот файл и искать запись соотвествующую сайту. Вообщем получается, что программы для хранения паролей типа keepass намного удобнее.
skype mylogin S16
skype mypass S16
thebank mylogin S8
thebank mypass S16
Где S8/S16 это длина пароля и название алгоритма. После того как таких записей становится штук 50, очень сложно бывает вспомнить какая длина пароля на том сайте куда я хочу зайти и мне приходится лезть в этот файл и искать запись соотвествующую сайту. Вообщем получается, что программы для хранения паролей типа keepass намного удобнее.
habrahabr.ru/post/145166/
habrahabr.ru/post/146100/
habrahabr.ru/post/146196/
И это только июньские :)
habrahabr.ru/post/146100/
habrahabr.ru/post/146196/
И это только июньские :)
А не проще ли использовать шифрование вместо хеш-функции. А если использовать хеш-функцию, то дополнять HMAC?
Сюрприз: пароли из 64 символов, каждый из которых принимает одно из 16 значений и 32 символов, каждый их которых принимает одно из 128 значений, имеют одну и ту же надежность.
Нет. Во втором случае надежность снижается. Или это был сарказм?
Нет. Это было либо неправильное умножение 4 на 2, либо неправильное возведение 2 в 7 степень. Вместо 128 должно было быть 256:)
Имелось в виду, что утверждение автора о «маленький алфавит => пароль слабый» неверно.
Имелось в виду, что утверждение автора о «маленький алфавит => пароль слабый» неверно.
А, это вы про это:
Да, тут у автора косячок, ибо его алгоритм как раз таки уменьшает надежность исходного хеша как пароля.
Длина результата хэш-функции более чем предостаточна для пароля. Но надежность пароля все равно оставляет желать лучшего. Каждый символ такого пароля может принимать только одно 16-ти значений, так как результатом хэш-функции является строка чисел в шестнадцатеричном представлении.
Да, тут у автора косячок, ибо его алгоритм как раз таки уменьшает надежность исходного хеша как пароля.
Эту проблему можно решить, если использовать остаток от деления не байта, а слова (т.е. двух байт).
Эту проблему можно решить, если использовать хэш как одно число, в вашем случае 256-битное.
Эту проблему можно решить, если использовать хэш как одно число, в вашем случае 256-битное.
Зачем нужна эта программа? Сложность сгенерированного пароля равна сложности keyword. Взломав его, можно взломать все остальные сайты пользователя, использующего данную программу и тот же keyword. Так что проще просто вводить keyword вместо пароля.
Я бы об этом написал в минусах. Первым пунктом. Жирным шрифтом.
Я бы об этом написал в минусах. Первым пунктом. Жирным шрифтом.
Для keyword можно взять несколько килобайт рандомных данных. Как будете ломать?
Может вы не до конца поняли алгоритм? keyword используется только сервером(возможно даже только отдельным сервером аутентификации). Пользователь не знает keyword.
Может вы не до конца поняли алгоритм? keyword используется только сервером(возможно даже только отдельным сервером аутентификации). Пользователь не знает keyword.
НЛО прилетело и опубликовало эту надпись здесь
«Пользоваться программой просто. Вводите мастер-пароль, адрес сайта, логин. Нажимаете enter.»
Мастер-пароль = keyword в обозначениях автора. Если он несколько килобайт рандомных данных, то явно будет где-то записан. А это уже ненадежно.
Пользователь знает keyword, по заявлению автора. Если бы он не знал его и была бы реализована схема, описанная вами (сервер выдает пользователю пароль по логину и сайту), то я бы вообще сторонился бы такой программы, так как личную информацию доверять третьему лицу не привык.
Мастер-пароль = keyword в обозначениях автора. Если он несколько килобайт рандомных данных, то явно будет где-то записан. А это уже ненадежно.
Пользователь знает keyword, по заявлению автора. Если бы он не знал его и была бы реализована схема, описанная вами (сервер выдает пользователю пароль по логину и сайту), то я бы вообще сторонился бы такой программы, так как личную информацию доверять третьему лицу не привык.
Вы скорее всего не очень поняли. Программа, о которой идет речь в посте — просто демо, не более. Вы ее можете использовать для генерации паролей самому себе, используя свой несложный запоминаемый мастер-пароль, если вам так угодно. Кстати, как обычный юзерский пароль, генерит оно вполне нормально, 32 символа, пусть даже с ограниченным алфавитом — это вполне неплохо. Если у целевого сайта есть защита от быстрого перебора — задолбутся брутфорсить.
Если же реализовывать этот же алгоритм на сервере — мастер-пароль можно делать каким-угодно, хоть несколькокилобайтным файлом, никакой пользователь мастер-пароля знать не будет, не должен и не может. Пользователь будет знать только свой логин и конечную сгенеренную последовательность.
У автора однозначно есть сильный косяк в понимании происходящего, обсуждаемый выше вокруг цитаты «Но надежность пароля все равно оставляет желать лучшего» и далее про HEX-представление. Это серьезный косяк, ибо в неисправленном виде может повлиять на безопасность его(автора) дальнейших разработок. С этим не вижу смысла спорить, с этим я согласен на все сто.
Но сам код данного поста, если правильно понимать его предназначение и функционал, собран в общем-то без ошибок.
А функционал его заключается только в упаковке неудобоваримого длинного хеша в более человечески запоминаемую последовательность для конечного юзера. Да — упаковка хеша с потерей данных. Да — понижение устойчивости ключа. Но сами подумайте — на большинстве сайтов большинство пользователей делают себе еще более короткие пароли(явно менее 32 символов) приблизительно с таким же алфавитом.
То есть текущий выхлоп программы можно сократить еще в два-четыре раза, потеряв конечно же дополнительно в устойчивости ключа, и только тогда мы приблизимся к устойчивости большинства обычных самопридуманных паролей, таких как на большинстве сайтов. Да и то, с оговоркой, что у нас пароли будут наиболее защищенными среди подобных, ибо у нас-то вряд ли будет множество последовательностей типа «12345», «qwerty», «masha1985» и т.п.
То есть по сути мы имеем генератор юзерских коротких паролей(да, с их недостатками, но с однозначным исключением атаки с использованием социнженерии), только без необходимости хранить БД паролей на сервере.
Добавьте к этому алгоритму со стороны сервера защиту от перебора по таймеру или количеству попыток на логин, а так же автовыбор длины пароля в разумных пределах, и все будет хорошо.
Зачем нужен автовыбор длины? Усложнение работы брутфорсеру. Если длина пароля одна везде, то условия для настройки программы брутфорса упрощаются, например выставляем длину 16 символов, и программе не придется перебирать комбинации из 6-15 символов и т.п. А тут количество вариантов увеличивается )
Если же реализовывать этот же алгоритм на сервере — мастер-пароль можно делать каким-угодно, хоть несколькокилобайтным файлом, никакой пользователь мастер-пароля знать не будет, не должен и не может. Пользователь будет знать только свой логин и конечную сгенеренную последовательность.
У автора однозначно есть сильный косяк в понимании происходящего, обсуждаемый выше вокруг цитаты «Но надежность пароля все равно оставляет желать лучшего» и далее про HEX-представление. Это серьезный косяк, ибо в неисправленном виде может повлиять на безопасность его(автора) дальнейших разработок. С этим не вижу смысла спорить, с этим я согласен на все сто.
Но сам код данного поста, если правильно понимать его предназначение и функционал, собран в общем-то без ошибок.
А функционал его заключается только в упаковке неудобоваримого длинного хеша в более человечески запоминаемую последовательность для конечного юзера. Да — упаковка хеша с потерей данных. Да — понижение устойчивости ключа. Но сами подумайте — на большинстве сайтов большинство пользователей делают себе еще более короткие пароли(явно менее 32 символов) приблизительно с таким же алфавитом.
То есть текущий выхлоп программы можно сократить еще в два-четыре раза, потеряв конечно же дополнительно в устойчивости ключа, и только тогда мы приблизимся к устойчивости большинства обычных самопридуманных паролей, таких как на большинстве сайтов. Да и то, с оговоркой, что у нас пароли будут наиболее защищенными среди подобных, ибо у нас-то вряд ли будет множество последовательностей типа «12345», «qwerty», «masha1985» и т.п.
То есть по сути мы имеем генератор юзерских коротких паролей(да, с их недостатками, но с однозначным исключением атаки с использованием социнженерии), только без необходимости хранить БД паролей на сервере.
Добавьте к этому алгоритму со стороны сервера защиту от перебора по таймеру или количеству попыток на логин, а так же автовыбор длины пароля в разумных пределах, и все будет хорошо.
Зачем нужен автовыбор длины? Усложнение работы брутфорсеру. Если длина пароля одна везде, то условия для настройки программы брутфорса упрощаются, например выставляем длину 16 символов, и программе не придется перебирать комбинации из 6-15 символов и т.п. А тут количество вариантов увеличивается )
НЛО прилетело и опубликовало эту надпись здесь
То, о чем вы пишете, все верно. Но это не должно быть узким местом системы. И уж точно не может являться критикой текущей статьи. Защита сервака и его криптодвижка — это отдельная песня.
Если можно увести из базы пароли, то, как правило, можно увести и всю базу, и скорее всего ее можно и грохнуть(про бекапы речь отдельная).
Поэтому в обоих случаях неплохо иметь демон на соседнем серваке, к которому есть доступ только по одному порту, который занимается аутентификацией. На него же можно повесить и контроль количества неверных попыток. В таком случае криптомодуль для злоумышленника будет черным ящиком, и сможет защитить сервер даже в большинстве случаев безалаберности программиста, «изобретшего» очередной кривой алгоритм.
Я это к чему — обычно на сервер с веб-мордой сайта вломиться гораздо проще, чем на отдельно-стоящий демон аутентификации. Если веб-проектов масса, одного такого сервака с демоном достаточно для обслуживания туевой хучи проектов. Вероятно поэтому у автора хеш генерится из составной фразы «keyword+sitename+login».
Кроме того, если вы еще раз посмотрите на код в статье, там есть только функция convert(), которую мы как бы и обсуждаем — упаковка хеша. Как этот хеш изначально получается — дело десятое. Хоть в результате шифрования с открытыми-закрытыми ключами. Главное, чтобы при получении логина очередного желающего войти на сервер юзера, сервер мог автоматом в памяти сгенерить его пароль для сравнения.
То есть фактически я говорю только о паре строк кода, не обсуждая остальное и связанные с ним проблемы — иначе это будет долгий неуникальный разговор, скорее всего к тому же непродуктивный вследствии регулярности подобных разговоров в коментах всех похожих тем )))
Если можно увести из базы пароли, то, как правило, можно увести и всю базу, и скорее всего ее можно и грохнуть(про бекапы речь отдельная).
Поэтому в обоих случаях неплохо иметь демон на соседнем серваке, к которому есть доступ только по одному порту, который занимается аутентификацией. На него же можно повесить и контроль количества неверных попыток. В таком случае криптомодуль для злоумышленника будет черным ящиком, и сможет защитить сервер даже в большинстве случаев безалаберности программиста, «изобретшего» очередной кривой алгоритм.
Я это к чему — обычно на сервер с веб-мордой сайта вломиться гораздо проще, чем на отдельно-стоящий демон аутентификации. Если веб-проектов масса, одного такого сервака с демоном достаточно для обслуживания туевой хучи проектов. Вероятно поэтому у автора хеш генерится из составной фразы «keyword+sitename+login».
Кроме того, если вы еще раз посмотрите на код в статье, там есть только функция convert(), которую мы как бы и обсуждаем — упаковка хеша. Как этот хеш изначально получается — дело десятое. Хоть в результате шифрования с открытыми-закрытыми ключами. Главное, чтобы при получении логина очередного желающего войти на сервер юзера, сервер мог автоматом в памяти сгенерить его пароль для сравнения.
То есть фактически я говорю только о паре строк кода, не обсуждая остальное и связанные с ним проблемы — иначе это будет долгий неуникальный разговор, скорее всего к тому же непродуктивный вследствии регулярности подобных разговоров в коментах всех похожих тем )))
И на самом деле я мечтаю, что интернет когда-нибудь перейдёт к нормальной системе с открытым ключом… Эх, мечты…
Системы на базе ключей плохи тем, что нормальный человек запомнить эти ключи не в состоянии и потеряв ключ лишаешься доступа к своим аккаунтам. Я мечтаю о системах аутентификации на базе биометрии.
«Всеобщее образование плохо тем, что нормальные плебеи выучится грамоте не в состоянии, оно им нафиг не нужно, им и так хорошо» — когда-то это было всеобщей нормой (почти идеологией), спасибо дедушке Ленину, что сейчас не так, ну, почти… ;-) Сходства не улавливаете, нет.
Вот скажите, вы все ip-шники всех сервисов и сайтов наизусть помните?! Сколько их приходится на один gmail.com?! Многие хранят пароли во всяких менеджерах паролей, и выучивают один сложный пароль, а не «запоминают» тысячи.
«Биометрия» в приложении к интернету в общем — та же система с открытым ключом первичные данные к которой снимают с датчиков биометрии. Если же вы имеете в виду передачу (или подтверждение третьей стороной) этих данных сервису, то это лишает анонимности (или деперсонификации).
Или это был вброс, а я повёлся?
Вот скажите, вы все ip-шники всех сервисов и сайтов наизусть помните?! Сколько их приходится на один gmail.com?! Многие хранят пароли во всяких менеджерах паролей, и выучивают один сложный пароль, а не «запоминают» тысячи.
«Биометрия» в приложении к интернету в общем — та же система с открытым ключом первичные данные к которой снимают с датчиков биометрии. Если же вы имеете в виду передачу (или подтверждение третьей стороной) этих данных сервису, то это лишает анонимности (или деперсонификации).
Или это был вброс, а я повёлся?
Нет, не улавливаю. Хотите сказать, что лет через дцать все будут помнить свои закрытые ключи бит так в 1024 (256 hex цифр)? Ну, может быть, если иного выхода не будет.
Техническая реализация мне не особо интересна, главное чтобы носителем закрытого «ключа» выступало моё тело, а не что-то что я могу забыть, потерять, сломать и т. п., чтобы доступ к своим аккаунтам мог получить с любого девайса, попавшего в руки даже на 5 минут.
Техническая реализация мне не особо интересна, главное чтобы носителем закрытого «ключа» выступало моё тело, а не что-то что я могу забыть, потерять, сломать и т. п., чтобы доступ к своим аккаунтам мог получить с любого девайса, попавшего в руки даже на 5 минут.
"… лет через дцать все будут помнить свои закрытые ключи бит так в 1024" — не, вы издеваетесь, где и как (кто, когда и где вообще) такое предлагает? И пруфлинк, пожалуйста.
«Техническая реализация мне не особо интересна» — это очень печально. Иначе вам было бы очевидно — ничто не мешает реализовать это прямо сейчас, но «всем пофиг».
«Техническая реализация мне не особо интересна» — это очень печально. Иначе вам было бы очевидно — ничто не мешает реализовать это прямо сейчас, но «всем пофиг».
Это сходство, которое я нашёл между своим «нормальный человек запомнить эти ключи не в состоянии» и вашим «нормальные плебеи выучится грамоте не в состоянии». Пришлось — плебеи выучились грамоте, придётся — будут ключи в 1024 бит запоминать. Я должен был заметить что-то другое?
Как минимум мешает отсутствие биометрических датчиков на подавляющем большинстве пользовательских устройств. Это не техническая (непонятно как сделать) проблема, а экономическая (дорого) и политическая (всем пофиг). Как показывает история технические проблемы активно решаются при наличии заказчика готового (политика) платить (экономика) за принципиально достижимый на данном этапе развития науки и техники результат. Скажем, человек полетел в космос много позже чем появились теоретические обоснования такой возможности и просто позже, чем появились технические возможности. И, вероятно, заказчику (СССР) было всё равно будет полёт обеспечен идеями Циолковского и законами Ньютона или какой-нибудь магией, пускай даже несовместимой с диалектическим материализмом и прочим марксизмом-ленинизмом. Интересовал, я думаю, приоритет и возможность использовать результат в военных целях.
Как минимум мешает отсутствие биометрических датчиков на подавляющем большинстве пользовательских устройств. Это не техническая (непонятно как сделать) проблема, а экономическая (дорого) и политическая (всем пофиг). Как показывает история технические проблемы активно решаются при наличии заказчика готового (политика) платить (экономика) за принципиально достижимый на данном этапе развития науки и техники результат. Скажем, человек полетел в космос много позже чем появились теоретические обоснования такой возможности и просто позже, чем появились технические возможности. И, вероятно, заказчику (СССР) было всё равно будет полёт обеспечен идеями Циолковского и законами Ньютона или какой-нибудь магией, пускай даже несовместимой с диалектическим материализмом и прочим марксизмом-ленинизмом. Интересовал, я думаю, приоритет и возможность использовать результат в военных целях.
В дополнение. Если на разных сервисах использовать один и тот же «ключ» (в виде биометрических данных в частности; логин и пароль в частности), это позволит связать их друг с другом и с вами без вашего ведома. Если же использовать разные ключи на разных сервисах и для разных случаев, то связать их без вашего ведома не удастся.
Если рассматривать общий случай (в частности бывает вообще всё).
Биометрические данные в смысле подтверждения реальной личности нужны в очень редких случаях, я думаю.
Отдельный логин-пароль или ключ надо понимать как надёжный способ удалённо и деперсонифицированно подтвердить статус взаимоотношений. Шифрование, секретность уже частности.
«Девайс» эти биометрические параметры как-то снимает, хранит, передаёт. А значит ничто не мешает их скопировать. А для их удалённого подтверждения необходимо где-то хранить их копию, ведь биометрические параметры должны оставаться постоянными, иначе какой в них смысл. Поэтому биометрия не может выступать как основа криптографии, и всё равно будет нужен случайный, уникальный, криптографически стойкий ключ. Даже если это мастер-ключь — где-то, на каком-то девайсе (только вашем) он быть должен. Иначе вы полностью доверяетесь тому кто сможет контролировать этот «любй девайс». И весь смысл — без вашего ведома ничего сделать нельзя — улетучивается.
Если рассматривать общий случай (в частности бывает вообще всё).
Биометрические данные в смысле подтверждения реальной личности нужны в очень редких случаях, я думаю.
Отдельный логин-пароль или ключ надо понимать как надёжный способ удалённо и деперсонифицированно подтвердить статус взаимоотношений. Шифрование, секретность уже частности.
«Девайс» эти биометрические параметры как-то снимает, хранит, передаёт. А значит ничто не мешает их скопировать. А для их удалённого подтверждения необходимо где-то хранить их копию, ведь биометрические параметры должны оставаться постоянными, иначе какой в них смысл. Поэтому биометрия не может выступать как основа криптографии, и всё равно будет нужен случайный, уникальный, криптографически стойкий ключ. Даже если это мастер-ключь — где-то, на каком-то девайсе (только вашем) он быть должен. Иначе вы полностью доверяетесь тому кто сможет контролировать этот «любй девайс». И весь смысл — без вашего ведома ничего сделать нельзя — улетучивается.
Деперсонификация интересует далеко не всех. А хочу я использовать свои биометрические данные для аутенфикации по двум причинам: они от меня практически неотчуждаемые, а если отчуждить, то возможность доступа к каким-то онлайн-сервисам волновать меня будет меньше всего — основная, вероятность случайного совпадения минимальна — дополнительная.
«Девайс» эти биометрические параметры как-то снимает, хранит, передаёт. А значит ничто не мешает их скопировать.
Если так рассуждать, то любые параметры ничто не помешает скопировать. В частности закрытый ключ хранится, как правило, на диске, пароли перехватываются кейлогерами и т. п.
Иначе вы полностью доверяетесь тому кто сможет контролировать этот «любй девайс».
В общем и в целом без доверия к кому-то никуда. Доверяем производителям девайсов, доверяем производителям ОС и другого софта, доверяем производителям и эксплуататорам каналов связи, доверяем самим сервисам в конце-концов. Не знаю я способа гарантированно (насколько могут давать гарантии теорвер и матстатистика) защитить свои данные от несанкционированного доступа, кроме как самому произвести всю инфраструктуру, предусмотрев все теоретически возможные угрозы. А если данные передаются кому-то для использования, то это невозможно в принципе — нужно доверять тому, кто будет их использовать.
«Девайс» эти биометрические параметры как-то снимает, хранит, передаёт. А значит ничто не мешает их скопировать.
Если так рассуждать, то любые параметры ничто не помешает скопировать. В частности закрытый ключ хранится, как правило, на диске, пароли перехватываются кейлогерами и т. п.
Иначе вы полностью доверяетесь тому кто сможет контролировать этот «любй девайс».
В общем и в целом без доверия к кому-то никуда. Доверяем производителям девайсов, доверяем производителям ОС и другого софта, доверяем производителям и эксплуататорам каналов связи, доверяем самим сервисам в конце-концов. Не знаю я способа гарантированно (насколько могут давать гарантии теорвер и матстатистика) защитить свои данные от несанкционированного доступа, кроме как самому произвести всю инфраструктуру, предусмотрев все теоретически возможные угрозы. А если данные передаются кому-то для использования, то это невозможно в принципе — нужно доверять тому, кто будет их использовать.
>> они от меня практически неотчуждаемые
В том-то и засада — спертый пароль сменить не сложно(если успеть), да и сперт он будет только с одного ресурса.
А вот сменить спертый отпечаток уже немножечко сложнее )
В том-то и засада — спертый пароль сменить не сложно(если успеть), да и сперт он будет только с одного ресурса.
А вот сменить спертый отпечаток уже немножечко сложнее )
Ничто не идеально :( Но для меня важнее, чтобы я всегда получил доступ, чем то, что кто-то другой получит без моего ведома.
Подозреваю, что это все только до тех пор, пока речь не идет о банковских картах, счетах, кредитах, накоплениях, сексе с женой, вещах на работе, напрямую связанных с размером зарплаты и штрафных санкциях, доступом к вашему жилищу и тому подобных )
Я не пользуюсь онлайн-сервисами секса с женой :)
Тогда вычеркните этот пункт)
Остальные остаются. И то, что вы не пользуетесь онлайн-сервисами, вовсе не означает, что ними за вас не воспользуется кто-то другой.
В ресторанах всегда требуете, чтобы снятие с карты происходило при вас? Всегда внимательно смотрите на терминал на кассе или в руках официанта на предмет доустановки накладок-снифферов на щель считывателя?
Ну и т.п. Подтверждение транзакции по СМС в таких случаях спасает, но несет некоторый геморрой, да и редкие банки такое поддерживают. Частично спасает СМС-информирование плюс дневной лимит и лимит на операцию — при любой несанкционированной транзакции можно заблокировать карточку «до выяснения»(опять же -потом гемор с перевыпуском будет).
Это просто пример того, что дополнительный геморрой в любой криптосистеме(то, от чего вы пытаетесь избавиться по вашим словам) как правило будет оправдан.
Остальные остаются. И то, что вы не пользуетесь онлайн-сервисами, вовсе не означает, что ними за вас не воспользуется кто-то другой.
В ресторанах всегда требуете, чтобы снятие с карты происходило при вас? Всегда внимательно смотрите на терминал на кассе или в руках официанта на предмет доустановки накладок-снифферов на щель считывателя?
Ну и т.п. Подтверждение транзакции по СМС в таких случаях спасает, но несет некоторый геморрой, да и редкие банки такое поддерживают. Частично спасает СМС-информирование плюс дневной лимит и лимит на операцию — при любой несанкционированной транзакции можно заблокировать карточку «до выяснения»(опять же -потом гемор с перевыпуском будет).
Это просто пример того, что дополнительный геморрой в любой криптосистеме(то, от чего вы пытаетесь избавиться по вашим словам) как правило будет оправдан.
В таком случае, почему бы не использовать везде один и тот же логин с одним и тем же простейшим паролем, вроде «Password256»? Вы доступ всегда получите (ну врядли же можно забыть такой пароль), ну а то, что кто-то другой получит доступ без Вашего ведома, так оно же для Вас менее важно ;)
Ну не настолько же мои слова утрировать :)
Да нет, мне понятно, что Вы хотите донести.
Просто лично я не вижу особых плюсов в применении биометрии. Ведь все равно надо будет в базе на сайтах хранить какой-то хэш от комбинации параметров, считанных биометрическим датчиком. И все равно ведь найдется какой-нибудь сайт, который решит все Ваши биометрические параметры сохранить в открытом виде. И найдется тот, кто эту базу украдет, и тогда все Ваши аккаунты на всех сайтах окажутся под угрозой. И изменить-то свои биометрические параметры Вы не сможете, вот ведь какое дело.
К тому же, одно дело доверить малоизвестному сайту одноразовый пароль и адрес электронной почты, который далеко не всегда можно ассоциировать с конкретным человеком, и совсем другое дело доверять куче неизвестных сайтов свои биометрические данные, которые у меня всегда одинаковые и однозначно связаны с моей личностью.
Еще вариант. Допустим, надо мне дать доступ к своей почте (любому другому сайту) кому-нибудь еще. Например, уехал я в отпуск, Интернета нету, звонят коллеги, говорят, что нужен им срочно какой-нибудь файл, который когда-то кто-то прислал. Сейчас я продиктовал логин/пароль — и все отлично, если не доверяю — перезвонил жене, продиктовал ей логин/пароль, попросил отослать файл. А если там снимок моей сетчатки нужен будет?
А уж если мне нужно не просто авторизоваться где-нибудь, а надежно ото всех что-то там спрятать, то биометрия вообще вредна! В случае с паролем чаще всего только термориктальный криптоанализ поможет неким товарищам получить доступ к информации, и то можно упирать на то, что аккаунт не мой, никакого пароля не знаю, или давно знал, но забыл, ну и т.д. А если там будет биометрия, то придется либо глаз выколоть, либо отпечатки пальцев посжигать, что, согласитесь, куда менее приятно.
В общем, ни одного плюса от применения биометрии я не вижу.
Просто лично я не вижу особых плюсов в применении биометрии. Ведь все равно надо будет в базе на сайтах хранить какой-то хэш от комбинации параметров, считанных биометрическим датчиком. И все равно ведь найдется какой-нибудь сайт, который решит все Ваши биометрические параметры сохранить в открытом виде. И найдется тот, кто эту базу украдет, и тогда все Ваши аккаунты на всех сайтах окажутся под угрозой. И изменить-то свои биометрические параметры Вы не сможете, вот ведь какое дело.
К тому же, одно дело доверить малоизвестному сайту одноразовый пароль и адрес электронной почты, который далеко не всегда можно ассоциировать с конкретным человеком, и совсем другое дело доверять куче неизвестных сайтов свои биометрические данные, которые у меня всегда одинаковые и однозначно связаны с моей личностью.
Еще вариант. Допустим, надо мне дать доступ к своей почте (любому другому сайту) кому-нибудь еще. Например, уехал я в отпуск, Интернета нету, звонят коллеги, говорят, что нужен им срочно какой-нибудь файл, который когда-то кто-то прислал. Сейчас я продиктовал логин/пароль — и все отлично, если не доверяю — перезвонил жене, продиктовал ей логин/пароль, попросил отослать файл. А если там снимок моей сетчатки нужен будет?
А уж если мне нужно не просто авторизоваться где-нибудь, а надежно ото всех что-то там спрятать, то биометрия вообще вредна! В случае с паролем чаще всего только термориктальный криптоанализ поможет неким товарищам получить доступ к информации, и то можно упирать на то, что аккаунт не мой, никакого пароля не знаю, или давно знал, но забыл, ну и т.д. А если там будет биометрия, то придется либо глаз выколоть, либо отпечатки пальцев посжигать, что, согласитесь, куда менее приятно.
В общем, ни одного плюса от применения биометрии я не вижу.
Проблема малоизвестных дырявых сайтов решается с помощью сторонних сервисов аутентификации. Вот я сейчас стараюсь один из трёх использовать google, fb или vk. Если кто-то из них прикрутит биометрию и девайсы с датчиками без очевидных уязвимостей будут распространены, то с радостью перейду. Проблема деанонимизации меня вообще не интересует.
Вы не видите, я вижу. И у других схем вижу минусы. Идеала нет :( Может на квантовом уровне что-то придумается, может ИИ какой будет.
Вы не видите, я вижу. И у других схем вижу минусы. Идеала нет :( Может на квантовом уровне что-то придумается, может ИИ какой будет.
Вы похоже отвечаете не на мой комментарий, а на какой-то другой.
«возможность доступа к каким-то онлайн-сервисам волновать меня будет меньше всего» — А нафига вам тогда вообще нужна аутенфикация, если вы будете присутствовать лично? Проверка по фотографии в паспорте тоже «биометрия». Можно развить её до более совершенного вида, но это уже абсолютно другое и к теме отношения не имеет никакого.
«вероятность случайного совпадения минимальна» — При использовании ключей вероятность совпадения вообще ничтожная.
(Скажем для примера: онлайн-голосование на выборах, быстрые и удобные банковские переводы — тоже интересные темы)
«они от меня практически неотчуждаемые» — При удалённом использовании, без личного присутствия они именно что абсолютно отчуждаемые. От вашего имени будут «грабить и насиловать».
«Деперсонификация интересует далеко не всех» — Но при использовании удалённых сервисов (абсолютно любых) присутствует по факту. И то что эти данные принадлежат именно вам, должна будет подтверждать третья сторона (производитель устройства, владелец устройства, те кто обслуживает эти устройства, провайдеры!, какой-нибудь центральный репозиторий и т.д.), иначе где гарантия что они не сфабрикованы, не испорчены (например плохим девайсом), не эмитируются, и т.п. Где гарантия что кто-то не вклинился в процесс и не управляет им без вашего ведома, и без ведома конечного сервиса разумеется. Ответ — наука криптография. Современный ответ криптографии — системы с открытым ключом.
«Если так рассуждать, то любые параметры ничто не помешает скопировать. В частности закрытый ключ хранится, как правило, на диске, пароли перехватываются кейлогерами и т. п.» — Эту проблему и пытается решить криптография, вообще-то, на всём пути своего существования. Единственное простое решение, ставшее доступным по глобальным меркам совсем недавно, личное устройство шифрования (всякие е-токины и т.п.). А если в место ФИО в открытом виде будет передаваться длина члена, ничего по большому счёту не изменится, за исключением уникальности.
«Доверяем ...» — Вы абсолютизируете доверие совершенно не по теме.
Можно никому не доверять и прекрасно жить без проблем — одно с другим напрямую не связано. «Все девайсы» проходят проверку в том или ином виде. И не только на предмет качества, но и на предмет того что делают только заявленное в спецификации — ничего более и ничего менее того. Тоже относится к ОС и софту, но часто в меньшей степени. Доверяем производителям и эксплуататорам каналов связи в том же ключе — соответствие заявленным спецификациям — гарантированная до некоторой степени передача данных (в важных случаях зашифрованных и им недоступных).
«доверяем самим сервисам» — А это уже ваша личная (но всё же в важных случаях, конечно, и общественная) проблема до какой степени вы доверяете конкретному сервису, какой уровень доверия требует конкретный сервис. Ведь почтовик не требует от вас вашу медицинскую историю.
Я сторонник минимальной связанности: без моего ведома связать данные от разных сервисов невозможно или максимально затруднено, без моего ведома воспользоваться сервисом от моего имени невозможно или максимально затруднено.
«возможность доступа к каким-то онлайн-сервисам волновать меня будет меньше всего» — А нафига вам тогда вообще нужна аутенфикация, если вы будете присутствовать лично? Проверка по фотографии в паспорте тоже «биометрия». Можно развить её до более совершенного вида, но это уже абсолютно другое и к теме отношения не имеет никакого.
«вероятность случайного совпадения минимальна» — При использовании ключей вероятность совпадения вообще ничтожная.
(Скажем для примера: онлайн-голосование на выборах, быстрые и удобные банковские переводы — тоже интересные темы)
«они от меня практически неотчуждаемые» — При удалённом использовании, без личного присутствия они именно что абсолютно отчуждаемые. От вашего имени будут «грабить и насиловать».
«Деперсонификация интересует далеко не всех» — Но при использовании удалённых сервисов (абсолютно любых) присутствует по факту. И то что эти данные принадлежат именно вам, должна будет подтверждать третья сторона (производитель устройства, владелец устройства, те кто обслуживает эти устройства, провайдеры!, какой-нибудь центральный репозиторий и т.д.), иначе где гарантия что они не сфабрикованы, не испорчены (например плохим девайсом), не эмитируются, и т.п. Где гарантия что кто-то не вклинился в процесс и не управляет им без вашего ведома, и без ведома конечного сервиса разумеется. Ответ — наука криптография. Современный ответ криптографии — системы с открытым ключом.
«Если так рассуждать, то любые параметры ничто не помешает скопировать. В частности закрытый ключ хранится, как правило, на диске, пароли перехватываются кейлогерами и т. п.» — Эту проблему и пытается решить криптография, вообще-то, на всём пути своего существования. Единственное простое решение, ставшее доступным по глобальным меркам совсем недавно, личное устройство шифрования (всякие е-токины и т.п.). А если в место ФИО в открытом виде будет передаваться длина члена, ничего по большому счёту не изменится, за исключением уникальности.
«Доверяем ...» — Вы абсолютизируете доверие совершенно не по теме.
Можно никому не доверять и прекрасно жить без проблем — одно с другим напрямую не связано. «Все девайсы» проходят проверку в том или ином виде. И не только на предмет качества, но и на предмет того что делают только заявленное в спецификации — ничего более и ничего менее того. Тоже относится к ОС и софту, но часто в меньшей степени. Доверяем производителям и эксплуататорам каналов связи в том же ключе — соответствие заявленным спецификациям — гарантированная до некоторой степени передача данных (в важных случаях зашифрованных и им недоступных).
«доверяем самим сервисам» — А это уже ваша личная (но всё же в важных случаях, конечно, и общественная) проблема до какой степени вы доверяете конкретному сервису, какой уровень доверия требует конкретный сервис. Ведь почтовик не требует от вас вашу медицинскую историю.
Я сторонник минимальной связанности: без моего ведома связать данные от разных сервисов невозможно или максимально затруднено, без моего ведома воспользоваться сервисом от моего имени невозможно или максимально затруднено.
А нафига вам тогда вообще нужна аутенфикация, если вы будете присутствовать лично?
Я имел в виду ситуацию когда мне руку отрежут или глаз вынут.
При удалённом использовании, без личного присутствия они именно что абсолютно отчуждаемые. От вашего имени будут «грабить и насиловать».
Под отчуждением я имел в виду перенос, а не копирование.
Современный ответ криптографии — системы с открытым ключом.
Я разве против криптографии? Пускай будет закрытый ключ, но генерируемый на базе отпечатка пальца или ДНК. Пускай наружу из криптоустройства никогда не выходит, чтоб обычная среда могла только подать открытый текст на вход и получить закрытый и/или хэш (подпись) с открытым ключом. «Всего-то» нужен или алгоритм однозначной генерациипростых чисел пар ключей на базе вариативной биометрической информации, или закрытый канал связи с онлайн-сервисом, выдающим закрытые ключи по биометрикам.
Единственное простое решение, ставшее доступным по глобальным меркам совсем недавно, личное устройство шифрования (всякие е-токины и т.п.)
Не взял, потерял, сломалось, украли и ты остался без доступа к своим аккаунтам. Это системный недостаток всех известных мне систем аутентификации, основанных на необходимости доступа к какому-то физическому носителю (от листа бумаги до диска в облаке, включая локальные диски, флэшки, телефоны, токены и т. п.). Из массово используемых лишена его только банальная пара логин/пароль — она всегда с собой. Она не лишена других недостатков, но этого лишена.
Можно никому не доверять и прекрасно жить без проблем
Сложно в современном мире жить без денег, а прекрасно без них жить ещё сложнее. А жить с деньгами значит доверять их эмитенту.
А это уже ваша личная… проблема до какой степени вы доверяете конкретному сервису, какой уровень доверия требует конкретный сервис. Ведь почтовик не требует от вас вашу медицинскую историю.
Хотелось бы иметь на выбор несколько сервисов аутентификации, которым я мог бы доверить всю свою электронную информацию. В принципе сейчас они у меня есть — google, facebook, vk. Не выбран один из них лишь потому что разные сервисы используют разных провайдеров. У каких-то нет google (мой основной), у каких-то fb, у каких-то только vk. С частью приходится мучаться с паролями. Кстати, у Google есть вся моя медицинская история, которую я смог получить на руки. Ни в одном медучреждении более полной нет. Утрачена в «лихих 90-х» та, что велась с детства.
Я сторонник минимальной связанности: без моего ведома связать данные от разных сервисов невозможно или максимально затруднено,
Я сам их связываю, не далее как вчера вбил в Yandex все соцсети, что у меня есть.
без моего ведома воспользоваться сервисом от моего имени невозможно или максимально затруднено.
Повторюсь, для меня важнее чтобы я мог всегда воспользоваться.
Я имел в виду ситуацию когда мне руку отрежут или глаз вынут.
При удалённом использовании, без личного присутствия они именно что абсолютно отчуждаемые. От вашего имени будут «грабить и насиловать».
Под отчуждением я имел в виду перенос, а не копирование.
Современный ответ криптографии — системы с открытым ключом.
Я разве против криптографии? Пускай будет закрытый ключ, но генерируемый на базе отпечатка пальца или ДНК. Пускай наружу из криптоустройства никогда не выходит, чтоб обычная среда могла только подать открытый текст на вход и получить закрытый и/или хэш (подпись) с открытым ключом. «Всего-то» нужен или алгоритм однозначной генерации
Единственное простое решение, ставшее доступным по глобальным меркам совсем недавно, личное устройство шифрования (всякие е-токины и т.п.)
Не взял, потерял, сломалось, украли и ты остался без доступа к своим аккаунтам. Это системный недостаток всех известных мне систем аутентификации, основанных на необходимости доступа к какому-то физическому носителю (от листа бумаги до диска в облаке, включая локальные диски, флэшки, телефоны, токены и т. п.). Из массово используемых лишена его только банальная пара логин/пароль — она всегда с собой. Она не лишена других недостатков, но этого лишена.
Можно никому не доверять и прекрасно жить без проблем
Сложно в современном мире жить без денег, а прекрасно без них жить ещё сложнее. А жить с деньгами значит доверять их эмитенту.
А это уже ваша личная… проблема до какой степени вы доверяете конкретному сервису, какой уровень доверия требует конкретный сервис. Ведь почтовик не требует от вас вашу медицинскую историю.
Хотелось бы иметь на выбор несколько сервисов аутентификации, которым я мог бы доверить всю свою электронную информацию. В принципе сейчас они у меня есть — google, facebook, vk. Не выбран один из них лишь потому что разные сервисы используют разных провайдеров. У каких-то нет google (мой основной), у каких-то fb, у каких-то только vk. С частью приходится мучаться с паролями. Кстати, у Google есть вся моя медицинская история, которую я смог получить на руки. Ни в одном медучреждении более полной нет. Утрачена в «лихих 90-х» та, что велась с детства.
Я сторонник минимальной связанности: без моего ведома связать данные от разных сервисов невозможно или максимально затруднено,
Я сам их связываю, не далее как вчера вбил в Yandex все соцсети, что у меня есть.
без моего ведома воспользоваться сервисом от моего имени невозможно или максимально затруднено.
Повторюсь, для меня важнее чтобы я мог всегда воспользоваться.
«руку отрежут или глаз вынут… перенос...» — Это уже оффлайн, здесь только классика работает, или я чего-то не понял.
«генерируемый на базе отпечатка пальца или ДНК» (и далее)- ну. Это возможно, но облегчает взлом. Стойкость ключей обеспечивается в том числе и некоторой случайностью, но это можно опустить. Однозначный съём биометрических данных это проблема. Одни данные при желании не очень сложно подделать, а другие непостоянны. А если вы и вам и так доверяют, то можно и на слово положится: «бармен — запиши на мой счет».
«Не взял, потерял, сломалось, украли и ты остался без доступа к своим аккаунтам» — Это уже классика: дубликаты, бэкапы, «трусы/ботинки одеть не забываем», устройство можно прицепить к телу, и т.д. И главное это уровень доверия. В одном месте можно обойтись добрым словом, в другом скажем отпечатком пальца, а в ином без е-токена слишком рискованно (мошенники не дремлют :) ).
«Yandex и соцсети» — это всё же немного не тот уровень, и вы сами их связываете. Вот есть у меня логин и пароль от онлайн-банка, и плюс к ним приходят эсемески, неудобно.
«Сложно в современном мире жить без денег, а прекрасно без них жить ещё сложнее. А жить с деньгами значит доверять их эмитенту.» — Ну что же вы так?! Ну, кто верит, например, сша: напечатают, не напечатают, куда сунут напечатанное. По сути когда они эмитируют (в особенности сейчас при спаде экономики), они обесценивают деньги и всё их производные. Т.е. воруют у вас или заставляют принудительно платить налоги в бюджет сша. Капиталы можно держать и не в денежной форме. И как это у вас эта тема денег связалась с тем, что я писал о доверии, о том виде доверия?
«всю свою электронную информацию» — Вот, а я думаю что не всю, а только минимум необходимый для дела. Но это уже «на вкус и цвет».
«наружу из криптоустройства никогда не выходит» (и далее) — Я думаю что в этом основная проблема. Слишком сложные схемы получаются. Слишком многим неизвестным (вам) организациям (обобщенно, в мировом масштабе) придётся доверять абсолютно всё. Вы же не хотите сами владеть криптоустройством и т.п. Многих это не устраивает. В таком случае нужно как это сейчас модно стало «широкое общественное движение», в смысле новой технологической волны, как было с персоналками и интернетом.
И не исключаем: игровой момент, паранойю, мошенников, всякие «службы» и «мафии» — это такая весёлая игра ;-)
«генерируемый на базе отпечатка пальца или ДНК» (и далее)- ну. Это возможно, но облегчает взлом. Стойкость ключей обеспечивается в том числе и некоторой случайностью, но это можно опустить. Однозначный съём биометрических данных это проблема. Одни данные при желании не очень сложно подделать, а другие непостоянны. А если вы и вам и так доверяют, то можно и на слово положится: «бармен — запиши на мой счет».
«Не взял, потерял, сломалось, украли и ты остался без доступа к своим аккаунтам» — Это уже классика: дубликаты, бэкапы, «трусы/ботинки одеть не забываем», устройство можно прицепить к телу, и т.д. И главное это уровень доверия. В одном месте можно обойтись добрым словом, в другом скажем отпечатком пальца, а в ином без е-токена слишком рискованно (мошенники не дремлют :) ).
«Yandex и соцсети» — это всё же немного не тот уровень, и вы сами их связываете. Вот есть у меня логин и пароль от онлайн-банка, и плюс к ним приходят эсемески, неудобно.
«Сложно в современном мире жить без денег, а прекрасно без них жить ещё сложнее. А жить с деньгами значит доверять их эмитенту.» — Ну что же вы так?! Ну, кто верит, например, сша: напечатают, не напечатают, куда сунут напечатанное. По сути когда они эмитируют (в особенности сейчас при спаде экономики), они обесценивают деньги и всё их производные. Т.е. воруют у вас или заставляют принудительно платить налоги в бюджет сша. Капиталы можно держать и не в денежной форме. И как это у вас эта тема денег связалась с тем, что я писал о доверии, о том виде доверия?
«всю свою электронную информацию» — Вот, а я думаю что не всю, а только минимум необходимый для дела. Но это уже «на вкус и цвет».
«наружу из криптоустройства никогда не выходит» (и далее) — Я думаю что в этом основная проблема. Слишком сложные схемы получаются. Слишком многим неизвестным (вам) организациям (обобщенно, в мировом масштабе) придётся доверять абсолютно всё. Вы же не хотите сами владеть криптоустройством и т.п. Многих это не устраивает. В таком случае нужно как это сейчас модно стало «широкое общественное движение», в смысле новой технологической волны, как было с персоналками и интернетом.
И не исключаем: игровой момент, паранойю, мошенников, всякие «службы» и «мафии» — это такая весёлая игра ;-)
Это уже оффлайн, здесь только классика работает, или я чего-то не понял.
Возьмём токен или просто флэшку/телефон с сертификатом. Я могу утратить к ней доступ по разным причинам: потерял, забыл на работе/дома, украли, сломалось и т. п. Результат один: я не получаю доступа к сервису и, в некоторых случаях, его получает кто-то другой. С биометрией я могу утратить возможность доступа только при серьёзной травме, когда мне, скорее всего, не до онлайн-сервисов будет. Ну и редкий злоумышленник пойдёт на такие меры.
«бармен — запиши на мой счет»
Это биометрия, пускай и не формализованная :)
Это уже классика: дубликаты, бэкапы, «трусы/ботинки одеть не забываем», устройство можно прицепить к телу, и т.д.
Чем защищаем дубликаты и бэкапы? Другим сертификатом? Замкнутый круг. Паролем? Вроде же от него хотим отказаться.
И как это у вас эта тема денег связалась с тем, что я писал о доверии, о том виде доверия?
Что сложно жить в современно мире никому не доверяя. Скажем я доверяю все свои доходы, накопления, пенсию и т. п. Правительству России, ЦБ, ПФ и т. д., в общем государству. Почему бы не доверить государству и, например, мою аутентификацию перед третьими лицами?
Возьмём токен или просто флэшку/телефон с сертификатом. Я могу утратить к ней доступ по разным причинам: потерял, забыл на работе/дома, украли, сломалось и т. п. Результат один: я не получаю доступа к сервису и, в некоторых случаях, его получает кто-то другой. С биометрией я могу утратить возможность доступа только при серьёзной травме, когда мне, скорее всего, не до онлайн-сервисов будет. Ну и редкий злоумышленник пойдёт на такие меры.
«бармен — запиши на мой счет»
Это биометрия, пускай и не формализованная :)
Это уже классика: дубликаты, бэкапы, «трусы/ботинки одеть не забываем», устройство можно прицепить к телу, и т.д.
Чем защищаем дубликаты и бэкапы? Другим сертификатом? Замкнутый круг. Паролем? Вроде же от него хотим отказаться.
И как это у вас эта тема денег связалась с тем, что я писал о доверии, о том виде доверия?
Что сложно жить в современно мире никому не доверяя. Скажем я доверяю все свои доходы, накопления, пенсию и т. п. Правительству России, ЦБ, ПФ и т. д., в общем государству. Почему бы не доверить государству и, например, мою аутентификацию перед третьими лицами?
«редкий злоумышленник пойдёт на такие меры» — Вопрос компромисса. Одного раза достаточно, при этом это не обязательно должны быть вы. Дважды лбом пулю не ловят.
Да, так можно. Но ведь от третьих лиц и пытаются избавится, точнее ограничить и контролировать их возможности, если без них никак. Аутентификация, шифрование, криптография как наука и т.д. — это как раз способы устранить или контролировать «третьи лица».
Значит у каждого сервиса (ну если не онлайн, то ресторана скажем) должно быть сертифицированное, защищённое «государством» устройство съема и передачи данных — сплошной геморой и убытки. Т.е. всё остаётся по прежнему, но всё «неудобство» берёт на себя сервис и повышает цены. А если онлайн, то где, у кого будет это устройство, и кто за него заплатит?
Разработка надёжных, однозначных, дешевых, удобных, доступных биометрических систем не менее сложно, чем разработка системы сотовой связи. Идеи появились в 50-70-ых в союзе, а были приемлемо реализованы только к середине 90-ых как говорится мировым сообществом.
В крайнем случае можно доверить некоему репозиторию хранение копии ваших данных (аналогично банку). Но мне этот вариант просто не нравится — слишком большое у него будет влияние, либо слишком много сил и средств на его контроль нужно будет тратить.
Невозможно перескакивать через этапы. Чтобы повсеместно ввести «биометрию» (как это показывают в фантастических фильмах и книгах), нужно в начале ввести «криптографию», а потом на её основе «биометрию».
А пока нет доступной «биометрию» будет вот это: Кольцо с RFID для проезда в лондонской подземке .
Да, так можно. Но ведь от третьих лиц и пытаются избавится, точнее ограничить и контролировать их возможности, если без них никак. Аутентификация, шифрование, криптография как наука и т.д. — это как раз способы устранить или контролировать «третьи лица».
Значит у каждого сервиса (ну если не онлайн, то ресторана скажем) должно быть сертифицированное, защищённое «государством» устройство съема и передачи данных — сплошной геморой и убытки. Т.е. всё остаётся по прежнему, но всё «неудобство» берёт на себя сервис и повышает цены. А если онлайн, то где, у кого будет это устройство, и кто за него заплатит?
Разработка надёжных, однозначных, дешевых, удобных, доступных биометрических систем не менее сложно, чем разработка системы сотовой связи. Идеи появились в 50-70-ых в союзе, а были приемлемо реализованы только к середине 90-ых как говорится мировым сообществом.
В крайнем случае можно доверить некоему репозиторию хранение копии ваших данных (аналогично банку). Но мне этот вариант просто не нравится — слишком большое у него будет влияние, либо слишком много сил и средств на его контроль нужно будет тратить.
Невозможно перескакивать через этапы. Чтобы повсеместно ввести «биометрию» (как это показывают в фантастических фильмах и книгах), нужно в начале ввести «криптографию», а потом на её основе «биометрию».
А пока нет доступной «биометрию» будет вот это: Кольцо с RFID для проезда в лондонской подземке .
Моя статья о подобном подходе к хранению паролей, написанная почти год назад. habrahabr.ru/post/125989/
Изначально алгоритм и идея были не мои. Но я попытался развить тему, сделав онлайн-сервис и приложения для телефонов (J2ME и Android).
Изначально алгоритм и идея были не мои. Но я попытался развить тему, сделав онлайн-сервис и приложения для телефонов (J2ME и Android).
Тоже имел проблемы с паролями. Потом узнал о такой програмке как KeePass, который в сочетании с DropBox покрыл абсолютно все мои потребности.
Вот, сначало пишут в коментах к одному посту «100 тышь тупых юзеров использовали дефолтный пароль, вот болваны» я это про эту статью (что-то на подобии). А потом в таких статьях как эта уже пишут- Это не идеальный способ, трололо, таких статей уже 3 было… 3 это МАЛО… всё равно пока-что у большинства пользователей один-два слабых универсальных пароля. Так-что чем больше таких статей — тем лучше.
результатом хэш-функции является строка чисел в шестнадцатеричном представленииЧтоб исправлять какие-то недостатки, нужно хоть немного разбираться в теме. Результатом хэш-функции является не «строка», а хэш-сумма. На входе у хэш-функции байты и на выходе у неё тоже байты. Ни с какими строками хэш-функции не работают. Вы хоть бы в код своей библиотеки заглянули.
Я попытался исправить этот недостаток.
В итоге получился типичный быдлокод: посчитали хэш-сумму, преобразовали её в строку, потом строку обратно преобразовали в исходное значение. Бессмысленно гоняем данные туда-сюда из одного представления в другое, ещё и с умным видом описываем алгоритм этой вакханалии.
НЛО прилетело и опубликовало эту надпись здесь
Так, а если пароль вдруг надо поменять на другой?
НЛО прилетело и опубликовало эту надпись здесь
Тогда нужно просто сменить логин(не везде это приемлемо). В статье в минусах проблема смены пароля указана.
Это не минус, а полный провал всей идеи. Тут либо полная универсальность, либо картинка про стандарты.
Простите, какой именно идеи это провал? Идеи генерить приложенной программой пароли себе самому или идеи использовать этот алгоритм на конкретном сервере для генерации паролей пользователям принудительно?
В первом случае вам vk2 ответил, как можно самому себе разнообразить пароли, введя дополнительную известную «соль» в исходные данные.
Во втором случае можно привязывать генерацию пароля не к логину, а к чему-то еще, что можно для пользователя поменять безболезненно. Например в кортеже(строке БД) пользователя в таблице пользователей можно добавить поле salt с рандомной строкой, и в алгоритме исходной строкой использовать не «keyword+sitename+login», а «keyword+sitename+login+salt». В случае надобности генерим юзеру новую «соль» и его пароль меняется автоматически, а старый уже не действует.
В первом случае вам vk2 ответил, как можно самому себе разнообразить пароли, введя дополнительную известную «соль» в исходные данные.
Во втором случае можно привязывать генерацию пароля не к логину, а к чему-то еще, что можно для пользователя поменять безболезненно. Например в кортеже(строке БД) пользователя в таблице пользователей можно добавить поле salt с рандомной строкой, и в алгоритме исходной строкой использовать не «keyword+sitename+login», а «keyword+sitename+login+salt». В случае надобности генерим юзеру новую «соль» и его пароль меняется автоматически, а старый уже не действует.
С чего вы вообще взяли, что идея заключается в генерации? Все предельно четко указано в заголовке: «хранение паролей без их сохранения». Вот эта идея и терпит крах, т.к. любое ваше предложение исправить этот минус заключается в сохранении чего-либо куда-либо.
Ну так ясен пень — keyword-то нужно где-то хранить как минимум. Хоть в ресурсах/исходниках самой программы.
А вам так принципиально воспринимать заголовок буквально?
Если даже взять общий «принцип узнавания» и научить сервер задавать вам задачки, которые сможете именно так решить только вы, ему(серверу) все-равно что-то придется у себя хранить — условия задачек, список вопросов и т.п. Тут придираться можно бесконечно )
А вам так принципиально воспринимать заголовок буквально?
Если даже взять общий «принцип узнавания» и научить сервер задавать вам задачки, которые сможете именно так решить только вы, ему(серверу) все-равно что-то придется у себя хранить — условия задачек, список вопросов и т.п. Тут придираться можно бесконечно )
Keyword-то автор как раз и предполагает вводить вместе с названием сайта и логином, т.е. не хранить его ни в исходниках, ни в ресурсах. И если этот мастер-пароль еще можно запомнить, то какой там по порядку пароль к любимому сайтику нужен, 1й или уже 20й, никто в здравом уме не будет. Именно поэтому я и говорю, что идея провальна, а вы всячески пытаетесь велосипед костылями подпереть. Ну вот никак она не подойдет для хранения паролей к сайтам.
Я уже писал в этом комменте, что приведенная в конце статьи программа — это просто демо. Она позволяет при желании генерировать пароли самому себе для личных целей. И именно для использования демо и предлагалось вводить и keyword, и sitename и login ручками. Если вам это не подходит — не используйте. Это демо-программа построена по алгоритму, а не алгоритм для этой демо-программы.
Автор нигде не кричал о том, что он гуру и что его решение суперсекюрно и суперправильно. У него есть только один принципиальный и важный косяк, который выше в комметах уже обсудили, минусов автору накидали, у него есть веский стимул в себе разобраться — и ладушки.
И ваши придирки к словам «без их сохранения» зависят исключительно от вашего личного их восприятия и вашей же личной принципиальности. А так-то конечно вы правы — без сохранения какой-либо информации такое сделать не получится. Цель статьи была явно не в этом и заголовок не несет буквального смысла.
Автор нигде не кричал о том, что он гуру и что его решение суперсекюрно и суперправильно. У него есть только один принципиальный и важный косяк, который выше в комметах уже обсудили, минусов автору накидали, у него есть веский стимул в себе разобраться — и ладушки.
И ваши придирки к словам «без их сохранения» зависят исключительно от вашего личного их восприятия и вашей же личной принципиальности. А так-то конечно вы правы — без сохранения какой-либо информации такое сделать не получится. Цель статьи была явно не в этом и заголовок не несет буквального смысла.
НЛО прилетело и опубликовало эту надпись здесь
Да хз почему я его защищаю. Он мне не брат, не сват и я его не знаю.
Скорее мне не нравится, когда на начинающих перебарщивают с критикой и пинками, вместо того, чтобы дать кнута за ошибки и приободрить пряником на саморазвитие.
Когда одни только кнуты, обычно это убивает мотивацию развиваться наглухо.
А когда кнутов неоправданно много(а я считаю, что в этом посте именно так), то это со стороны похоже на стаю гиен, цинично загрызающую молодую зебру, или как-то так. В общем, не смотря на обычную природную пищеварительную цепочку, морально некий мерзко выглядящий элемент присутствует.
Ну и еще некоторые претензии к автору малость притянуты за уши. Это часто бывает, когда сообщество само за тебя додумает выводы, которых ты не делал, потом тебя же в этом обвинят и в грязь втопчут.
Это мое видение происходящего, если что, я никому его не навязываю. Вы спросили — я ответил )
Скорее мне не нравится, когда на начинающих перебарщивают с критикой и пинками, вместо того, чтобы дать кнута за ошибки и приободрить пряником на саморазвитие.
Когда одни только кнуты, обычно это убивает мотивацию развиваться наглухо.
А когда кнутов неоправданно много(а я считаю, что в этом посте именно так), то это со стороны похоже на стаю гиен, цинично загрызающую молодую зебру, или как-то так. В общем, не смотря на обычную природную пищеварительную цепочку, морально некий мерзко выглядящий элемент присутствует.
Ну и еще некоторые претензии к автору малость притянуты за уши. Это часто бывает, когда сообщество само за тебя додумает выводы, которых ты не делал, потом тебя же в этом обвинят и в грязь втопчут.
Это мое видение происходящего, если что, я никому его не навязываю. Вы спросили — я ответил )
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Хранение паролей без их сохранения