Ну, сделать стерео, добавить технологию отслеживания точки зрения и поставить в качестве окна в кабине управления чем-нибудь полезным. Можно будет маркеры прямо на реальный мир накладывать. Получится 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, которое добавлено в конце. Можно ругаться, что при вводе допустили ошибку.
Весьма возможно, что это будет хорошо. Как раз ради этого баланса. После нескольких лет 'не будет контента' до потребителей (и посредников), которым хочется нового контента, в конце концов дойдет, что если хочешь чего-то новенького — то нужно денежку на это дать..
А если не дойдет — то это будет означать, что уже существующей музыки вполне достаточно и новой не очень-то надо.
Непонятно, почему контрольные цифры отдельно, а само число — отдельно. Нужно ведь только чтобы не каждое из 10^11 чисел подходило, а приблизительно каждое сотое. Это можно и в другом виде формулировать. "Должно являться корнем функции...". А функция пускай хоть с отдельными битами работает и логарифмы вычисляет.
Гораздо интереснее, почему такие алгоритмы, работающие на основе написания, выбираются.
Можно же взять бинарное представление десятичного числа, вычислить какое-нибудь CRC-8, прицепить (или даже перемешать) его с исходным числом, снова записать в десятичном виде — и готово число со встроенной контрольной суммой.
Или я ошибаюсь и ничего хорошего из этого не получится?
А стараниями текущего поколения разработчиков теперь ко всему этом добавиться еще и рой микросервисов, про который никто не будет знает, как он работает (вот нигде не видел, как сделать так, чтобы все это оставалось понятным и лет так через 10). Упадет рой — и обратно подняться не сумеет, потому что какой-нибудь конфигурационный сервер начальной раскрутки, что нужен несколько раз за жизнь системы, давно умер.
Причем рой именно добавиться, а не придет на замену — старую же систему целиком на новую архитектуру перенести не сумеют.
Когда проект достаточно большой и достаточно старый — с объяснениями проблема. Потому что в нем появляются части, в которые никто из имеющихся на проекте ни разу не заглядывал. А чуть позже появляются и части/инструменты/функционал, про существование которых никому неизвестно.
Ну, сделать стерео, добавить технологию отслеживания точки зрения и поставить в качестве окна в кабине управления чем-нибудь полезным. Можно будет маркеры прямо на реальный мир накладывать. Получится 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, которое добавлено в конце. Можно ругаться, что при вводе допустили ошибку.
Весьма возможно, что это будет хорошо. Как раз ради этого баланса. После нескольких лет 'не будет контента' до потребителей (и посредников), которым хочется нового контента, в конце концов дойдет, что если хочешь чего-то новенького — то нужно денежку на это дать..
А если не дойдет — то это будет означать, что уже существующей музыки вполне достаточно и новой не очень-то надо.
Непонятно, почему контрольные цифры отдельно, а само число — отдельно. Нужно ведь только чтобы не каждое из 10^11 чисел подходило, а приблизительно каждое сотое. Это можно и в другом виде формулировать. "Должно являться корнем функции...". А функция пускай хоть с отдельными битами работает и логарифмы вычисляет.
Гораздо интереснее, почему такие алгоритмы, работающие на основе написания, выбираются.
Можно же взять бинарное представление десятичного числа, вычислить какое-нибудь CRC-8, прицепить (или даже перемешать) его с исходным числом, снова записать в десятичном виде — и готово число со встроенной контрольной суммой.
Или я ошибаюсь и ничего хорошего из этого не получится?
А стараниями текущего поколения разработчиков теперь ко всему этом добавиться еще и рой микросервисов, про который никто не будет знает, как он работает (вот нигде не видел, как сделать так, чтобы все это оставалось понятным и лет так через 10). Упадет рой — и обратно подняться не сумеет, потому что какой-нибудь конфигурационный сервер начальной раскрутки, что нужен несколько раз за жизнь системы, давно умер.
Причем рой именно добавиться, а не придет на замену — старую же систему целиком на новую архитектуру перенести не сумеют.
Когда проект достаточно большой и достаточно старый — с объяснениями проблема. Потому что в нем появляются части, в которые никто из имеющихся на проекте ни разу не заглядывал. А чуть позже появляются и части/инструменты/функционал, про существование которых никому неизвестно.