А можете подсказать подходящий для тех же целей кириллический шрифт?
Присоединяюсь к этому вопросу с изменением: хочется не непрерывный курсив, а рукописный шрифт 'печатного' вида. Такой, что удобно писать от руки и своим начертанием разборчивости помогает. Например, часто упоминаемый в подобном контексте чертежный шрифт близок к требуемому, но у него, как минимум, 'л' и 'п' слишком похоже. И пишется он не так чтобы очень удобно.
бизнесу важно, чтобы проект вообще был написан, в разумные сроки, за разумные деньги и был поддерживаем
А теперь вспоминаем, что большая часть затрат на проект обычно приходится как раз на этап эксплуатации и поддержки, когда оригинальная команды разработки (или даже вся) во всем этом не участвует. И понимаем, что для удешевления этой части нужно каких-то других софт-скилов хотеть, не тех, что в статье написана.
Так что хотеть надо сумрачного гения документирования. Такого, чтобы если кто прочитал результат его работы — так сразу и понял, как система устроена и как ее чинить и допиливать.
С оптикой, я подозреваю, будут некие проблемы — наверняка дорогая и сложная получится. За положением взгляда, скорее всего, следить просто дешевле получится.
Но да, все то же самое делается без всяких OLED — таким же полупрозрачным экраном, на который картинку проектором проецируют.
Ну, сделать стерео, добавить технологию отслеживания точки зрения и поставить в качестве окна в кабине управления чем-нибудь полезным. Можно будет маркеры прямо на реальный мир накладывать. Получится Augmented Reality/HUD, но не посредством очков, а через прозрачную стену.
Вон, тут рядом рассказывают, как автоматизированную систему управления к комбайну прикручивают. Вот там такой монитор вместо окна как раз бы пригодился — ту картинку, что они на планшет выводят, показывать.
Есть убунтофоны всякие, да собственно зачем этому устройству быть вообще телефоном то?
Потому что легко найти уже ненужный и дешевый. Т.е. с большой вероятностью покупать не надо — уже где-нибудь на полках валяется. А так, конечно, можно и на более простой железке делать.
Возможно я не понял вашу схему, что происходит при вводе мастер-пароля?
Запоминается приложением. Если очень параноить — то не запоминается, а каждый раз вводится заново.
Если мы бакапим только его, то где хранятся сами пароли?
Нигде. Они каждый раз генерируются из мастер пароля и прямо тут же введенного имени учетной записи. (Собственно, все это написано в описании CryptoPass, которым я предлагал заменить qwertycards, которые делают похожее, но ручным алгоритмом):
password = base64(pbkdf2(secret, username@url))
PBKDF2 это стандарт, метод генерации паролей. Как проверить его корректную реализацию?
Ссылка CryptoPass была на f-droid. Что означает что исходники доступны. Возможно, что PBKDF2 прямо в этих исходниках нет, но тогда реализация системная и ищется в исходниках андроида или используемой библиотеки.
есть ли драйвер для смартфона чтобы прикинуться клавиатурой
Я тоже искал. Сам по себе Linux эмулировать HID умеет. Но в том же андроиде это умение с самых ранних версий выключено. Правда, когда Android Pie был на стадии слухов — были статьи, что HID эмуляция таки будет. Но ее, похоже, так и не включили.
Причем выключено, как я подозреваю, именно по соображениям безопасности — чтобы нельзя было смарт к компу подключить и быстро набрать зловредный payload через командную строку.
А так проекты с пропатченными ядрами были, но успешно заглохли. Видимо, легче на микроконтроллерах что-нибудь собрать, чем ядро коммерчески доступных смартов патчить.
Далее, как бакапить такие пароли? А то китайский смарт умер, дальше что?
В описываемой схеме бакапить надо только мастер-пароль. Который ты сам и вводишь. Т.е. бакап пароля производится до того как он в смарт попадет. Само же устройстово ничего уникального не генерит и не запоминает — в этом отличие от традиционных менеджеров паролей и это же позволяет держать устройство в вечном оффлайне.
криптостойкости сгенерированных сторонним приложением паролей (кто гарантирует вам генерацию уникальных паролей, а не выборку из 100000 паролей которые выглядят вполне случайно).
PBKDF2 вроде бы это и гарантирует.
Как обеспечить невозможность восстановления пароля путем социнженерии, взлома почты и смены симкарты
Никак. Это за пределами обсуждения. Если сервис позволяет по почте и телефону пароль сбросить и восстановить — то этот риск от способа хранения и генерации пароля не зависит.
Все преимущество — что электроники нет. В современных условиях лучше купить самый дешевый (можно даже БУ) китайский смарт, поставить на него CryptoPass, вбить мастер-пароль и генерировать пароли для сайтов в нем.
Смарт, разумеется, после инициализации никогда ни к какой сети больше не подключается.
Прямо в xkcd-ной картинке показана проблема с сознательным нарушением грамотности. Там тоже обычное слов искажали. Затруднение же не в битах энтропии, а в том, как это все потом вспомнить. Особенно для тех паролей, которыми редко пользуешься.
К сожалению, не будет легко запомнить. Пару месяцев такой пароль не используешь — и вроде еще фразу помнишь, но набрать в точности уже не можешь. Лучше уж вместо искажений на два-три-четыре слова фразу длиннее сделать.
Странно что не рассказали о самом лучшем и надежном методе генерирования паролей — использование нескольких случайных слов:
Идем, скажем, на список случайных слов от EFF. В длинном списке их 7776 штуки или 12.9248… бит на слово. Чтобы набрать 128 бит энтропии нужно 10 слов. А десять случайных слов запомнить — тоже проблема.
Хорошо запоминается только грамматически правильная случайная парольная фраза. Но несмотря на целую кучу генераторов текста — я ни сумел найти ни одного, который умеет генерировать фразы с гарантированной энтропией. Всякие современные методы генерации при помощи сеток для этого, очевидно, мало подходят — там невозможно понять, насколько именно получающийся текст случайный.
Так мы же не в техническом канале передачи ошибки ловим (там обычно какая-то защита от ошибок уже есть), а именно при наборе. Поэтому отдельно учитывать ошибки вида "n последовательных бит" вроде бы должны быть неактуально.
Т.е. для гарантированного обнаружения таких ошибок валидным ID-ом должно быть каждое 109-ое число.
Похоже, кстати, что "делится нацело на 109" — и есть алгоритм для 11-ти значного десятичного числа, гарантированно находящий ошибку в одной цифре либо одну перестановку рядом стоящих.
Наверное есть вариант изменения первоначальной постановки задачи
Тогда уж использовать 16-чное число. Только вместо цифр 'ABCDEF' использовать что-то вроде 'ABCEHK' — чтобы одновременно и латиницу не заставлять русскоязычных произносить и проблем с кириллицей для зарубежных систем не создавать.
Пока нам с вами вариант, который гарантирует обнаружение одиночных ошибок неизвестен же.
В 11-ти значном числе, если в арифметике не ошибся, есть 99 вариантов ошибиться в одной цифре и 10 вариантов — переставить две рядом стоящие. Т.е. для гарантированного обнаружения таких ошибок валидным ID-ом должно быть каждое 109-ое число. Кажется, это означает, что двух десятичных разрядов контрольной суммы заведомо для этой задачи не хватить.
Вот с CRC-6 было бы просто, но Вам он, почему-то не нравится.
Почему не нравится? Мне все равно. Единственное, что я хотел выяснить — почему выбирают алгоритмы, переводящие десятичные цифры в отдельные десятичные же цифры контрольной суммы. Хотя можно выставить условие на все число сразу. Это выглядит так, как будто обеспечивают удобство ручного вычисления. Что странно.
А CRC-8 — это был сходу придуманный пример, возможно не очень удачный, того, как это 'на все число сразу' может выглядеть.
тем более после преобразования 8-и контрольных бит в 2-е контрольные цифры.
Весь первоначальный вопрос был, зачем нужно такое выделение. Я вот в примере отдельных десятичных цифр контрольной суммы не выделял — и вроде все работает.
Другое дело, что оперируя в полях по модулю 10 можно построить лучшие коды с лучшими гарантиями.
Может быть. Вот как раз это мне и не очевидно. Кроме того, что-то я не верю, что оно получается при таких простых алгоритмах, как вот тут предлагается.
CRC не от битовой последовательности строки как последовательности символов, а от битовой последовательности двоичного представления этого целого.
Те. для берем "случайное" целое '536870912'. Считаем CRC от последовательности битов CRC8(100000000000000000000000000000 BIN) = 10010100 BIN (считал тут)
Цепляем в конец и переводим обратно в целое, получая допустимый ID:
10000000000000000000000000000010010100 BIN = 1374 3895 3620 DEC. Да, я знаю, что тут не 11 цифр — просто демонстрирую идею. Если нужно именно 11 — надо будет подбирать другую функцию.
какие-либо гарантии за пакеты ошибок теряются, и получаем просто некую контрольную сумму.
К сожалению, не понял аргумента. Например, в примере выше набрали не то что надо а переставили четвертую и пятую цифры: '1347 3895 3620' (т.е. 1111101011111000100010100010110010100 BIN)
CRC8(11111010111110001000101000101 BIN) = 00110110 BIN
Что не равно 10010100, которое добавлено в конце. Можно ругаться, что при вводе допустили ошибку.
Весьма возможно, что это будет хорошо. Как раз ради этого баланса. После нескольких лет 'не будет контента' до потребителей (и посредников), которым хочется нового контента, в конце концов дойдет, что если хочешь чего-то новенького — то нужно денежку на это дать..
А если не дойдет — то это будет означать, что уже существующей музыки вполне достаточно и новой не очень-то надо.
Присоединяюсь к этому вопросу с изменением: хочется не непрерывный курсив, а рукописный шрифт 'печатного' вида. Такой, что удобно писать от руки и своим начертанием разборчивости помогает. Например, часто упоминаемый в подобном контексте чертежный шрифт близок к требуемому, но у него, как минимум, 'л' и 'п' слишком похоже. И пишется он не так чтобы очень удобно.
А теперь вспоминаем, что большая часть затрат на проект обычно приходится как раз на этап эксплуатации и поддержки, когда оригинальная команды разработки (или даже вся) во всем этом не участвует. И понимаем, что для удешевления этой части нужно каких-то других софт-скилов хотеть, не тех, что в статье написана.
Так что хотеть надо сумрачного гения документирования. Такого, чтобы если кто прочитал результат его работы — так сразу и понял, как система устроена и как ее чинить и допиливать.
С оптикой, я подозреваю, будут некие проблемы — наверняка дорогая и сложная получится. За положением взгляда, скорее всего, следить просто дешевле получится.
Но да, все то же самое делается без всяких OLED — таким же полупрозрачным экраном, на который картинку проектором проецируют.
Ну так нам для одного и нужно — того, что в кабине управления сидит и рычаги/кнопки нажимает.
Ну, сделать стерео, добавить технологию отслеживания точки зрения и поставить в качестве окна в кабине управления чем-нибудь полезным. Можно будет маркеры прямо на реальный мир накладывать. Получится Augmented Reality/HUD, но не посредством очков, а через прозрачную стену.
Вон, тут рядом рассказывают, как автоматизированную систему управления к комбайну прикручивают. Вот там такой монитор вместо окна как раз бы пригодился — ту картинку, что они на планшет выводят, показывать.
Теперь берем три случайных прилагательных из 512 самых частых (т.е. 9*3=27 бит) и получаем "шимпанзе в древней густой счастливой шляпе".
Гораздо читабельней, однозначно восстанавливается без перебора ошибок, если фразу помнишь и не нужно придумывать правила искажения.
Потому что легко найти уже ненужный и дешевый. Т.е. с большой вероятностью покупать не надо — уже где-нибудь на полках валяется. А так, конечно, можно и на более простой железке делать.
Запоминается приложением. Если очень параноить — то не запоминается, а каждый раз вводится заново.
Нигде. Они каждый раз генерируются из мастер пароля и прямо тут же введенного имени учетной записи. (Собственно, все это написано в описании CryptoPass, которым я предлагал заменить qwertycards, которые делают похожее, но ручным алгоритмом):
Ссылка CryptoPass была на f-droid. Что означает что исходники доступны. Возможно, что PBKDF2 прямо в этих исходниках нет, но тогда реализация системная и ищется в исходниках андроида или используемой библиотеки.
есть ли драйвер для смартфона чтобы прикинуться клавиатурой
Я тоже искал. Сам по себе Linux эмулировать HID умеет. Но в том же андроиде это умение с самых ранних версий выключено. Правда, когда Android Pie был на стадии слухов — были статьи, что HID эмуляция таки будет. Но ее, похоже, так и не включили.
Причем выключено, как я подозреваю, именно по соображениям безопасности — чтобы нельзя было смарт к компу подключить и быстро набрать зловредный payload через командную строку.
А так проекты с пропатченными ядрами были, но успешно заглохли. Видимо, легче на микроконтроллерах что-нибудь собрать, чем ядро коммерчески доступных смартов патчить.
Далее, как бакапить такие пароли? А то китайский смарт умер, дальше что?
В описываемой схеме бакапить надо только мастер-пароль. Который ты сам и вводишь. Т.е. бакап пароля производится до того как он в смарт попадет. Само же устройстово ничего уникального не генерит и не запоминает — в этом отличие от традиционных менеджеров паролей и это же позволяет держать устройство в вечном оффлайне.
криптостойкости сгенерированных сторонним приложением паролей (кто гарантирует вам генерацию уникальных паролей, а не выборку из 100000 паролей которые выглядят вполне случайно).
PBKDF2 вроде бы это и гарантирует.
Как обеспечить невозможность восстановления пароля путем социнженерии, взлома почты и смены симкарты
Никак. Это за пределами обсуждения. Если сервис позволяет по почте и телефону пароль сбросить и восстановить — то этот риск от способа хранения и генерации пароля не зависит.
Все преимущество — что электроники нет. В современных условиях лучше купить самый дешевый (можно даже БУ) китайский смарт, поставить на него CryptoPass, вбить мастер-пароль и генерировать пароли для сайтов в нем.
Смарт, разумеется, после инициализации никогда ни к какой сети больше не подключается.
Прямо в xkcd-ной картинке показана проблема с сознательным нарушением грамотности. Там тоже обычное слов искажали. Затруднение же не в битах энтропии, а в том, как это все потом вспомнить. Особенно для тех паролей, которыми редко пользуешься.
К сожалению, не будет легко запомнить. Пару месяцев такой пароль не используешь — и вроде еще фразу помнишь, но набрать в точности уже не можешь. Лучше уж вместо искажений на два-три-четыре слова фразу длиннее сделать.
Это становится заметно труднее запомнить. Ту часть которая "а какую именно ошибку тут сделать надо?".
Идем, скажем, на список случайных слов от EFF. В длинном списке их 7776 штуки или 12.9248… бит на слово. Чтобы набрать 128 бит энтропии нужно 10 слов. А десять случайных слов запомнить — тоже проблема.
Хорошо запоминается только грамматически правильная случайная парольная фраза. Но несмотря на целую кучу генераторов текста — я ни сумел найти ни одного, который умеет генерировать фразы с гарантированной энтропией. Всякие современные методы генерации при помощи сеток для этого, очевидно, мало подходят — там невозможно понять, насколько именно получающийся текст случайный.
Так и не надо формулировать алгоритм генерации в виде '9 случайных цифр + контрольная сумма'
Просто: ID-ом является случайное число, кратное 101 (ну или, как у меня — 109) длиной меньше 12 десятичных цифр.
И все.
Ошибку в наборе в одном знаке находим, ошибку в двух рядом стоящих — находим. Чего еще хочется?
Так мы же не в техническом канале передачи ошибки ловим (там обычно какая-то защита от ошибок уже есть), а именно при наборе. Поэтому отдельно учитывать ошибки вида "n последовательных бит" вроде бы должны быть неактуально.
Похоже, кстати, что "делится нацело на 109" — и есть алгоритм для 11-ти значного десятичного числа, гарантированно находящий ошибку в одной цифре либо одну перестановку рядом стоящих.
Тогда уж использовать 16-чное число. Только вместо цифр 'ABCDEF' использовать что-то вроде 'ABCEHK' — чтобы одновременно и латиницу не заставлять русскоязычных произносить и проблем с кириллицей для зарубежных систем не создавать.
В 11-ти значном числе, если в арифметике не ошибся, есть 99 вариантов ошибиться в одной цифре и 10 вариантов — переставить две рядом стоящие. Т.е. для гарантированного обнаружения таких ошибок валидным ID-ом должно быть каждое 109-ое число. Кажется, это означает, что двух десятичных разрядов контрольной суммы заведомо для этой задачи не хватить.
Почему не нравится? Мне все равно. Единственное, что я хотел выяснить — почему выбирают алгоритмы, переводящие десятичные цифры в отдельные десятичные же цифры контрольной суммы. Хотя можно выставить условие на все число сразу. Это выглядит так, как будто обеспечивают удобство ручного вычисления. Что странно.
А CRC-8 — это был сходу придуманный пример, возможно не очень удачный, того, как это 'на все число сразу' может выглядеть.
Весь первоначальный вопрос был, зачем нужно такое выделение. Я вот в примере отдельных десятичных цифр контрольной суммы не выделял — и вроде все работает.
Может быть. Вот как раз это мне и не очевидно. Кроме того, что-то я не верю, что оно получается при таких простых алгоритмах, как вот тут предлагается.
CRC не от битовой последовательности строки как последовательности символов, а от битовой последовательности двоичного представления этого целого.
Те. для берем "случайное" целое '536870912'. Считаем CRC от последовательности битов CRC8(100000000000000000000000000000 BIN) = 10010100 BIN (считал тут)
Цепляем в конец и переводим обратно в целое, получая допустимый ID:
10000000000000000000000000000010010100 BIN = 1374 3895 3620 DEC. Да, я знаю, что тут не 11 цифр — просто демонстрирую идею. Если нужно именно 11 — надо будет подбирать другую функцию.
К сожалению, не понял аргумента. Например, в примере выше набрали не то что надо а переставили четвертую и пятую цифры: '1347 3895 3620' (т.е. 1111101011111000100010100010110010100 BIN)
CRC8(11111010111110001000101000101 BIN) = 00110110 BIN
Что не равно 10010100, которое добавлено в конце. Можно ругаться, что при вводе допустили ошибку.
Весьма возможно, что это будет хорошо. Как раз ради этого баланса. После нескольких лет 'не будет контента' до потребителей (и посредников), которым хочется нового контента, в конце концов дойдет, что если хочешь чего-то новенького — то нужно денежку на это дать..
А если не дойдет — то это будет означать, что уже существующей музыки вполне достаточно и новой не очень-то надо.