Комментарии 93
Что-то не понял - это примерно те же ключи, что в ssh, только для домохозяек?
И под контролем владельца вашего устройства - "потеряй ещё легче" :-)
Кроме того, есть среды, в которых использование Passkey пока просто не уместно. Если вы работаете на устройстве, где нет облачного резервного копирования или синхронизации ключей, например, на старом смартфоне или общественном компьютере, эффективное использование ключей может быть затруднено или вовсе невозможно.
Но при этом резервирование/синхронизация увеличивают поверхность атаки. И если обычный пароль можно держать в одном месте (в голове), то с продвинутыми ключами без этого никак. Скажем, github недавно настойчиво попросил перейти на TOTP - ok, теперь у меня в куче мест забекаплены секретный ключ и коды восстановления.
Я тоже так понял, что устройство потеряешь и хана...
Это так в случае базового FIDO, на основе которого сделан стандарт passkey, но неверно в случае passkey
Можно при регистрации выдавать уникальный код по которому можно восстановить доступ и ещё уникальный код, чтобы доставить второе устройство. Как раз не так давно разбирался как оно работает. Можете вот тут демку глянуть https://webauthn-omed.hplar.ch/#/login
В целом суть этих ключей это сгенерировать пару ключей и дальше обменивать их на обычные jwt токены
Спасибо за наводку. Обязательно посмотрю. Рано или поздно жизнь заставит пользоваться. Против прогресса не попрёшь.
Можно при регистрации выдавать уникальный код по которому можно восстановить доступ и ещё уникальный код, чтобы доставить второе устройство.
Это почти ничем не отличается от того, чтобы просто иметь второй Passkeys на другом устройстве. Потому что нормальный код все равно запомнить нельзя. Ну да, можно записать, но все равно так себе получается - народ забывает и теряет.
А народ тут протестует против требования иметь копию/резерв.
типа того, только там еще навертели всяких механизмов для того чтобы логиниться с другого устройства, api чтобы генерировать ключи, настаивают чтобы это все обязательно хранилось в какой-нибудь специальной железке типа TPM, и черт знает что еще.
Все это жуткий оверинжиниринг и NIH. Ровно то же самое можно сделать с помощью инфраструктуры открытых ключей gpg, ssh или X509 - это все давно проверенные надежные технологии, которые используются с начала времен. X509 используется в TLS, то есть по определению есть вообще везде. Но продвижение подобных технологий, которые может реализовать и использовать кто угодно, не несет бизнес-велью корпорациям.
Кстати у нас passkeys поддерживаются яндексом и частично сбером. А еще их можно сохранять в базе KeePassXC.
настаивают чтобы это все обязательно хранилось в какой-нибудь специальной железке типа TPM
Ну, это понятно почему. И в общем, правильно. Вот только оно было еще в эру смарт-карт и 'почему-то' не взлетело. У меня <надеваем шапочку из фольги>вообще есть подозрение что тут где-то есть противодействие организаций, которые не хотят нормальной массовой аутентификации</снимаем шапочку>
X509
Вот почему они работу с клиентскими сертификатами не доделали(все равно же поддержку в браузеры нужно было добавлять), а придумали все это - мне очень хочется почитать.
А что там недоделано? Немного через *опу, но работает. Мы все ресурсы для внутреннего применения перевели на клиентский сертификаты, WAF сразу успокоился, меньше стал истерить. Там единственная проблема была, что PEM сертификаты не принимаются, надо в .p12, и под линуксом ставить надо в системное хранилище, а не в хром-браузер. (в случае с Firefox, можно в браузер, у FF свое хранилище).
А что там недоделано?
Нельзя разлогинится. После того, как сертификат выбрал - он так и используется для соединения с сервисом, пока весь браузер не закроешь.
Нет той самой синхронизации между устройствами.
Механизм добавления нового клиентского сертификата в хранилище по запросу сервиса (это нужно для механизма регистрации) - ну очень многоступенчатый.
Нет механизма генерации Certificate Request (для той же регистрации). Когда-то в некоторых браузерах был - но его выкинули.
Совместимость в смысле аппаратных токенов - ну так себе.
Это неправильное понимание. Где вы собираетесь хранить private key ( секретный ключ)?. В local storage browser? Это, мягко говоря, не здорово.
Никакого овеинжениринга здесь нет. И есть разделение обязанностей. Браузеру пофиг как именно хранятся ключи в конкретной железке
В принципе, никакого железного решения не требуется, насколько я помню.
Где вы собираетесь хранить private key ( секретный ключ)?. В local storage browser? Это, мягко говоря, не здорово.
Там же, где хранятся клиентские сертификаты. те самые, которые X.509(в частности -- на смарт-карте, например. И в USB токенах предыдущих поколений).
Но тут решили изобрели всю систему заново, вместо того, чтобы юзабельность этих сертификатов и токенов до нормального состояния довести.
Если вы хотим создавать неизвлекаемые ключи на каждом устройстве по отдельности - никаких проблем, сертификаты X.509 и ssh рассчитаны именно на такой сценарий. Генерируем Certificate Signing Request, шлём его CA на подпись, говорим серверу доверять всем сертификатам, подписанным этим CA.
Если нам надо подписывать сообщение и передавать подпись на удаленный сервер - замечательно, именно такая процедура производится в TLS хендшейке или например в простеньком текстовом протоколе ssh-agent.
Как я и говорю, для всех этих операций не нужно было придумывать буквально ничего нового. Достаточно реализовать в браузере все эти стандарты с протоколами, которые существуют годы (если не десятки лет) и отлично себя зарекомендовали в самых суровых продакшнах.
Мы хотим чтобы секретный ключ был доступен только когда user authenticated локально. Именно это добавляет стандарт FIDO , на котором основан passkey. Причем authenticated лучшим возможным способом: fingerprint, face id. В худшем случае PIN. Ещё мы хотим хранить секретный ключ безопасно лучшим возможным способом для данного устройства.
Ничего такого в браузере или ssh нет.
А протоколы там и так используются самые обычные: цифровая подпись RSA или ECC.
Про якобы овеинжениринг: в JavaScript добавили 2 (две!!!) функции: создать ключ и подписать данные этим ключём
Про якобы овеинжениринг: в JavaScript добавили 2 (две!!!) функции: создать ключ и подписать данные этим ключём
Это в JS. А теперь смотрим, как Cross-Device Sign-In работает. Браузер, конечно, всего этого не видит. Я вот, например, не понимаю, для чего там устройству-авторизатору нужно было придумывать такой протокол, что он требует Интернет-соединения. С учетом того, что там одновременно bluetooth используется.
Очень неудачная статья для перевода. Во первых.
Для использования ключей доступа также требуется биометрическая аутентификация (например, Face ID или отпечаток пальца). Даже если кто-то украдет ваш телефон, он не сможет получить доступ к ключам доступа без ваших биометрических данных.
В наших краях упоминание биометрии моментально всех нервирует и распугивает. И нужна она только тогда, когда владелец телефона этого хочет.
Во вторых:
Нет описания (и даже не упоминается, насколько я вижу) возможности Cross-Device Sign-In когда телефон используется для входа на десктопе или другом телефоне.
А механизм работы там достаточно загадочный в том смысле почему именно такой.
Да и мне кажется тут лукавство, у меня на винде требуется только пин код, это же не биометрия...
Как ты обходится стороной вопрос о том как владельцу пасскея зайти на нужный сайт самому, в случае если телефон утерян или сломан.
Да что там странного? Мало информации просто и все. Вместо логина и пароля создаётся пара ключей, закрытый хранится в чипе на устройстве локально или в tpm модуле на винде, входить можно не только по биометрии, но и по паролю экрана блокировки или отдельным USB модулем. На сервере хранится публичный ключ, потом есть процесс аттестации, когда проверяется что ключи совпадают и сервер в замен выдает обычный jwt токен
Да что там странного?
Речь идет про Cross-Device Sign-In. (вот первое попавшееся видео, как выглядит) Как я уже тут где-то рядом писал - он странен тем, что используется и интернет и bluetooth. Хотя казалось бы для того, чтобы воспользоваться ключиком во втором устройстве достаточно только bluetooth. Ну или NFC, но этот вариант у всех только в стадии разработки, кажется.
А информации мало не о том, как оно работает(этого уже полно), а почему именно оно такое, какое есть. Вот почему (уже в который раз тут озвучиваю), клиентские сертификаты не подошли? Тоже пара ключей. И протокол браузером из коробки поддерживается - вроде нигде еще не выпили.
Как-то вечером в офисе открылась дверь, и в нее ввалился человек в маске клоуна: огромная несимметричная рожа, нарисованные синие круги вокруг глаз и большой красный рот.
Представили?
А это был не клоун и не маска: это сотрудника ночной смены по дороге избили гопники (лицо распухло до карикатурного вида) и отобрали телефон.
Всегда вспоминаю эту историю при словах "биометрия" и "специальная программа на телефоне".
Пароль можно хотя бы вспомнить...
PKI - это нормальная тема, а вот невозможность доступа и сохранения собственного персонального сертификата где угодно (тупо зашифрованного отдельным пользовательским паролем в файловой системе) - полная хрень.
Украли/потерял/сломал устройство с сертификатом, и? Причем тут биометрия тогда?
Облако (для восстановления сертификата) требует именно этот сертификат с устройства, и? А если требует пароль, то зачем тогда сертификат?
Украли/потерял/сломал устройство с сертификатом, и?
Надоел этот аргумент. Берем другое устройство, где сертификат (возможно, другой, но пригодный для той же цели), есть. Которое надо, разумеется создать, так же как надо копию пароля куда-нибудь записать на случай утери той копии, что пользуешься.
Вообще, вся система с синхронизацией - это какая-то встроенная подпорка. Так-то (не очень настоятельно, правда), рекомендуется использовать device bound passkeys. Правильный сервис, соответственно, должен уметь привязывать к учетке произвольное количество ключиков, а не только один.
так же как надо копию пароля куда-нибудь записать
Пароль можно просто запомнить.
Пароль можно просто запомнить.
Это предполагает, что люди могут могут запомнить все пароли, разные (потому что одинаковые пароли создают проблемы), достаточно сложные (чтобы пароль из утекшей базы подбором не ломался) от всех сервисов, что он пользуется.
Что на практике не выполняется. Потому что если бы оно было верно - все это вот придумывать бы просто не пришлось.
И то что 'можно запомнить' навечно, без риска утерять/забыть - это ну очень сильно предположение, которое на практике, как мы знаем тоже как-то не наблюдается.
:-) "произвольное количество ключиков" - и паролей тогда уж... И много вы таких знаете?
Аргумент вам надоел, а не надоедает специально "для биометрии" иметь "другое устройство", "другой ключ" и приседания по их регистрации в сервисе?
Правильный сервис, соответственно, должен уметь привязывать к учетке произвольное количество ключиков, а не только один.
Я за свою жизнь видел в разы больше неправильных сервисов, чем правильных.
А уж всякие развлекухи, типа - "ой, тут ваш yubikey нашим правилам сертификации не удовлетворяет, идите в ...." - это вообще любим и практикуем. (год до этого удовлетворял у другого сервиса верификации, а потом работодатель решил перейти на windows hello. Чтоб ему пусто было.
PS. Для паролей есть парольный менеджер. А вот passkeys - не доверяю. вот вообще. Это не трогая того, что это будет мешать автоматизации взаимодействия с сервисами. (Смотри выше про "правильные" - предусмотреть пароль для средств автоматизации. Не вы что, у нас есть ОДИН СамыйПравильныйМетодАвторизацииИНикакИначе). Простите. От взаимодействия с рабочими сервисами и прочим гуглагом накипело.
Для паролей есть парольный менеджер.
Что по сценарию не отличается от базы данных Passkey-ев. Так что с этой стороны разницы нет.
Аргумент про неудобство автоматизации - согласен. Но авторы стандарта, очевидно, предполагают, что сервисы, которые предполагают автоматизацию - должны какой-нибудь OAuth токен выдавать. А те, что не предполагают - это надо думать, это именно нужный пользователь автоматизирует, или злодеи что-то такое настроили, так что оно может, и к лучшему, что неудобно.
Берем другое устройство, где сертификат ... есть.
Это если второе устройство есть. Технология эта для широкого круга лиц и у них никакого второго устройства может не быть.
Это если второе устройство есть. Технология эта для широкого круга лиц и у них никакого второго устройства может не быть.
Планшет/старый телефон. Оно с андроида 9 поддерживается. Запасной можно заиметь задешево, если еще нет.
Кроме того - как раз для таких и прикрутили синхронизацию. Ключики (немного другие) - в новый телефон втянутся, когда ты его к своей учетке Гугла (ну или Apple) привяжешь.
Занятный у нас с вами диалог получается:
– Второго устройства может не быть.
– Пусть используют планшет/старый телефон второе устройство!
Ключики-то втянутся, только новый телефон ещё достать надо. А в свой аккаунт, например, с соседского десктопа не зайти - passkey нужен, а одного пароля недостаточно.
Да, в этом плане даже TOTP явно удобнее/прозрачнее.
только новый телефон ещё достать надо.
Запасные ключи изготавливаются до того, как ключ потеряешь. Это не такое уж большое изменение привычек, особенно учитывая то, что с физическими ключами так и делаешь.
А в свой аккаунт, например, с соседского десктопа не зайти - passkey нужен, а одного пароля недостаточно.
И именно этого и добиваются. Потому что десктоп может быть не только соседский, но и злодея.
Со своего второго устройства - вполне зайдешь, потому что там к этому моменту либо уже свои ключики заведутся, либо телефонные синхронизируются.
Мы, кажется, по кругу ходим. Повторюсь:
Технология эта для широкого круга лиц и у них никакого второго устройства может не быть.
То что лично вы понимаете, что второе устройство необходимо, не даст этого понимания (и устройства) миллионам (а то и миллиардам) пользователей по всему миру.
Мой тезис - что у здоровенной такой массы широкого круга лиц второе устройство уже есть. Поэтому им даже задумываться не придется.
А просто пароли, очевидно, большим фирмам перестают нравится. И чем их заменять?
Утомившиеся в соседней реплике OTP генераторы - та же сложность "вдруг потеряю?" и точно так же, по хорошему, второго устройства требуют.
totp-генератор заводится несколько проще ("хоть на ардуине" ™ )
Впрочем - даже их умудряются сделать через жопу - "ставьте наше приложение, иначе мы сделаем вам жизнь адом"
Для OTP то зачем отдельное устройство? Нужен только секретный код и генерилка типа такой.
Для OTP то зачем отдельное устройство?
Потому что в этом смысл. Чтобы злодей, который смог захватить контроль над этим устройством, все еще не мог залогинится. Что он сможет, если генератор живет тут же.
Это, конечно, от уровня параноий зависит, но идея приблизительно такая.
По мне так OTP не про безопасность, а про неудобство - ладно хоть преодолимое, а то у некоторых реакция такая. В плане безопасности меня пароли устраивают.
:-) Полностью солидарен. Пароли - наше все.
При применении терморектального взлома не спасет ничего... А вот без него - у нормально мыслящих людей пароль из головы не извлечешь и вводить "где попало" они не будут, а других не защитит никакая технология безопасности или способы идентификации (они сами все добровольно отдадут).... :-)
Так ты подписку не продашь.
Тут основная фигня - как ключи шарятся между устройствами. Можно через сервера Apple или Google, в перспективе MS. Якобы говорят что все передается зашифрованным - но при этом протокол закрыт, нет открытости при передаче через их сервера. Откуда мне знать что они там передают, как проходит шифрование? Почему нельзя подменить устройство и сохранить на другом вирт. устройстве - как я об этом узнаю?
Откуда мне знать что они там передают, как проходит шифрование?
Ну, гугл тут описали. Подробнее - я не думаю, что код уж совсем неизвестен. Их бы давно уже загрызли все эксперты, что только можно.
Подробнее - я не думаю, что код уж совсем неизвестен
Вроде API закрыты, протокол держат в тайне. Как происходит передача всех секретов от одного девайса к другому, могу ли я сам инициировать такую передачу путем вызова системных API?
Нет прозрачности и открытости, а это уже дурно пахнет.
Ну если включить немного здравой паранойи - так буквально предлагается доступы к своим сервисам хранить у "очень честных чуваков, они же написали что они честные!" Причем эти доступы разработаны самими очень честными чуваками, то есть они и алгоритмы шифрования знаю а то и доступ к контейнерам имеют изначально.
нет открытости при передаче через их сервера
Что есть открытость при передаче через сторонний сервер?
Что есть открытость при передаче через сторонний сервер?
Копия ключей, передача ключа на другое устройство - это то, чем пользователь должен уметь управлять. Могу ли я передать свои ключи с Android-телефона на iOS-телефон? Есть ли открытый протокол для этого? Или навечное привязывание к вендору?
Могу ли я передать свои ключи с Android-телефона на iOS-телефон?
...
Или навечное привязывание к вендору?
Вообще, это не так должно происходить. А вот так:
Начинаешь логинится на iOS телефоне. Когда спрашивают - говоришь 'хочу использовать другое устройство'. Процедура показывает QR код. Ты сканируешь его Android телефоном, происходит вход в сервис. И в процессе - тебя спрашивают 'а не создать ли Passkey на этом (iOS) телефоне'.
Если ответить положительно - в iOS телефоне появляется свой ключик.
Так что привязки нет, но путь несколько косвенный, не через синхронизацию.
Если ответить положительно - в iOS телефоне появляется свой ключик.
Для каждого сервиса нужно процедуру повторить? Работает ли это реально или только ваше видение как должно быть?
Повторить придется, да. На некоторый, возможно - придется зайти в их Security настройки явно и ключевую пару явно добавить.
Но так - проверялось логином с андроидного телефона в Edge,Хром,Firefox на винде. Ключик в Windows Hello добавляется и потом все три браузера могут им пользоваться. Т.е. это не браузерное хранилище, а системное. Можно даже в TPM заглянуть консольными утилитами - но там они в крайне нечитабельном виде представлены и поэтому сильно непонятно, какой от чего.
А меня все достало и я купил клавиатуру с макросами и вбил туда пароли систем, с которыми часто работаю. Кайфую. Тем более умники местами отключили copy paste для паролей в ряде мест, а мне теперь пох
Паскей немного про другое, его суть это чтобы было невозможно перехватить пароль в принципе, никакого пароля нет. Пароль не хранится и его нельзя слить. Есть проблемы с мультидевайсами, тут запутано да
То, что вы вводите пароли макросами не мешает слить базу данных сервиса куда вы их отправляете
Вообще вся эта система с ключами это только всего лишь замена пароля и все, ничего более, это не отменяет ни вторых факторов и прочего. Вместо пароля мы отправляем открытый ключ и все, не зная закрытого мы такой же не сделаем. Вот и весь смысл
Самое дикое что у Сбербанк и Совкомбанк это давно есть, в у Т-Банк нету.
Говорят что и палка раз в год стреляет, и негоже все яйца в одну корзину складывать.
Собственно о чем это я. Так я о том, что все эти фразы не с потолка взяты и являются фольклорной формой демонстрации некогда неудачно полученного или наоборот удачно опыта.
Колличество утекших данных пользователей с каждым днем растет как на дрожжах. Причина тому проста, идеальной безопасности не существует. Они миф, вымысел. И если вам говорят что все ваши данные и пароли будут надежно защищены читайте эту фразу правильно. В один прекрасный день этот цикл безопасности будет прерван. И тогда мы получим маленький такой филиал хаоса.
А в целом закончу как и начал, благими мыслями дорога в ад выстелена.
Только вот беда - если ты перепрошил устройство (что лично у меня бывает периодически) - все эти пасскеи слетают и теряются и надо по новой настраивать.
если хранить в облаке или на электронном ключе, то нет, не дезориентируй людей
Я вас не знаю, что бы тыкать, как и вы меня.
Хранить пароли или ключи в облаке? Вы серьёзно?
Про электронный ключ другие вопросы - а кто на самом деле будет покупать ключ для авторизации к чему угодно? Вы будете покупать ключ для авторизации к гитхабу или мелкомягким или просто нажали сохранить пароль / ключ на устройстве? Только честно.
как человек, который принимал участие в реализации входа по webauthn passkeys (полностью реализуя backend часть), хочу сказать, что эта технология ни в коем случае не использует никакие биометрии)) Закрытый ключ хранится на вашем устройстве (пк/браузер/электронный ключ), либо в облаке (icloud, google, bitwarden и т.д.) и чтобы использовать этот ключ для входа на сайт, вы должны его «достать» из хранилища, а чтобы это сделать, вы должны, каждый раз подтверждать что вы владелец устройства, подтверждение происходит точно также, как процесс разблокирования телефона или ПК (либо также, как открытие менеджера паролей, кстати когда вы храните ключе в облаке, они и так хранятся в менеджерах паролей), то есть для подтверждения входа вы вводите ПИН-код, либо Touch ID, либо Face ID. Ещё раз: биометрию использует ваше устройство для подтверждения, что вы владелец устройства, для того чтобы «достать» ключ из хранилища)
того чтобы «достать» ключ из хранилища
Так основная фишка ж в том что ключ из микросхемы невозможно достать никаким образом - ЭЦП производит сама микросхема без отдачи ключа во внешний мир из своей памяти. Это не плохо, но при синхронизации ключей все-таки есть способ импорта, пусть и зашифрованых данных.
Если есть синхронизация или бэкапы значит ни в какой микросхеме он точно не лежит. Мне нравится пасскей, но как замена паролям, а не паролям+2FA иначе опять появится единая точка отказа.
Если есть синхронизация или бэкапы значит ни в какой микросхеме он точно не лежит
Вроде пишут что первая микросхема может передать свой публичный ключ второй микросхеме. И тогда вторая микросхема шифрует публичным ключом свои данные и передает первой - первая расшифровывает внутри себя самой. Т.о. для внешнего мира ключи не доступны. Остается только вопрос - как пользователю понять какая из микросхем делает запрос - его личная или кул-хацкера.
Остается только вопрос - как пользователю понять какая из микросхем делает запрос - его личная или кул-хацкера.
Там в процесс еще PIN/пароль блокировки экрана/пароль учетки используется (лень перечитывать статью, что тут где-то линковал), без которого ничего не расшифруется и который надо отдавать в первую.
Поэтому у злодея ничего не получится. Но это приводит к той же уязвимости с паролем(если злодей сумел завладеть паролем - получит и ключики), поэтому они их хотят совсем извести.
Что вынуждает иметь ключевые артефакты. Больше одного. А дальше получаем (вот и тут несколько раз спрашивали) "а если потеряю?". Как будто пароль потерять/забыть нельзя.
И, (повторяюсь, да), я не очень понимаю почему ответ 'иметь запасной' настолько плохо воспринимается - ну делаем же мы запасные физические ключи от разных физических замков. Почему для 'замка' на сервисе нельзя? Ладно бы говорили, что дорого - так ведь оно не очень верно(тут возможны варианты), но именно 'дорого' как аргумент приводится редко. Не нравится сам факт необходимости иметь запаску.
Пароли не в моде...
Пасскей в моде правда только на 5: сервисах.
Жестокая мода...
Ездить на транспорте не в моде... Летать в космос в моде.
Есть хлеб не в моде... Черную икру в моде...
Главное, чтобы "модники" не начали агрессивно навязывать "лучший пользовательский опыт" (по их версии, разумеется), отключая нормальный работающий.
Очень поверхносная статья. Как раз недавно реализововал авторизацию через passkey и webauthn в ios мобильном приложении. Passkey это надежно и очень удобно. В случае iOs, даже приложение не имеет доступа к приватному ключу, ни на этапе генерации, ни авторизации. Приложение просто вызывает системное Api для подписи challenge (который присылает сервер), а система его подписывает выбранным юзером ключем, проверив юзера биометрией. Также ключи синхронизируются между всеми apple девайсами, привязанными к одной учетной записи, так что потеря телефона не проблема
Также ключи синхронизируются между всеми apple девайсами, привязанными к одной учетной записи, так что потеря телефона не проблема
угадайте, где они хранятся и кто ещё имеет доступ, если синхронизуются между всеми apple девайсами без трудностей и потеря телефона не проблема? Отвратительно же, хотя может не так плохо как пароль 123456
Понятно. Раньше для выяснения пароля или кодов доступа применялся анально-ректальный способ, не обязательно с гарантированным успехом. Тут все проще. Субъект живым не нужен. Достаточно его пальца или улыбки покойника.
Про андроид не скажу, а на яблоках достаточно нажать громкость и действие и биометрия отключается. Если вы вдруг боитесь что через нее все откроется.
Вообще не понимаю почему передача по сети логина и пароля считается безопасней, когда сейчас буквально у каждого есть карманное устройство, которое может шифровать данные и хранить их локально
Если вы вдруг боитесь что через нее все откроется.
У меня все критичные данные под паролем. Так что не боюсь.
Вообще не понимаю почему передача по сети логина и пароля считается безопасней
А я не понимаю, почему вообще по сети передается пароль. Кроме сайтов, где и так никакой чувствительной персональной информации не бывает, везде хранят только криптографический хеш пароля, из которого без суперкомпьютера задолбаешься сам пароль получать. На клиенте пароль используется только для того, чтобы подписать криптографической хеш функцией от него ответ серверу, содержащий в себе запрос сервера, который всегда разный.
у каждого есть карманное устройство, которое может шифровать данные и хранить их локально
Даже если доступ к этому хранилищу через пароль в голове, то его компрометация - утеря всех паролей. Это почти тоже самое, что на всех карточках использовать один пин-код или на всех сайтах регистрироваться с одинаковым паролем.
Чтобы скомпрометировать локальное хранилище нужно проепотерять: 1. саму локальную базу, 2. пароль к ней.
Причем так, чтобы было однозначное соответствие между базой и паролем.
Это связанные вещи. Если кому-то удастся подсмотреть пароль, то уже украсть после этого смартфон - дело техники. А если вспомнить еще о детях или иных родственниках, которым смартфон совсем не обязательно воровать, то становится совсем грустно.
А если вспомнить еще о детях или иных родственниках, которым смартфон совсем не обязательно воровать, то становится совсем грустно.
Поэтому если мы боимся этой угрозы, то храним смартфон с ключиками в сейфе. А ключ от сейфа, который, очевидно они тоже могут украсть...<далее по индукции> Однако помним, что сотни лет с сейфами и желающими посмотреть, что в них находится - как то жили. С разной степени успешности в зависимости о степени параной владельца.
Значит менеджер паролей, с зашифрованной базой, которую хостит кто-то (если не позволяет паранойя - то лично пользователь), это небезопасно и фу. А бекап passkey, который в зашифрованном виде (правда-правда в зашифрованном!) хостит дядя в облаке это безопасно и модно. При этом для passkey со стороны сервера даже не надо второго фактора. Эта логика для меня непонятна.
Эти резервные копии шифруются end-to-end — это значит, что доступ к ним есть только у вас
нынче такие облака у нас, что end-to-end значит только то что они в открытом виде на серверах не лежат, а по факту все кому очень хочется - доступ имеют, начиная от спецслужб и заканчивая протечками
Пароли больше не в моде? Что такое Passkeys?