Comments 48
Информация по поводу моего USB устройства попроще:
(ответ на вопрос уважаемого @M_AJ) Точное название устройства — ACS PocketKey (AFD-KM v1.2.1.0) от компании Advanced Card Systems Ltd., размер 29 × 14.5 × 10.5мм, вес 4.5 г. Обошлось мне примерно $27 в оффлайн магазине.
Форм-фактор USB Type-A (USB 2.0), криптография на ECC p256, поддерживаемые стандарты аутентификации FIDO U2F, FIDO2, FIDO2 CTAP2.1; поддерживаемые браузеры Chrome, Edge, Firefox, Safari; поддерживаемые OS Android, Linux, MacOS, Windows.
После задания PIN-кода (нужно установить с сайта производителя ACS FIDO Key Manager MacOS / Windows) доступна запись на устройство Resident Credential (максимум 200 одновременно, можно удалять ненужные).
(ответ на вопрос уважаемого @leon_shtuet) Нет, как аппаратный ключ с KeePassXC (версия 2.7.7 / Win10) не работает — пишет что «аппаратный ключ не обнаружен».
(ответ на вопрос от меня самого) Да, можно использовать для хранения секретного ключа OpenSSH (не поддерживает ed25519).
Нужно подключить устройство к компьютеру и выполнить команду:
ssh-keygen -t ecdsa-sk -O resident -C "Your Comment" -f ~/.ssh/id_myacs_sk
После ввода правильного PIN устройства мигает светодиодом кнопки (нужно нажать её), генерирует ключ и записывает его на устройство, а также в файл (рекомендуется защитить его сильной парольной фразой и спрятать подальше).
После чего на произвольном компьютере с OpenSSH (и запущенным ssh-agent) подключаем устройство, загружаем данные о ключе в агент ssh-agent -K (требуется ввести PIN, сам секретный ключ остаётся на устройстве!), заходим на нужный хост ssh host. Мигающая синим кнопка означает, что устройство просит подтверждения, после нажатия на кнопку мы авторизованы! Очень удобно оказалось, теперь точно всюду без опаски PasswordAuthentication no пропишу в настройках sshd (пока оставлял парольную аутентификацию на серверах подскока).
(пока нет ответа на вопрос «Работает ли устройство с GPG», там надо ещё почитать / поразбираться; как появится — напишу)
В имеющихся 2FA жутко бесит, что время должно быть достаточно точно синхронизировано между девайсами — а если второе устройство не имеет контактов с внешним миром, то время имеет тенденцию убегать, и в результате сгенерированный код не подходит. Другая проблема — часовые пояса: поскольку я нахожусь не в Москве, постоянно приходится на девайсе выставлять московское время, чтобы код для Сбера оказался правильный. Есть же для таких ситуаций UTC, которое по всему шарику одно и то же — но индейская народная национальная изба получается...
Поскольку не раз реализовывал и использовал TOTP в разных проектах, то описанная ситуация несколько удивляет.
время имеет тенденцию убегать
У TOTP есть параметр "период" и его редко ставят меньше 30 сек. Устройство в котором время убегает от сервера на хотя бы 5 сек (что бы это вызвало проблемы) за какой то разумный срок (месяц..два) без синхронизации - это странно.
постоянно приходится на девайсе выставлять московское время, чтобы код для Сбера оказался правильный. Есть же для таких ситуаций UTC
То же очень странно. В стандартной реализации, на хосте у меня используется Math.floorDiv(System.currentTimeMillis()/1000L, period) и никаких проблем нет с UTC временем ни с одним сторонним токеном TOTP.
Потому что, по стандарту rfc6238 используется время UTC и никаких часовых поясов нет в принципе.
У меня на "телефоне" (аппарат, у которого нет симки, то есть это просто "мобильный WiFi-терминал" время регулярно убегает на 2-3 минуты (Без симки синхронизировать время с сотовой сетью он почему-то не умеет), а установка "текущего времени" осуществляется как "укажи на циферблате, куда стрелки показывают" (а не "набери цифирки на клавиатуре"), в результате чего правильный TOTP-код получается попыткий так с пятой.
То же очень странно. В стандартной реализации,
Очевидно, у сберовских программистов своеобразные понятия о том, что такое "стандартная реализация" (ни разу не удивлён, кстати, велосипед из костылей — наше всё). При установке правильной таймзоны и правильного текущего местного времени — индейская изба; при установке таймозны "Москва" и текущего московского времени — работает.
Кстати, если у Вас часы на устройстве отстают — попробуйте oathtool -w 10 скажем. Это сгенериует TOTP для текущего момента времени плюс 10 последующих периодов (30 секунд рекомендовано). Можно изловчиться в уме коррекцию делать: «ага, отстаём на две минуты, значит беру пятое выданное значение TOTP».
А вот если спешат, тогда хуже… Ну и привязка к конкретной таймзоне остаётся — если бы в РФ была одна таймзона на всю страну, можно было бы сказать «так и задумано, чтоб только свои могли пользоваться», а так даже и не знаю.
А вот если спешат, тогда хуже…
Ничто не мешает точно так же сгенерировать код на любой момент времени, в том же oathtool можно задать произвольное время, а не только несколько будущих кодов. При желании можно даже скрипт наклепать, который запросит текущее время с какого-нибудь интернет-ресурса, сделает коррекцию на таймзону и вставит это значение в параметры oathtool'у вместо текущего. Другой вопрос, что запускать консольные программы на смартфоне — удовольствие ниже среднего, не говоря уж о том, что секретный код для генерации придётся тогда хранить не в конкретном приложении, а в общедоступной части файловой системы.
Да, Вы правы, можно делать нечто вроде такого oathtool -N $(date -ud "2 minutes 25 seconds ago")
Что касается консольных программ на смартфоне (хотя я именно от смартфона и старался уйти), то при наличии там полноценного линукса (iSH для iPhone, наверняка для Android есть аналог) — можно поставить туда кроме oathtool ещё и GPG, ну и mytotp.sh тогда тоже.
(в сторону: делегация TLD .sh это прямо диверсия! пришлось упоминание своего скрипта как код оформлять, иначе считало это активной ссылкой)
Можно попробовать настроить на этом "телефоне" синхронизацию времени по GPS, была вроде такая фича некоторое время на андроиде, а если уже недоступна, то наверняка есть программы реализующие такой функционал.
Очевидно, у сберовских программистов своеобразные понятия о том, что такое "стандартная реализация"
Это не у них может быть. А у таблицы таймзон в какой-нибудь Java внутри телефона, которую забыли обновить. Потому что, скажем, некоторые варианты до сих пор думают, что в самарской таймзоне (если она вообще есть) времени есть переход на летнее время да еще и смещение не то, которое было. В результате в unixtime то самое текущее время, вводимое руками, неправильно пересчитывается.
Проверяется легко - ставим таймзону, синхронизируем время по NTP (не ставим руками и не берем с сотовой сети - там оно правильное смещение умеет передавать) через WiFi и смотрим, а правильно ли часы телефона время показывают.
Или по другому - поставить UTC зону, ввести UTC время, потом переставить зону, не трогая само время. И посмотреть показание часов/правильность кодов OTP.
Воистину удивительные вещи могут сотворить одарённые люди при реализации хорошо документированных стандартов! Ведь в RFC 6238 явно прописано использовать UNIX time (Определяется как количество секунд, прошедших с полуночи (00:00:00 UTC) 1 января 1970 года (четверг)); да и целый раздел посвящён проблеме синхронизации, с рекомендацией:
If the time step is 30 seconds as recommended, and the validator is set to only accept two time steps backward, then the maximum elapsed time drift would be around 89 seconds, i.e., 29 seconds in the calculated time step and 60 seconds for two backward time steps.
Ведь в RFC 6238 явно прописано использовать UNIX time
Хе, кожаные мешки уже который десяток лет костыляют "валидацию емейл-адреса" каждый в меру своего понимания (при том, что в RFC совсем другое написано), а Вы всё ещё на что-то надеетесь...
Да, есть такое! Почитал Ваш перевод, полезная штука — и то, в RFC 3696 уже не упоминается UUCP bang notation (RFC 976) типа system!user@domain. Хорошо, если есть проверенные библиотеки (привет, supply chain attack!); а если делать самому ab ovo — то читать всю доступную документацию, включая лютое legacy.
А надеюсь я так, pro forma… Но всегда приятно быть удивлённым!
взял USB-устройство попроще
Хоть бы сказали какое.
Прошу прощения, я решил избежать подозрений в рекламе конкретного девайса; подумал что если кому-то интересно будет — спросят в комментариях.
Это изделие ACS PocketKey от компании Advanced Card Systems Ltd. Форм-фактор USB Type-A (USB 2.0), криптография на ECC p256, поддерживает стандарты FIDO U2F и FIDO2 L1.
Устройств попроще на алике полно по запросу "FIDO2"
До ответа автора я по фото даже подумал, что это что-то от KEY-ID, по внешнему виду очень похожи.
А ведь полностью аппаратный TOTP-токен тоже возможен. Пластина в формате банковской карты, только потолще. На борту eInk дисплей, всесистемный приемник GNSS для периодической коррекции локальных часов, и клавиатура с HEX набором. Буквы хекса вводят символы при вводе ключа, в остальных состояниях являются функциональными кнопками. Цифры всегда вводят цифры - ввод пин-кода при разблокировке и навигация. Питать это все от пары биосных батареек. Для дополнительной паранойи можно хранить базу в оперативке, питать ее через обрывную обмотку в стенках корпуса, и конструктивно обеспечить замену батареек только по очереди, для непрерывности питания.
Да, возможен! В описанном Вами формате точно существовали аппартные генераторы HOTP; а впрочем вот нашёл и Feitian c200 TOTP:
Ну все же не совсем. Я имел в виду примерно так - вводим пин для разблокировки, видим меню:
Меню
01 Google
02 Hotmail
....
20 Facebook
-------
A: Prev page
B: GNSS sync
C: Lock session
D: New entry
E: Delete entry
F: Next page
Соответственно, вводим номер с клавы и сразу получаем соответствующий 2FA код, а хекс буквы служат функциональными клавишами. Сами собой они являются, если мы войдем в режим New entry и будем там вводить ключ. Название сервиса вводим с цифр по принципу SMS.
P.S. Да и приема времени от GNSS я в спеке этого брелка не увидел.
Скажу честно, глубоко в спецификации я не смотрел; время там каким-то образом всё же поддерживается более-менее точным; а вот что касается меню — очень может быть, что оно вообще для Одного-Единственного Самого Секретного Сервиса.
В любом случае, устройства с CTAP1 / CTAP2 делают такие аппаратные HOTP / TOTP токены устаревшими. Чем запоминать на устройстве секреты от разных сервисов, чтобы потом использовать достаточно примитивную математику для получения хэша — лучше взять за основу современное ассиметричное шифрование на эллиптических кривых; секретный ключ выжжен в устройстве, публичный сообщается сервису при регистрации и запоминается им. И всё, при аутентификации сервис посылает челлендж, токен отвечает на него и подписывает ответ своим секретным ключом; сервис проверяет ответ и подпись — бинго!
секретный ключ выжжен в устройстве
Защитники приватности шуметь будут. Потому что так получается, что один ключ используется в разных сервисах. Потому его и генерируют для каждого сервиса отдельно.
С другой стороны, выжеч прямо на фабрике и зашить в устройство можно пару десятков тысяч штук. Это всего ~300 килобайт для 128 битного ключа.
И пускай устройство последовательно предлагает, когда генерацию просят.
Но тут шуметь будут уже параноики-криптографы. Дескать, нет никакой гарантии, что фабрика эти ключики куда-нибудь не сохранила.
Ну это по сути обыкновенный USB-токен получается, с помощью которого бухгалтера логинятся в свои сбисы и диадоки. Тут загвоздка в том, что требуется двусторонний обмен между токеном и устройством, соответственно страдает или удобство, или универсальность, или дешевизна. А в чем несекурность TOTP, особенно если вовремя переходить на более современные криптопримитивы - не понимаю.
Ну это по сути обыкновенный USB-токен получается, с помощью которого бухгалтера логинятся в свои сбисы и диадоки.
Ну да. Я и написал, что не понимаю, почему не захотели воспользоваться всеми этими протоколами, а изобрели новый.
С точки зрения использования - что так, что так втыкаешь какое-то устройство в USB (ну или то же самое по Bluetooth/NFC)
Тут загвоздка в том, что требуется двусторонний обмен между токеном и устройством,
В момент создания учетки - он всегда требуется чтобы seed в токен попал. Сканирование QR-это именно оно. Ну, если он не зашивается на заводе. Но если зашивается - то ключ/публичная часть ключа должна как-то в сервис попасть. Они достаточно длинные, чтобы руками было не набрать, даже если токен его покажет.
А в чем несекурность TOTP, особенно если вовремя переходить на более современные криптопримитивы - не понимаю.
Нет защиты от MitM при регистрации, например. Или что seed хранится и у тебя и на стороне сервера и может оттуда утечь.
В более совершенных проколах над этим поработали. Особенно хорошо будет, если токен нормальным экраном обладает. Можно будет показать 'сайт example.com' хочет сгенерировать учетку, разрешить?
А в TOTP возможен сценарий, когда в основном сервисе регистрируется промежуточный товарищ, а тебе, для инициализации генератора - предлагает свой seed.
Однако сейчас нужно хотеть уже не генератор OTP (ну устаревает оно), а устройство для работы с Passkeys/WebAuthn, интерфейсами PC/SC и прочими CCID-образными.
Мне, кстати, интересно, почему на предыдущее поколение интерфейса ко всем этим токенам авторизации решили забить, а изобрели заново.
...И почему смартфоны, у которых USB, Bluetooth, NFC есть, аутентификатором по этим CCID образным интерфейсам работать не умеют.
А у устройства, показывающего циферки есть, кажется, только одно преимущество - явный air gap и, соответственно, никакого специализированного интерфейса от того устройства, где оно применяется, не требуется.
...И почему смартфоны, у которых USB, Bluetooth, NFC есть, аутентификатором по этим CCID образным интерфейсам работать не умеют.
В смысле, не умеют? Например, можно с любого компьютера войти по пасскею, сохраненному на айфоне.
https://support.apple.com/ru-ru/guide/iphone/iphf538ea8d0/ios
https://fidoalliance.org/news-your-google-android-7-phone-is-now-a-fido2-security-key/
Это не тот сценарий. Точнее, не тот интерфейс. Это, судя по англоязычному описанию того же - новые Passkeys.
Тот - это когда приложение хочет авторизации по железному токену вроде того самого, как у бухгалтера. А ты вместо токена - смартфон цепляешь и дальше работаешь с ним почти так же, как с тем токеном работал бы.
А Passkeys с соседнего устройства, насколько я понимаю - хочет наличия на том самом устройстве Интернет соединения. В отличии от аппаратных токенов.
Он не "возможен" - это единственный разумный вариант. И подобные устройства раньше давали нормальные банки. Только они там не тотр использовали, а вообще одноразовый шифр-блокнот.
Для тотр очевидно нужно устройство с вводом пина и выбором ключа. Ведь для разных сервисов хорошо бы разные ключи. И вот тут надо бы поискать. У меня руки не дошли пока :(
Ввод пароля по нажатию клавиши это в целом неплохо(а поддерживает ли он много ключей?), но яб лучше с экрана набил, удобнее как по мне. С телефоном к примеру неудобно по usb втыкать итп.
Я выше расписал, как вижу примерную логику девайса https://habr.com/ru/articles/809569/#comment_26754969
Позволю себе не согласиться! Чуть выше я написал, что HOTP / TOTP (как и простыни с OTP, пользовался такими в одном банке лет 15 назад) это уже вчерашний день. А современное состояние дел — использование ассиметричного шифрования, когда один токен с намертво прошитым секретным ключом ползволяет использовать множество сервисов (которые на стадии инициализации 2FA зипоминают у себя публичный ключ токена).
Ну т.е. перехватив один "ответ", скажем в хабр ты логинился, можно будет украсть все твои деньги из банков, с биржи итп :)?
Прелестно.
В асимметричном шифровании даже полный доступ ко всей коммуникации не может привести к раскрытию закрытого ключа. По крайней мере, на текущий момент развития науки и технологий и при отсутствии уязвимостей в используемых библиотеках.
Нет. Уважаемый CaptainFlint уже написал почему — использование ассиметричного шифрования позволяет безопасно распостранять публичный ключ (которого достаточно для проверки правильности подписи секретным ключом; а также для шифрования сообщения, подлежащего расшифровке всё тем же секретным ключом).
Пока нет никаких свидетельств возможности восстановить секретный ключ по публичному, как для классичесих алгоритмов (RSA), так и для совеременных (ECC). Когда их научатся ломать, то мои деньги из банков вряд ли заинтересуют того, кто сможет все «потерянные биткоины» на себя переписать.
Нифига не понимаю как можно это натянуть скажем на хабр и банк-клиент одновременно.
Кто кому после чего будет доверять ?
Или вы планируете со своей стороны подписывать каждое "распоряжение" вбивая его в устройство, а результат обратно туда, куда надо ? Как обеспечивается то, что ответы на вопросы хабра не подходят к банк клиенту ?
Как обеспечивается то, что ответы на вопросы хабра не подходят к банк клиенту ?
Тем, что браузер отправляет в устройство еще и информацию, для кого это все подписываться должно. После чего банк клиент, глядя на подписанный ответ для хабр, просто его не принимает, потому что 'я не это подписать просил и это не мое'.
Но, вообще, как я уже выше писал, иметь одну пару для всех сервисов - несколько бестолково. И в WebAuthn/Passkeys так не делают -- там для каждого сервиса своя ключевая пара генерируется и используется.
В какое устройство ?
У нас ведь внешнее аппаратное устройство, ведь правда да ? Не уязвимый к атакам телефон или компьютер, а какая-то отдельная железка, совершенно никакой связи не имеющая. В варианте с разными тотр или просто шифрблокнотом я просто с нее нужные цифири набиваю туда, куда хочу авторизоваться, и они должны быть разными (внутри несколько тотр, выбираешь какой нужен сейчас).
В вашем варианте мне что делать ? Как это было у вебмани вначале что-то набивать в устройство, а потом ответ обратно? Это как-то не очень удобно...
Было бы безусловно полезно прям конкретный "приказ" подписывать, но как подумаешь о том, что отдельное устройство должно тебе дать его сформировать, показать на экране итд итп, тоска берет :(.
У нас ведь внешнее аппаратное устройство, ведь правда да ?
Да. В общем случае - специализированной, но я бы согласился, для большинсва сайтов, и на телефон(у него экран есть и он может показать, что именно авторизоваться хочет) согласился, если ему старательно лишние каналы связи зарезать.
совершенно никакой связи не имеющая.
Нет, в этой ветке этого не хотели. Потому что в заголовке было "А современное состояние дел — использование ассиметричного шифрования, когда один токен с намертво прошитым секретным ключом ползволяет использовать множество сервисов (которые на стадии инициализации 2FA зипоминают у себя публичный ключ токена)."
Тут без нормальной связью с основным устройством - никак, в общем. Хоть по USB, хоть по Bluetooth/NFC. Потому что в вариантами "...вначале что-то набивать в устройство, а потом ответ обратно?", действительно, очень муторно и ползователи взвоют. Хотя и возможно в каком-то виде. Да и публичный ключ от токена в сервис как то передавать надо. Его руками умрешь набирать.
Да нет, как-раз в втб судя по всему неплохо было сделано. Еще лучше было сделано в вебмани. Там набираемое в кодогенератор имело еще и признаки транзакции, т.е. даже при перехвате этого всего после ввода в компьютер было затруднительно подписать ответом другую транзакцию.
Вангую, что этих кодогенераторов нету больше, либо наряду с ними все равно можно по смс войти, либо стоят они негуманно.
В общем случае хорошо бы, чтобы связь нужна только односторонняя, т.е. набрать результат на клавиатуре. Схема с ключом как я понимаю этого не обеспечит :(.
В идеале вообще выбирать на устройстве куда хочешь войти, затем что там сделать (т.е. вход и транзакция должны иметь разные механизмы проверки), затем если это транзакция набирать скажем половину, а лучше весь номер счета, и полученный "приказ" набирать на том устройстве на каком надо.
Для обычных паролей отлично работает мультипасс, единственное у меня колесико требует регулярно промывки спиртом. А вот для чего-нибудь поумнее типа тотр я хорошего варианта не нашел :(
(написал кучу букв, и подумал, что возможно у нас просто разговор о разном: я о современных ключах FIDO U2F / FIDO 2 с HID-интерфейсом, а Вы о простом генераторе HOTP / TOTP с 6-8 цифрами на дисплее?)
Информация по поводу моего USB устройства попроще:
(ответ на вопрос уважаемого @M_AJ) Точное название устройства — ACS PocketKey (AFD-KM v1.2.1.0) от компании Advanced Card Systems Ltd., размер 29 × 14.5 × 10.5мм, вес 4.5 г. Обошлось мне примерно $27 в оффлайн магазине.
Форм-фактор USB Type-A (USB 2.0), криптография на ECC p256, поддерживаемые стандарты аутентификации FIDO U2F, FIDO2, FIDO2 CTAP2.1; поддерживаемые браузеры Chrome, Edge, Firefox, Safari; поддерживаемые OS Android, Linux, MacOS, Windows.
После задания PIN-кода (нужно установить с сайта производителя ACS FIDO Key Manager MacOS / Windows) доступна запись на устройство Resident Credential (максимум 200 одновременно, можно удалять ненужные).
(ответ на вопрос уважаемого @leon_shtuet) Нет, как аппаратный ключ с KeePassXC (версия 2.7.7 / Win10) не работает — пишет что «аппаратный ключ не обнаружен».
(ответ на вопрос от меня самого) Да, можно использовать для хранения секретного ключа OpenSSH (не поддерживает ed25519).
Нужно подключить устройство к компьютеру и выполнить команду:
ssh-keygen -t ecdsa-sk -O resident -C "Your Comment" -f ~/.ssh/id_myacs_sk
После ввода правильного PIN устройства мигает светодиодом кнопки (нужно нажать её), генерирует ключ и записывает его на устройство, а также в файл (рекомендуется защитить его сильной парольной фразой и спрятать подальше).
После чего на произвольном компьютере с OpenSSH (и запущенным ssh-agent) подключаем устройство, загружаем данные о ключе в агент ssh-agent -K (требуется ввести PIN, сам секретный ключ остаётся на устройстве!), заходим на нужный хост ssh host. Мигающая синим кнопка означает, что устройство просит подтверждения, после нажатия на кнопку мы авторизованы! Очень удобно оказалось, теперь точно всюду без опаски PasswordAuthentication no пропишу в настройках sshd (пока оставлял парольную аутентификацию на серверах подскока).
(пока нет ответа на вопрос «Работает ли устройство с GPG», там надо ещё почитать / поразбираться; как появится — напишу)
теперь точно всюду без опаски
PasswordAuthentication noпропишу в настройках sshd
А какой план восстановления доступа, если устройство ломается/теряется/забывается?
Иду к компьютеру, на котором есть любой другой мой SSH-ключ (традиционный, в ~/.ssh/ живущий) — я же не только ключ с токена в authorized_keys прописываю. Но даже если случится такое, что только его прописал — достаю из подальше спрятанный там ранее id_myacs_sk, захожу с его помощью (после ввода сильной парольной фразы).
А, если ключ-файл тоже допускается, тогда ОК. Просто сообщение выглядело так, будто токен остаётся единственным способом аутентификации.
Ну да, я же строку генерации привёл, и словами:
После ввода правильного PIN устройства мигает светодиодом кнопки (нужно нажать её), генерирует ключ и записывает его на устройство, а также в файл (рекомендуется защитить его сильной парольной фразой и спрятать подальше).
Тут ключевая ценность в том, что секретный ключ не покидает токен при использовании, чем закрывается кейс «а вдруг мне надо будет срочно зайти на сервер с компьютера, на котором нет моих файловых ключей SSH, и мне не хотелось бы их туда тянуть» — собственно ради него на серверах подскока я оставлял PasswordAuthentication yes.
Не могу сообразить. Вы подтверждаете "логин" нажатием клавиши на ключе, верно ?
Но чем обеспечивается то, что при этом вы логинитесь туда, куда хотите, а не кто-то логинится в ваш интернет-банк, если ему удалось скомпрометировать вашу операционную систему ? Как вы контролируете, какие конкретно ключи будут использованы после нажатия ?
Да, просто нажатие клавиши на ключе, называется «подтверждение присутствия», как раз чтоб не было возможности удалённо или по расписанию запустить (помимо воли собственника ключа).
Используемый ключ однозначно определяется по домену, с которого приходит запрос на подтвержение аутентификации, выбирается автоматически. Насколько я понял, нельзя имень больше одного ключа для домена (по крайней мере, в Resident Credential). При настолько сильной компрометации системы, когда кто-то может с моего браузера логиниться в мой интернет-банк, с установленным в USB разъём ключом и с «подтвержением присутствия» — думаю медицина техника бессильна вообще.
TOTP без смартфона, послесловие