Как стать автором
Обновить

Комментарии 147

Кул, как мне воспользоваться этой хреновиной, чтобы ввести пароль на моем iPad?

(заодно еще — как ввести пин на пинпаде и пароль на терминале в интернет-кафе, где любые внешние устройства заблокированы)
HID — блокируется редко и не требует дополнительного драйвера. Для iPad — можно вот так.
Можно сделать из токена usb-клавиатуру, а далее вручную ставить курсор для ввода пароля в нужное поле и отправлять команду с смартфона.

К сожалению это не решает вопросы с троянами: с
HID — блокируется редко и не требует дополнительного драйвера.

Иногда заблокированы все (прописью: все) внешние подключения. Просто портов нет физически. Я уж молчу про пинпады.

Для iPad — можно вот так.

А как Camera Connection Kit в этом поможет?
Camera Connection Kit — позволяет работать с usb-клавиатурой.
Круто!
К iPad можно подключать внешние клавиатуры.
USB-hid поддерживается почти везде. На текущий момент это самый универсальный способ ввода паролей без установки софта.
Android, IPhone, WinPhone поддерживают usb-hid. Кто-то усложняет эксплуатацию универсальных переходников за счет инновационных разъемов, но суть одинакова.
Кстати, никто не задал вопрос «Как ввести пароль на сам телефон, с которого он отправляется?». Я предусмотрел и это, добавив задержку ввода пароля.

Пинпады.
Там короткие цифровые пароли. Их легко вводить.

Пароль на терминале в интернет-кафе.
Если часто приходится с этим иметь дело, то можно один раз дома задать VID и PID клавиатуры в интернет кафе.

Т.е. вы хотите использовать аппаратное устройство, предназначенное для максимальной защиты, чтобы в итоге вводить пароль в общественном месте? Не надо так...

Нет, я хочу знать, как мне решать мои типовые сценарии использования.

Интересная штуковина. А какая примерная стоимость девайса?
К сожалению, не было возможности добавить опрос в песочнице.
Цена очень сильно зависит от размера партии и используемых компонент.
Сейчас мы выбираем между двухслойной и четырехслойной платами, а так же между дорогим bt модулем и дешевым, но менее качественным.
Если наберется людей на небольшую партию, то мы сможем определить примерную стоимость конечного устройства.

А зачем делать отдельное устройство? Приобрести usb-bluetooth и эмулировать клавиатуру на сотовом телефоне (меня бы устроил такой порт между android keepass и pc)
Вы же знаете как работает встроенное шифрование bluetooth, да?
Спарринг можно подделать за 7 секунд(при 6-символьном пароле), а пароли читать вообще без этого.
Кстати, уже придумал как вам малварь на комп закинуть с такой системой
1) получаем MITM доступ
2) кидаем набор управляющих символов для открытия блокнота, написания скрипта и сохранения его
3) запускаем с нужными правами
4) получаем бэкдор или_что_нам_там_нужно
Сходу не нашел нормальной статьи, подскажите ключевые слова или ссылку, везде мне попадаются описания старых проблем 200x года
Повторю вопрос по конкретнее — достаточно ли надежно использование bluetooth 4.x версии, пусть содержимое трафика дополнительно шифруется, меня главное интересует спаринг устройств и минимальная защита от ддос.
Я не знаю как именно работает ваше соединение, но в описании было написано >стандартный ввод Bluetooth
Вот первая более-менее адекватная статья последовательности действий в Kali, чтобы поломать bluetooth протокол клавиатуры.
null-byte.wonderhowto.com/how-to/hack-bluetooth-part-1-terms-technologies-security-0163977
Я не гарантирую ее полную верность, но точно помню отличные старые лекции, когда ломали клавиатуры по 30-ти нажатиям. Надо понимать, что шифрование не изменилось.
Работа со специализированными крипточипами, как это делают токены аутентификации, возможно, тоже будет. Как за счёт кастомных прошивок, так и за счёт выпуска специальных версий устройства. Всё зависит от степени интереса сообщества к девайсу.
Чем «hash(pass+user_id+salt)» менее устойчивее, чем «hash(hash(pass)+user_id+salt)»?
конкатенация пароля и ID может повторяться для разных пар «пароль — ID». Например: «mypass!!» + «1138» и «mypass!!1» + «138».
Для обхода такой проблемы оптимальнее выравнивать user_id по длине, чем с помощью hash-а уменьшать размерность. Соответственно, будет «mypass!!_1138» и «mypass!!1__138».
Данная проблема отсутствует, если в качестве user_id используется guid.
>>Для обхода такой проблемы оптимальнее выравнивать user_id по длине, чем с помощью hash-а уменьшать размерность.

Что значит — оптимальнее? Хэш здесь не для размерности, не для удобства, а для безопасности. Похожая конструкция используется и в HMAC, например. Универсальный совет «хэшировать секрет перед конкатенацией с чем угодно» проще, чем набор советов «используйте uid», «выравнивайте поля» и т.д.

Проблема, разумеется, вообще отсутствует, если для для хэширования паролей использовать специальные алгоритмы типа bcrypt, scrypt
Как и Cardberry, Вы полагаетесь на bluetooth. Но bluetooth сам по себе является дырой, его отключить скорее правило, чем исключение.
Можете пояснить, в каком именно месте bluetooth ненадежен?
[del]
Извиняюсь, я забыл, что удалять комментарии нельзя. А хабр перестал давать возможность отвечать в одном из комментариев, решил проверить, что могу еще постить
При работе с bluetooth я исхожу из предположения, что это полностью открытый для прослушки канал. Именно поэтому я шифрую трафик. Я не полагаюсь на безопасность bluetooth.
Я не об этом. Открывая на своём телефоне блютус, я сам телефон подвергаю опасности. Вне всякой связи с Вашим дополнением.
какая именно опасность? речь идет о дефолтных паролях (пинах, которые можно сменить) или о чем то более серьезном?
http://4pda.ru/forum/index.php?showtopic=678302 как пример.Но если Вы специалист в области безопасности, я с удовольствием приму от Вас заверения о том, что блютус абсолютно безопасен.
большинство этих багов оборудования а не протокола:
Bluebugging — Bluetooth class 2, 2004г
BlueSmack — DoS с помощью пинга болшими пакетами
BlueSnarf — это использование багов устройств а не протокола! 2003г. wiki: After the disclosure of this vulnerability, vendors of mobile phone patched their Bluetooth implementations and, at the time of writing, no current phone models are vulnerable to this attack
Bluesnarf++ — так же это баг устройств а не протокола (собственно эти две уязвимости используют то что по умолчанию устройства не требуют запроса подтверждения на получения некоторых данных и как я понял даже на уязвимых устройствах это настраивается)
HeloMoto — Bluesnarf исключительно под мотороллу,

BlueDump — серъезный баг, позволяет определить пин в момент создания соединения, если знать mac атакуемого и иметь возможность вклиниться (подменить) в создаваемый pairing с кем то еще (по ссылке кто то даже заявил что успешно 'взломал' соединение с android 4.4) я пока не нашел информации как от него можно защититься, и хотя условия этого взлома сложны полагаю опасность достаточно велика
BlueDump attack

In this case the attacker needs to know the BDADDR of a set of paired devices. The attacker spoofs the address of one of the devices and connects to the other. Since the attacker has no link key, when the victim device requests authentication, the attacker’s device will respond with an ‘HCI_Link_Key_Request_Negative_Reply’, which will, in some cases, cause the target device to delete its own link key and go into pairing mode.
много 'А' и восклицательный знак.
Я так понимаю если программа на устройстве наша, то мы можем так не делать!
Да какая разница, чей баг, если с включённым блютусом телефон становится уязвимым. Ну или более уязвимым чем без него. Были же даже охотники за блютусами http://www.nestor.minsk.by/sr/2005/06/sr50616.html.
огромная, уязвимы не bluetooth протоколы, а устройства!
мы говорим о разработке устройства и программы, соответственно мы будем отвечать за безопасность а не протокол bluetooth!
Я пытаюсь донести, что при открытии на телефоне блютуса, с целью соединяться с системой безопасности, на телефоне открывается дополнительная дыра. Это никак не связано с конкретным применением, это просто свойство телефона — если есть протокол, воспринимающий внешне сигналы, телефон становится уязвим. Телефон уязвим. В нём появляется маленькая дверца для хакера. Поэтому использовать блютус нельзя.
Собственно говоря, есть же и другие проблемы с ним, о которых писали ниже, так что поиск альтернативы совсем не вредное занятие.
У меня встречный вопрос, какую опасность имеет использование телефона в режиме прослушивания а не сервера? сервисы не поднимаются, через что телефон будет атакован?
Мне кажется, что наличие смартфона — избыточность. Может хватить устройства и программы. Каждый смартфон это как минимум +3 версии программы под каждую ось. Можно говорить, что смартфон — незаменимое устройство, которое всегда в руках, но однажды забыв его теряешь доступ к паролям. Разрядив? То же самое. Кажется эти мелкие минусы перевешивают плюсы. имхо, конечно.
Мне кажется это мЕньший минус, чем таскать за собой еще одно устройство. Причем достаточно большое — чтобы на нем был какой-то экран + заряжать его.

При утере телефона база как я понял остается на большом компьютере.
Хорошее замечание, но наличие смартфона все-таки оправдано.
1) Он значительно удешевляет производство, так как не надо задумываться о выводе информации пользователю. Делать экран на устройстве сложно, дорого и менее удобно.
2) >Может хватить устройства и программы
Возможно, вы не совсем поняли необходимость программы. Программа на компьютере лишь служит для записи данных на устройство и телефон. Она не нужна на компьютере, на который мы вводим пароль.
3) >Разрядив
Да, но вы вводите пароль на компьютер. Значит источник питания у вас рядом. Как минимум это не безвыходная ситуация. Но разряженный телефон затруднит ввод

Смартфон помогает увеличить как удобность, так и безопасность. Удобность в плане способа управления устройством(не надо лезть к самому usb порту, чтобы ввести новый пароль, например), а безопасность в плане, что пароли невозможно будет достать, имея только одно устройство + мастер-пароль.
1. Страдает только стоимость производства. Удобство может и не страдать — узкая e-ink полоска и одна-две кнопки для выбора из списка.
2. Исходя из пункта 1: конечное устройство убирает из цепочки смартфон.
3. Это серьёзная ошибка — предполагать, что источник питания всегда рядом.

Идея крутая, чёрт подери! Но она строится на таком количестве «если», что они нивелируют всю цену этой идеи. Учитывая такое количество входящих условий, можно рассмотреть аналогичный вариант: флешка-токен с keepass и файлом паролей в облаке. Ключ привязан к железке и учётке. Украли токен — никакого вреда. Украли мастер-файл из облака — без компа и токена ломать будут долго. Украли комп — ховайся. И устройств меньше и телодвижений.
1. Страдает только стоимость производства. Удобство может и не страдать — узкая e-ink полоска и одна-две кнопки для выбора из списка.

В этом случае украденный токен означает утекшие пароли, разве не так?
3. Это серьёзная ошибка — предполагать, что источник питания всегда рядом.

Источник питания — USB порт куда вы хотите воткнуть девайс, что не так то?
Поглядел ролик. Это ж сколько лишних действий нужно сделать: воткнуть usb-стик, запустить приложение на смартфоне, ввести пароль, найти нужный пароль в списке, прокликать… И это вместо того, чтобы просто ввести пароль.

Плюс, вся эта завязанность на смартфоны, мягко говоря. не радует. Все еще есть люди, которые ими не пользуются по тем или иным причинам.
Не все пользуются одинаковыми и/или легко запоминающимися паролями, «чтобы просто ввести пароль».
Проще запомнить несколько достаточно стойких паролей, чем полагаться на эдакие часы с кукушкой.

А для всякой ерунды со случайными паролями, проще использовать шифрованный gnupg текстовичок, синхронизируясь через тот же syncthing и при надобности его грепать. Ну, я как-то так это вижу.
Несколько? Специально открыл свой менеджер паролей. У меня в нем на данный момент 429 записей.
Вопрос, насколько часто они все используются. А так,
$cat $files/pw.gpg|gpg -d|wc -l
...
632


У меня часто используется аж три пароля: на дешифровку lvm лаптопа, разброкировку экрана и к ssh-agent'у.
У меня очень серьезные опасения по поводу безопасности протокола передачи данных. В моем случае первые пароли задаются по гарантированно шифрованному каналу. Здесь, в лучшем случае, используется ассиметричное шифрование. А, скорее всего, plain text.
На сайте ни слова о безопасности, что настораживает.
Я бы посоветовал послушать bluetooth трафик. И если там plain text, то либо заменить систему, либо держать ее в тайне.
На сайте достаточно много данных об этой разработке, в том числе о шифровании.
InputStick uses encrypted Bluetooth connection. Protocol allows to use additional AES-128 encryption (CBC mode).

Но на всякий случай Bluetooth трафик послушаю, спасибо.
НЛО прилетело и опубликовало эту надпись здесь
Зависит от способов использования. Например, если вы работаете за одним рабочим местом, то провести этот набор действий необходимо будет лишь один раз по приходу на него. Если вы администрируете что-либо, то вводить пароли приходится разные и по несколько раз.
Для ssh есть, конечно, ключи. Но не из под рута же работать на машинах.
Предполагается, что телефон просто лежит на столе, а на телефоне запущено приложение(оно имеет сервис, который совсем не тратит энергии).
В сервисе уже разблокированная база(повторно мастер-пароль вводить нет необходимости) и надо лишь совершить долгое нажатие на нужный пароль из списка.

У вас интересная идея, но она будет очень зависеть от того где находится компьютер и его usb-порт. Но даже если предположить, что протянут удобный провод, то все равно придется запоминать комбинации для всех сервисов.
Так же не стоит забывать, что люди очень плохи в генерации случайных событий. И однозначно будут частоиспользуемые комбинации.
Это значительно упростит перебор. А еще не стоит забывать о камерах наблюдения и разводах на стекле.
Я всегда исхожу из предположения, что устройство могут украсть, поэтому соль известна злоумышленнику.
НЛО прилетело и опубликовало эту надпись здесь
>и это самый реальный вектор атаки
нет. Просто его обычно используют, т к альтернатив нет. Моя цель — не понизить безопасность ввода с клавиатуры.
>С чипа ничего просто так не прочитать, если стоят биты защиты, ценник на такую операцию астрономический с риском все испортить
Подпаяйтесь к чипу и читайте как белый человек. Паяльник, чья-то мать и коленка сделают свое дело. Это не сложно.
Да и не забывайте, что если оно внутри зашифровано, то пароль хранится в той же памяти!
>на донгле не написано, к каким учетным записям он
перебрать 30 паролей или перебрать 15^76!? Я бы выбрал 30.
>юзабилити устройства
1) Приходите на рабочее место
2) втыкаете донгл
3) запускаете приложение в телефоне(1 раз за день)
4) необходимо ввести пароль — тыкаете в телефоне нужный
Все. Я тестировал продолжительное время. Лишних действий минимум. Получалось быстрее, чем вводить руками(включая разблокировку телефона и поиск пароля)

Ну и про донгл.
Даже если вы надеетесь, что мастер-пароль вас спасет, то в голове все равно будет сидеть мысль, что «а что, если таки узнают мой мастер-пароль и все пароли будут скомпрометированы».


Самодельная криптография и Bluetooth отпугнут любого параноика, даже если там всё на самом деле 100% надёжно.
Я бы не назвал это самодельной криптографией. Используется AES256. Его я не трогаю и уважаю. Но ключи для него я меняю часто.
По факту, нового тут только изменение ключей в каждом пакете. То, что начальные пароли шифрования задаются с компьютера, это лишь один из простейших способов передачи ключей собеседникам. Обычно эта часть и является проблемной. Но я это делаю напрямую и в защищенной среде. Это не новый подход(к сожалению, не смог с ходу загуглить. Но как пример — передать пароли при личной встрече Алисы и Боба)
Единственное, что ново это смена ключей. Так как передаются лишь новые ключи, то никаких взаимосвязей с текущим шифрованным сообщением быть не может. Это всего-лишь кусок данных
Я далёк от криптографии, что-то ответить сложно. Протокол обмена ключами, то какие вы применяете алгоритмы, как и из каких библиотек, где и как храните ключи, и т.д., всё это самодельное. И должно пройти ультрапараноидальный аудит.

Вот, кстати, в тему: https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2009/july/if-youre-typing-the-letters-a-e-s-into-your-code-youre-doing-it-wrong/

PS; Я и телеграмом не пользуюсь, там вообще всё самодельное.
-вообще всё самодельное.
У меня для вас плохие новости. Весь мир — самодельный. Кто-то что-то создал (самодельно).
Спасибо за ссылку на статью, она мне очень понравилась. Но хочу заметить, что там нет действительно «неожиданных поворотов». Лично для себя я нашел лишь одно место, которое меня удивило. Но оно специфично для решаемой там задачи(меня удивила простота, с которой осознанно меняли байты в следующем блоке при CBC). Но несмотря на то, что не знал, что это делается так просто я все же защищался и от рандомно измененных битов, добавив проверку целостности с HMAC по sha256.

Обмен ключами не самодельный. Они уже оказываются у собеседников при инициализации коннекта.
Алгоритмы шифрования я не придумываю. Я беру готовые опираюсь на то, что они гарантируют.
Код открыт и все используемые библиотеки доступны всем. Я не нашел упреков их надежности, но если кто-то авторитетный(любой криптограф) скажет, что стоит использовать другую библиотеку, то я это исправлю ASAP.
Ключи хранятся в шифрованном хранилище. Создаю ключи, используя соленый хэш от мастер-пароля. Пожалуй, это единственное место где я сделал что-то свое. Но нигде эти хэши я открытыми не держу в лбом случае. Я их только генерирую и использую. Там нет необходимости в защите от перебора даже.

Спасибо за ссылку. Жаль, что вам нельзя повысить карму.
Создаю ключи, используя соленый хэш от мастер-пароля. Пожалуй, это единственное место где я сделал что-то свое.
не надо «свое» когда есть PBKDF2
>в описанном протоколе есть таки логическая уязвимость

Я не совсем понял про символы, описывающие векторы атаки.
Но, в текущем протоколе есть, как минимум, проблема доставки первых ключей BtKey[i] и HBtKey[i] на PSD.
Плюс, в случае, если связь между устройствами рвётся (6 пункт генерирует, а отправляет аж на 9 пункте, после замены ключей на PSD), на PSD перезаписываются новые ключи, оно пытается отослать респонс на телефон, и у него не получается.
В этом случае будет рассинхронизация, так как в следующий раз телефон отправит тоже BtKey[i+1] и HBtKey[i+1] вместо BtKey[i+2] и HBtKey[i+2], зашифрованные на BtKey[i] и HBtKey[i]. А PSD будет пытаться расшифровать их уже на обновлённых ключах BtKey[i+1] и HBtKey[i+1]

Таким образом, как минимум нужно местами шаги алгоритма переставить, или добавить механизм, который будет этот момент учитывать.
Мне тоже показалось странным, что старые ключи удаляются не в 10 пункте а уже в 7м. Но это, наверное, уязвимостью не назовешь.
>проблема доставки первых ключей BtKey[i] и HBtKey[i]
Первая картинка(шаг 1)
Первые ключи это BtKey0 и HBtKey0. Они записываются самым безопасным возможным способом — общим распространителем.
То есть они попадают на оба девайса при записи туда баз.
>6 пункт генерирует, а отправляет аж на 9 пункте
Так и задумано. Ввод производится относительно долгое время(секунд 5 для длинных паролей) и надо предотвратить возможность выдернуть устройство до смены паролей на новые. Поэтому, пароли надо заменить как можно раньше и стереть старые. Но мы отсылаем хэш старого пароля(HBtKey) обратно. Если мы его сотрем, то не сможем потом сгенерировать ответ. Поэтому генерируем сразу и удаляем пароли.
>связь между устройствами рвётся
да, есть такой кейс. Именно для этого на телефоне предусмотрен таймаут ответа. Если он превышен, то вылезает занятное окошко, описывающее ситуацию и предлагающее пользователю прокрутить ключи или оставить как есть. Прокрутить надо, если пароль был введен.

К сожалению, я не могу описать все в одной статье. Но это хорошее и логичное замечание!
Статья интересная. Большинство воров паролей и вымогателей рассчитаны на самого безграмотного юзера, которых «золотые» 95%. Если вы не владеете крупным бизнесом и большими деньгами то прицельно вас ломать никто не будет. Сухое кривое дерево никто не срубит. Зато паранойя очень быстро загонит вас на больничную койку или вообще в могилу, т.к. постоянная тревога является крайне ресурсоемким процессом. Она и физически истощает тело и ворует процессорное время вашей думалки, а повышенный эмоциональный фон еще и сделает мышление крайне однообразным и плоским.

Осталось только думалку в этом убедить :)
Зато удовлетворение этой самой паранойи приносит людям море удовольствия как я посмотрю :)
Успешное решение проблем вообще дает хороший гормональный «допинг», причем это эволюционное свойство мозга. Но эволюция нас не готовила к жизни в городе. Это свойство лежит в основе игровых зависимостей. Побеждаешь врагов в танках а мозг заливает медиаторами «системы поощрения».
Поддержку TOTP / HOTP для двух-факторной авторизации, как я понимаю, вы планируете решать возможностью запуска кастомных прошивок?

Телефон отправляет свою половину секрета. Устройство комбинирует её со своей.
Но вместо того, чтобы отправлять результат на вывод, использует его для генерации TOTP и «печатает» уже его.
К сожалению, я не могу решать все задачи сразу. Сейчас я решаю лишь проблему ввода символьных паролей.
Я полагаю, что места где используются TOTP / HOTP для двух-факторной авторизации уже имеют своих специалистов по безопасности, которые не особо будут довольны подобной самодеятельностью.
Да ведь тот же Google Authenticator, FreeOTP, Authy — все они используют TOTP.
Т.е. двух-факторный логин в GMail — это уже «место, где используется TOTP». О каких «специалистах по безопасности» речь?

Кстати, в этом контексте было бы удобно, чтобы password_part_2 и totp_secret_part_2 были как-то проассоциированы в программе на телефоне. Чтобы можно было выбрать один пункт («логин в GMail»), и телефон сам сначала отправил (через PSD) пароль, а потом, после небольшой задержки, и TOTP-код.
Я думал, что речь идет о брелках с одноразовыми паролями.
В принципе, можно реализовать этот функционал. Но там достаточно простые пароли высылаются(6 цифр) и их просто набрать.
А вот пароли с кучей символов и в разных регистрах набирать проблематично.
Проблема с ними не в наборе, а в доступе к этому коду: включить телефон, разлочить, открыть список приложений, запустить программу, тапнуть на учётной записи, чтобы увидеть код.

Если использовать PSD для ввода «пароля с кучей символов в разных регистрах» для GMail, логично было бы и TOTP-код вводить с помощью PSD, а не запускать для него отдельную программу.
Да, это реально. Но не все сразу, к сожалению. Но если после запуска кто-нибудь захочет помочь реализовать подобный функционал, то я буду лишь только за.
1. Зачем Вам менять HBtKey в каждом сеансе? Он Вам нужен только для того, чтобы PSD удостоверялся в смартфоне (хотя и это непонятно зачем, только разве как защита от DoS). Сгенерируйте его на MASTER_PC и не меняйте.

2. Вопрос синхронизации счетчиков PSD и смартфона, обсуждавшийся в комментах выше, нетривиален. Любая потеря пакета хоть в прямом хоть в обратном направлении приводит к рассинхронизации — не важно 3-WAY-CLOSE или 4-WAY-CLOSE. Мне кажется, необходимо более детально прорабатывать этот вопрос.
1. Я отсылаю обратно старый HBtKey, чтобы подтвердить, что пароль действительно был введен успешно. Вы правы, что менять его каждый раз нет необходимости, но это не уменьшает безопасность системы и мы имеем что отправлять как респонс.

2. Выше я уже отвечал, но уже после вашего комментария. Там есть способ разрешения таких проблем
>связь между устройствами рвётся
да, есть такой кейс. Именно для этого на телефоне предусмотрен таймаут ответа. Если он превышен, то вылезает занятное окошко, описывающее ситуацию и предлагающее пользователю прокрутить ключи или оставить как есть. Прокрутить надо, если пароль был введен.
К сожалению, я не могу описать все в одной статье.
Классная штучка. Мне нравится. Я бы даже купил.

Идеи:
1. Не «перейти на формат KeePass», а реализовать плагин для KeePass(2), чтобы можно было сразу из кипасса заливать все на psd и телефон (без вашей программы для пк). Заодно и (почти) готовая поддержка для всех (win, lin, mac) платформ.

2. В программе для телефона должна быть возможность ввести определенные символы, которые будут отправлены PSD на комп. Суть в том, что в последних версиях касперского (например, в KES 10.2.4.674) появилась защита от атак BadUSB. Когда подключаешь USB-клаву, появляется окошко каспера, в котором написано несколько символов и поле для ввода этих символов. Пока не введешь именно с подключенной клавы указанные в окне символы, каспер не позволит использовать эту «клавиатуру».

3. В программе на телефоне сделать возможность вводить ПИН, а не целый пароль каждый раз. Например, если пин ввели 3 раза не верно, то сохраненный (зашифрованный) пароль удаляется и уже надо будет ввести весь пароль целиком. Хотя не знаю, возможно ли это сделать так, чтобы сам пароль хранился на телефоне безопасно (т.е. чтобы не пином его шифровать).

4. На самом PSD сделать не только USB папа, но и USB мама и пропускать все через себя. Идея такая: если послана с телефона команда, эмулируем ввод с клавы, в остальных случаях просто пропускаем коды от клавиатуры. Можно дополнительный девайс сделать, специально для постоянного подключения к ПК.

5. Как и в п.2 можно сделать под. девайс (psd) с usb и microusb разъемами. Хотя, есть переходники. Правда я не знаю, как андройды себя поведут.

6. Конечно, от клейлоггеров ваш девайс не защитит… Но все же, думаю, можно реализовать какую-никакую защиту в виде «посылки мусора», который генерируется случайным образом или, хотя бы, псевдослучайным. Например, надо ввести пароль «Pas$W0rD_». Можно вводить не символ за символом, а, например, так (в <> указаны клавиши клавиатуры):
P$W<left><left>as<end>De<left>t<del><left><left>0r<end><shift+left>_

7. Добавить поддержку OTP. Т.е. чтобы не только основной пароль можно было ввести, но и одноразовый пароль. Например, для входа в gmail.
Пробовали вчера на Андроиде через OTG-кабель USB-OTP-брелок, который тоже представляется как HID-устройство (по нажатию на кнопку выдает 6 цифр HOTP как клавиатура) — в принципе работает нормально, вот только пришлось на телефоне настраивать, подавать ли питание и сколько миллиампер. Без этого — брелок постоянно то отключался то подключался снова.
1. Мы еще рассматриваем альтернативы. Возможно, будет и то, и то.
2. Да, достаточно добавить еще один тип пакета
3. Еще удобнее. Есть политики хранения пароля. В идеале, пароль вводится один раз в день(или реже). Можно сделать, чтобы пароль сбрасывался каждые 30 минут. Обычно, подключение к базе висит в сервисе(не кушает заряда совсем).
4. А зачем? Это усложнит подключение устройства. Или это способ решить 2-й пункт?
5. Да, есть очень мелкие и удобные переходники. Андроид ведет себя с ними хорошо, все работает отлично, я проверял.
6. Я не думаю, что это усложнит задачу хакеру
7. Одноразовые пароли очень просты. У гугла это 6 цифр. Их ввести просто и быстро. PSD же позволяет автоматически вводить пароли, которые заняли бы много энергии и концентрации.
1. Это будет очень здорово. Держать базу в кипасс и в любой момент иметь возможность скинуть ее на psd, это будет супер! )))
2. Просто без этой «фишки» девайс работать не будет, если на компе есть защита от badusb.
3. Ну… Лично мне не хочется держать базу открытой постоянно (понимаю, что из нее пасс не достать, но все же, паранойя). А каждый раз (по истечении, например, тех же 30 сек) вводить полный 20+ символьный пароль не очень удобно.
4. Нет. Это как доп. фишка. Аля, аппаратное хранилище. Например, на работе подключил клаву и девайс и пусть себе живут, и лишний раз порт не занимает. Или дома… У меня к ноуту монитор подключен и клава… Портов мало. А так целый порт экономить можно. Туда-сюда psd дергать тоже не очень хочется.
5. Здорово!
6. Профику не усложнит. Но от скрипткиддиса или коллеги-недоброжелатя вполне может спасти. Хотя понимаю, что реализовать такой алгоритм не очень просто (я с ходу себе представить на уровне кода не могу). Можно не в самом psd это сделать, а в программе на телефоне, чтобы она уже готовый набор действий сообщала psd.
7. Это как доп. фишка. Менеджер паролей + otp. Можно еще таймер прикрутить: ввели пароль, нажали энтер, подождали, например, 3 секунды, ввели otp (должно быть настраиваемо). Все же это проще и удобнее, чем самому вводить otp.

Еще мысль пришла:
8. На psd сделать одну кнопку, при нажатии которой будет вводить пароль «по умолчанию». Удобно будет для ввода пароля от чего-нибудь, что часто используешь. Если телефон рядом, то вводим, если нет, то не вводит. Так же в программе на телефоне можно профили реализовать: профиль настраивает поведение кнопки и позволяет быстро его (поведение) изменить.

PS: Это просто предложения. Возможно что-нибудь вам покажется дельным и решите добавить в планы.
3. База не открыта, но в памяти. И к ней нет прямого доступа. Если нет рута на телефоне, то бояться вообще нечего, так как оперативную память чужих приложений без рута читать нельзя(вроде как). Пароль нужен больше для того, чтобы кто-то не мог у вас телефон и девайс забрать, а потом сделать все через разблоченое приложение. Но вообще там разные политики сброса предусмотрены. Например, при закрытии приложения.
Вообще, нет смысла 20+ символов иметь именно на эту базу. Сам по себе слитый пароль от базы ничего не даст даже при краже одного из устройств. Но открывает огромное количество векторов. Например, незаметное чтение базы с PSD используя зараженный FOREIGN_PC.
Я считаю, что хватит и 8+ символов(буквы разных регистров, цифры и символы) для защиты от перебора. Но это личное дело каждого, конечно.
Гораздо проще «не позволить украсть два девайса при разлоченной базе».
С пинами я подумаю, конечно. Но я не уверен, что это возможно при такой постановке задачи. Ибо пины обычно используют в системах, чью память просмотреть нельзя
4. Мы сейчас очень стараемся понизить стоимость устройства. Но я обсужу с коллегой, который занимается железом.
6. Закодить не сложно, но это замедлит ввод. Да и я не очень представляю как это защитит от человека, который глазами будет просматривать все нажатые символы.
7. Надо OTP уже размышляем. Сделать можно, конечно.
8. Тут проблема в том, что скорее всего придется хранить этот пароль в целом виде на PSD. Или с psd запрашивать вторую часть, что немного ломает парадигму клиент-сервер.
Да и предполагается, что телефон находится удобнее, чем psd.
Вот что действительно может помочь, так это всякие виджеты. Например, на экран блокировки. Приложение уже работает в сервисе и позволяет использовать несколько клиентов когда база разблокирована. Вообще, удобство — не проблема. Оно только звучит сложно, при тестировании все работало очень удобно(старался быть объективным)

Спасибо за предложения. Конструктивный фидбэк всегда приятен!
3. Что память без рута не прочитать, я знаю. Я говорил именно о случае, когда кто-то взял телефон в руки и залез в базу. Так сказать, привычка ставить пины на такого рода программы. Хотя понимаю, что в данном случае особо ничего не сопрут (т.е. без девайса пассы мои не вытащат). С другой стороны даже 8 символов, типа f7H_0.'2 вводить каждый день куда ленивее, чем 7820 каждые 10 минут ;) Думаю, сам пароль можно будет шифровать по типу серийник_телефона + мак_вафли + пин + что-то_еще_из_статического.
4. Можно сделать 2-3 разных версий устройства. Хочешь доп. фишки, плати больше ;-)
6. На мой взгляд, не так то и сильно скорость замедлится. В любом случае будет быстрее, чем ручками 20-40 символов вводить. Я понимаю, это конечно защита от дурака, но и не каждый будет логи кейлоггера изучать скрупулезно. Это просто полет мысли.
8. Кстати, да, согласен. Можно виджеты сделать на телефоне. Или даже 2-3 кнопки в самой программе, чтобы доступ к ним сразу при запуске был без лишних телодвижений. Лично я кнопку на psd представляю так: зашел в серверную, воткнул psd в порт, нажал кнопку, ОСь разблокировалась, вынул psd, делаешь свою работу. А телефон это время, как обычно, просто в кармане лежит. Т.о. не два, а один девайс из карма доставать.
Не, на psd не вариант хранить, т.к. девайс же без автономного питания, поэтому «на ходу» не поставить профиль (т.е. какой пароль на кнопку повесить), нужно будет обязательное подключение psd к usb порту. Я реализацию вижу так: нажимаем кнопку на psd, psd посылает телефону команду (хоть не шифрованную) «дай дефолтовый пасс», телефон по всем правилам протокола передает данные, а psd их вводит. Т.о. и парадигма особо не ломается, т.к. psd может только один запрос сделать, как бы своего рода «стук в дверь».

А сколько на данный момент, если не секрет, выходит стоимость устройства?

И вам спасибо! Хороший и полезный проект делаете.
Я понимаю, это конечно защита от дурака, но и не каждый будет логи кейлоггера изучать скрупулезно.
Зачем? Просто эмулировать форму ввода куда проще.
3. А не проще тогда уж поставить пин на разблокировку? И поставить политику «забывать пароль при выключении устройства» или «каждые 30 минут бездействия».
4. В будущем все возможно. Были бы покупатели. Но можно на кикстартере сделать
6. Не думаю, что человек, который поставил кейлоггер на чужой компьютер, будет этим как-то смущен. Помню как через blindsql через бинарные вопросы узнавал имя пользователя и название базы руками. Как proof of concept, конечно.
8. >хоть не шифрованную
Ииии, все сломалось.
Вектор атаки
1. Воруем «в наглую» psd
2. Наш ноутбук запрашивает дефолтный пасс
3. Приходим домой, расшифровываем трафик(т к на psd ключи старые, а память psd мы с паяльником считать можем)
4. Наслаждаемся статьей 272.

Но я понял идею, обдумаю на досуге.

>стоимость устройства
мы еще не определились с корпусом, но стараемся уложиться до 30$.
Вообще, если абстрагироваться от курса рубля, то это дешево. Но и 2400 за девайс тоже вполне адекватно, учитывая, что у многих людей в it зарплаты привязаны к доллару.

3. Лично у меня привязка к Mi Band. Без него требует пин для разблокировки телефона. Я просто мысли озвучиваю. Они исходят из, пусть будет, паранойи: дал позвонил, а чел залез за паролем.
Но не смотря на пин самого телефона, все равно некоторые программы, по привычке, дополнительным пином защищаю :-D
6. В целом да, согласен. Видать моя паранойя раздулась.
8. Упс )))) А ведь действительно!!! Лопух я :-D

Хм… Как-то и не думал, что «привязка» ЗП к баксу есть. Наверное, это в частных компаниях так…
3. >а чел залез за паролем
он его не увидит же все равно. только сможет ввести. Там с телефона даже при подключении инфы никакой не узнать.
Если начнет вводить на компьютер, то можно выдернуть psd. Но это совсем не серьезный вектор. Ибо человек будет пойман.

Зависит от компании. У фрилансеров-то точно. Сейчас много компаний работают вне Российского рынка. Ибо цены не успели еще подскочить за долларом.
3. В данном случае, я говорил в целом, а не конкретно о программе для psd. А что пасс в проге не глянуть, это я понял.

А… Ну да. Забыл о фрилансерах.
Идея хороша, в реализации вижу два слабых места.

1. Ценность софтовых (а именно open-source) менеджеров паролей в том, что их можно проверить один раз в год, а потом доверять результатам этой проверки, получая бинарники из надежного источника. С аппаратными решениями все печально, каждый экземпляр — черный ящик Пандоры.

2. Репутация USB устройств, притворяющихся клавиатурами, несколько подпорчена. (На самом деле это продолжение первого пункта.)
Мне кажется, всё в точности наоборот.
1) получая обновление софта, в один прекрасный момент прилетит намеренно встроенный троянец от разработчиков. Прецедент у мозиллы (если не ошибаюсь) уже был. А если и не было, то это, в принципе, очевидно.

2) а вот клавиатуры, как правило, сейчас всё равно по USB подключаются, так что мы ничего не теряем.
Ну, не стоит забывать, что код открыт. Он был открыт и будет открыт, потому что он работает с чувствительными для пользователей данными.
«Прилет троянца» будет огромным ударом по репутации.
Да и форки никто не отменял.
Пока что у нас закрыт только код на сам девайс(PSD). С него сделать чего-то плохого проблематично, а уж слить пароли еще сложнее.
При этом, планируется его открыть в будущем.
Я не очень понимаю вектор, который вы рассматриваете. Предполагается, что PSD начнет вводить в режиме клавиатуры непотребщину уровня скриптов для создания бэкдора? Это очень сложно реализовать незаметно и надо быть уверенным в том, какая ОС используется.

Но все это можно обсудить, мы не mozilla и гораздо проще в коммуникации.
>Я не очень понимаю вектор, который вы рассматриваете.

Это не я, я как раз считаю что с USB частью всё нормально, не хуже по крайней мере чем с клавиатурой.
Писал байтовый протокол для работы с фискальным регистратором из софта на мобильном телефоне.
Первая версия устройства была с BT. По BT работает все хорошо до тех пор пока в офис не приходили люди (я выхожу на работу на 3 часа раньше всех). После того как в округе набиралось критическое количество телефонов с включенным BT — связь становилась просто ужасной.
На каждые переданные 100 байт было до 3-х байт неверно полученных на другой стороне (данные с двух устройств логировались и вручную анализировалось что отправлено и получено).
В итоге разработчик ФР сделал нам версию с WiFi вместо BT. Тут уже полегче стало. Единственное что пришлось решать — это выход из зоны действия в режиме работы. Научили само устройство передавать номер последней команды, чтобы телефон мог откатить счетчик и послать команды повторно.

Так что очень советую проверить ваше решение в зашумленном месте.
Непонятно зачем возня с BtKey и HBtKey, когда можно сделать Diffie-Hellman
Окей. Вектор:
1) перехватывать весь трафик
2) Украсть устройство
3) достать ключ дешифрования с него(для дешифрования ключ будет храниться на девайсе)
4) расшифровать весь трафик, что шел ранее
5) соединить все посланные password_part_2 со всеми соответствующими password_part_1 на устройстве
В итоге получим все пароли, которые мы когда либо вводили.
Собственно, смена ключей на каждом пакете и нужна, чтобы расшифровать можно было только следующий пакет. Для предыдущего пакета паролей не существует.
Diffie-Hellman, к тому же, не подходит в качестве пост-квантовой системы.
Еще можно попробовать атаки на спаривание устройств. Например, попробовать спарить фейковое устройство раньше и перехватывать password_part_2 с уже известным ключом.

DH создает сессионный ключ в момент установления связи с телефоном, ключ хранится в RAM и удаляется когда донгл вынимают из порта + по таймауту + по датчику вскрытия корпуса.
DH не защищен от MITM атак. Защититься можно только используя сертификат.
В моем случае я передаю ключ(вместо обмена как в DH) по гарантированно защищенному каналу, что и обеспечивает более высокий уровень безопасности.
stackoverflow.com/questions/10471009/how-does-the-man-in-the-middle-attack-work-in-diffie-hellman
И в чем проблема использовать сертификаты? А еще можно не выдумывать и просто взять TLS. Сразу и аутентификация и PFS и поддержка нескольких донглов при желании.
Я бы купил )
думаю до 2кр (25$) в текущем функционале.
В комментариях не хватает картинки из xkcd про стоимость взлома пароля. =)
Спасибо за статью и разработку!

Делайте!!! Идея хорошая!

Понятно что всегда найдутся применения в которых не будет USB или плохо будет работать BT или еще что нить будет не так…
но для многих и многих это устройство будет банально очень удобной вводилкой паролей!!!
с удовольствием бы такую купил даже без особых шифрований — просто чтобы не запоминать пароли

когда работаешь на одном компе то все более менее просто — броузер запоминает пароли, а вот когда этих компьютеров два или три — то начинаешь искать броузер с аккаунтом (тот же хром), но иметь такое устройство которое делает тебя независимым от интернет аккаунтов — это однозначно плюс!!!

так что для среднестатистического пользователя ваше устройство будет интересно!!! я бы даже предложил подумать над уменьшением цены — если выкинуть BT модуль — то вместо его цены вы точно сможете поставить маленький LCD и пару кнопок + шнурок удлинитель для USB (пользователям десктопов) — и это будет вообще классное решение!!! (нужно посмотреть может китайцы уже что то подобное сделали??!)

p.s. я не рассматриваю вопросы всяких попыток взлома, так как у меня нет настолько критической информации на тех сайтах где я зарегистрирован…
с удовольствием бы такую купил даже без особых шифрований — просто чтобы не запоминать пароли

Тем самым сделать еще хуже: потерял девайс — лишился всех аккаунтов.
и часто вы теряете ключи ? я уже лет 20 ничего не терял из того чем пользуюсь почти каждый день…

еще раз напишу — я не системный администратор, не админю майл ру или яндекс или пайпал, хабр или еще какие нить супер-системы с повышенными требованиями к безопасности…

у меня домашнее применение и ущерб от утраты паролей будет только в том что придется везде делать восстановление через емайл… — и это не самое страшное… я сейчас постоянно это делаю когда оказывается что на каком нить «x» сайте мой емайл уже зарегистрирован но пароля я не помню…
к слову на некоторых сайтах нельзя написать логин русскими буквами — пишу по английски — был бы рад если бы донгл еще и напоминал имя пользователя для сайта (наряду с паролем)… а есть сайты с принудительным присвоением логика в виде id номера (!) — там вообще это будет супер нужно!!!

Еще раз повторюсь — для рядового пользователя этот девайс — находка!!! запишите меня в первую партию!!!

Обычно ничего не теряется, а вот кошелек у меня один раз увели. Упростив требования к безопасности такого девайса, получим новую инкарнацию листочка с паролями и раздолье для торгашей учетками.
ну тогда, на крайний случай, можно сделать запрос на мастер пароль при подключении устройства… (и то желательно сделать это отключаемым),
может быть сделать набор пароля на кнопках самого устройства (Пусть это будет простейший пин — этого будет достаточно)

Просто мне например не нужен аппаратный донгл который связывает телефон и компьютер… у меня на работе телефон рядом со мной (на столе), а вот дома — я его зачастую кладу на тумбочку и если никто не звонит — то и не трогаю…

еще раз повторю мысль — вся зависит от применения. если для дома- то достаточно донгла, если для защищенных система — то пусть будет и с телефоном, и с шифрованием, и еще с проверкой отпечатков пальцев…
Да, конечно все зависит от сферы применения. Но делать систему защиты, которая делает только хуже, явно не стоит.
конечно,
просто нужно сразу озвучить «что является хуже чем сейчас»
я вот уже фактически пришел к нескольким паролям на все сайты — и это очень плохо…
и что хуже — иметь донгл который НУЖНО НЕ ТЕРЯТЬ или иметь три-четыре пароля на все сайты где зарегистрирован ?!
по мне первое намного лучше чем второе…
в конце концов телефон же вы не теряете наверное? :-) прицепить к нему донгл на шнурке для забывчивых :-)

вернее для забывчивых — донгл не использовать вообще :-)))
итого у нас два варианта:
1) донгл «simple»: простой в использовании, но который нельзя терять, так как моментально компрометирует все учетные записи
2) донгл «hard»: более сложный в использовании, но потеря донгла или телефона, грозит только покупкой нового донгла и восстановлением базы с компьютера
В такой постановке вопроса первый вариант делает «хуже чем сейчас», и без разницы что сейчас, добавляя только удобство для пользователей.
согласен с вами :-(

как заплатку можно предложить, чтобы не компроментировать «моментально», ввод пароля на самом донгле…
соглашусь что наверное это не ахти какая защита…

и все равно я бы себе такое устройство купил!!!
Спасибо, очень интересная статья.
Интересует вопрос: по итогам всех шифрований и вычислений эмулированная клавиатура все равно вводит пароль в виде plain text, так или нет? Если да, насколько это безопасно? Возможно ли отследить вводимый пароль при помощи keylogger'a?
Да, я даже писал про кейлоггер.
Пароль вводится в обычном виде, будто это клавиатура, но удобно для пользователя(без, непосредственно, ввода).
Это будет работать с любым сервисом, принимающим символьные пароли. И сервис даже не должен знать о том кто вводит пароль
Не думали немного усложнить ввод от тупых кейлоггеров, применяя например рандомный ввод, бекспейсы, довведение в нужные места букв с передвижением курсора стрелочками и т.п.?

Иногда так делаю, надеясь что простейшие кейлоггеры бекспейсы и стрелочки не обрабатывают, или по крайней мере — отбраковывают такой ввод как мусор (кому потом не лень копаться/разбираться в этом мусоре, если рядом лежит обычный готовый плейнтекст от другого пользователя?).
Написание кода, который это обойдет не намного сложнее, чем написание кода, который это добавит. Я не особо разбираюсь в кейлоггерах, но если я с ходу могу придумать алгоритм, который, если ему ввести каждую нажатую клавишу и время нажатия, сможет вывести полноценный список текстов, единовременно введенных пользователем(например, введенный пароль будет в отдельной строке, а написанный email в другой), то уж разработчики, которые думали над этим больше 10-ти секунд и подавно уже давно решили эти проблемы.
Мы подумаем что можно сделать с кейлоггерами, но не думаю, что там реально можно что-то значительно улучшить, не помешав удобству. Но добавлять клавиш в ввод не спасет от кейлоггера, который писали не на коленке
Да, из-за кейлоггеров символьный пароль по любому является дырой в безопасности. Обыкновенный Punto Switcher, который стоит на половине компьютеров, уже является (легальным!) кейлоггером, вроде даже copy-past'ы отлавливает, и антивирусы не отмечают его как опасную программу.
Поэтому ваша система безопасности работает в сфере (символьный пароль), которая принципиально небезопасна (кроме как в специальных средах, типа Tails).
Я бы купил с текущим функционалом, но с несколькими «если».
1. Оно должно работать без плясок с бубном под линухом.
2. В комплекте 2 «свистка» и возможность докупить сколько необходимо.

Очень жклательно в комплекте иметь мелкий переходничок на микро usb, который будет как-то крепиться к свистку. И нужно предусмотреть на свистке способ крепления к чему-нибудь. Например, отверстие для шнурка.

Готов $20-$30 в таком случае потратить. И готов сделать предзаказ на каком-нибудь *стартере.
1. Да, естественно. Моно только запустить надо. А оно ставится очень просто(на дебиан и убунту вообще с ходу)
2. Два свистка? Имеется ввиду 2 PSD? Это небезопасно. Любая система, работающая с двумя свистками будет взламываема при краже одного свистка и чтения памяти с него.
Переходник на микро usb и сами думаем. Но вообще они продаются повсеместно, а нужны не всем. Зависит от того как использовать устройство.
2. Два свистка? Имеется ввиду 2 PSD? Это небезопасно. Любая система, работающая с двумя свистками будет взламываема при краже одного свистка и чтения памяти с него.

Не понял. Вы же сами пишите, что кража PSD без телефона бесполезна. Я имел в виду, что либо второй PSD лежит дома и при утере первого система продолжает функционировать, либо один дома, а второй на работе стационарно подключен.

Переходник на микро usb и сами думаем. Но вообще они продаются повсеместно, а нужны не всем.

Без переходника будет невозможно ввести пароль с телефона. А отдельный переходник будет теряться и по закону подлости его не окажется в нужный момент под рукой.
Зачем вам аж два девайса с одними и теми же паролями? Протокол подразумевает смену паролей на собеседниках при каждом сообщении. Если третий(еще один PSD) девайс не участвует в общении, то у него ключи устареют.
Вообще, база дублируется на компьютере(вашем домашнем) и будет совместима с KeePass.
Так что проще в случае утери девайса просто купить новый и записать пароли на него снова. И при этом можно быть уверенным, что со старого(украденного) не достанут пароли даже если узнают ваш мастер-пароль. В том и суть же.
Вообще, база дублируется на компьютере(вашем домашнем)

Хм, я думал база без PSD превращается в тыкву. Недопонял, значит.
Тогда еще более актуально предусмотреть возможность крепления всего этого хозяйства, например, на ключи. Чтобы, с одной стороны, надежно держалось, а с другой, быстро отстегивалось, когда нужно.
Вот часть с корпусом мы еще не продумали. Есть идеи по реализации, но не знаем кто этим занимается на рынке
Я поясню по пункту 2. Я как-то попал в совершенно идиотскую ситуацию. Я поменял пароль на пайпале и умудрился забыть его. А ответ на секретный вопрос я забыл еще раньше за давностью лет. Сам дурак, конечно, но дело не в этом. Буржуины отказались восстанавливать пароль «разумными» способами. Молодцы, на самом деле, но передо мной маячила перспектива потери аккаунта. Хорошо, пароль все-таки вспомнил.

Так вот, я хочу, чтобы при утере одного PSD я бы имел возможность хотя бы сменить пароли без геморроя. А для этого нужен второй «свисток».
Я бы еще NFC в дополнение к BT предложил в качестве транспорта…
Вот у конкурентов можно список фич посмотреть
Я так и не понял как ввести пароль для шифрованного раздела до старта операционки. Ткните меня, пожалуйста, носом, если не сложно.
Если честно, я не уверен, что такое вообще реализовано, сам я пока не физическими токенами не пользуюсь
Просто в том вся и суть. Господа по ссылке лишь предлагают отдельные решения для некоторых сервисов(самых основных).
Я же предлагаю решение для всего спектра устройств, поддерживающих usb клавиатуры(это почти все устройства)
При этом, система гарантирует безопасность при утере самого донгла + мастер-пароля. И вот этого нет ни у кого в данный момент
Нисколько не умоляю ваше решение, но тем не менее, а как часто вам нужно расшифровать хранилище до старта операционки?
Лично меня вполне устраивает набор скриптов уже загруженного initramfs, а вот лишний девайс в лице телефона наоборот не нравится.
Но идея у вас интересная, и я желаю вам успехов ;)
А у уже успешного коммерческого продукта в похожей области можно многие решения подсмотреть. Насколько я понял, они как раз предоставляют широченный спектр, от эмуляции клавиатуры, до otp токенов, ключницы сертификатов и все это для устройств с usb или nfc…
В том и проблема, что все вместе не поддерживает ни одно устройство.
И уж точно никто не хранит пароли распределенно, что делает вектор «узнать пароль-> украсть донгл» крайне вероятным.
Но, идея использовать OTP мне понравилась, так что реализовать ее запланировал.
Я еще не читал исходники той программы, что с keepass работала, но я почти уверен, что вектор «перехватить трафик -> украть донгл» позволит расшифровать предыдущий трафик.
Но ваша позиция определенно валидна, Cпасибо
Тот токен, который предлагается yubico, предназначен для несколько иного применения. Так что никакой конкуренции не видно, как и двух факторов в вашем случае.

Yubikey является смарткартой (со всеми вытекающими, вроде крайне высокой стоимости попытки извлечения ключей) с аплетами для стандартных применений смарткарт (типа piv, openpgp). Естественно, оно может использоваться для хранения 3 pgp/gpg ключей (шифрование, подпись, аутентификация), стандартных для piv ключей + сертификатов и т. п. Это таки не про хранение паролей к каким-либо сервисам. Многим это не нужно.

FIDO U2F — стандарт, позволяющий добавить к обычному логину-паролю второй фактор с challenge-response на аппаратном токене. Оно в первую очередь про простую для пользователя двухфакторку, имеющую свои ключи для каждого сервиса. Естественно, пароль там обычно тоже есть.
MMN.
Флешка со сканером отпечатков пальцев и с эмуляцией клавиатуры. Питание подается при установке в устройство, а экрана и 4-х кнопок, как на первых МР3-плеерах, хватило бы выше крыши. Чуть больше габариты, чем у «обычной» флешки, но не нужен телефон.

Самой идее уже пару десятков лет (первые терминалы в нормальных компаниях активировались чип-картой/ручкой с чипом), просто обвязка и применение чуть шире.
>Флешка со сканером отпечатков пальцев и с эмуляцией клавиатуры
оно есть. Вы имеете ввиду биометрическую аутентификацию? Есть девайсы для этого. Но это не поможет вам авторизоваться в сервисе, принимающем только символьные пароли.
Самый простой пример, как я часто уже писал, это шифрованный диск с операционной системой. Я не уверен, что там можно вход по ключам сделать, но даже если можно, то утеря ключа будет очень неприятной.
Вклинюсь по поводу осей — за все не скажу, но под linux самый популярный способ шифрования контейнеров — это LUKS через ядерный dm-crypt. Luks контейнер содержит незашифрованный заголовок, в который прописывается зашифрованный ключ к разделу. Ключ этот шифруется паролем либо файлом и вариантов можно записать до 8 штук. Соответственно, можно задать несколько паролей к одному разделу и тому подобное.
Соответственно, можно делать разные интересные штуки, от файла-ключа на отдельном носителе до отдельной флэшки с boot разделом и тем самым незашифрованным заголовком от основного диска
Именно про это я и говорю. Но если вы потеряете свой чудо-ключ(или злые люди в масках его у вас заберут), то вы успешно получите кирпич вместо диска или человека с доступом к вашему диску.
Я разнес ключи на 2 устройства с необходимостью знать мастер пароль.
Если у хакера будет всего 2 вещи из 3-х(телефон, PSD, мастер-пароль), то вам нечего бояться.

Кстати, чудо-ключ еще можно незаметно дублировать
В наших реалиях, если к вам придут люди в масках, то вас не спасет разделение на два устройства. Если вы потеряете чудо ключ, то вы можете либо отозвать этот ключ в случае luks контейнера, либо не переживать в случае, если вы и этот мастер ключ зашифровали паролем из своей головы.
В случае таргетированной атаки на вас, как и в случае маски-шоу, вряд ли вас хоть что либо спасет.
Как показывают многочисленные известные случаи, проще сломать либо человека, либо уже загруженную операционку.

image
А как насчёт «пароля на всякий случай», который вместо открытия базы уничтожает её (и/или девайс)?

Для достоверности можно даже немного покочевряжиться, прежде чем его выдать вопрошающим.
Планируется сбрасывать базы при вводе пароля в обратном порядке.
Хотели еще сделать дополнительный контур, сбрасывающий память psd при нажатии на специальную кнопку(даже если нет питания). Но оно увеличит размер и стоимость.
Возможно, сделаем в нескольких версиях.
Планируется сбрасывать базы при вводе пароля в обратном порядке.
Я бы не советовал. Можно будет легко отличить пароли:

— Колись, какой мастер-пароль?
— ВасяПупкин!

vs.

— Колись, какой мастер-пароль?
— н… и… к… п… у… П… я… с… а… В! (трудно, помня настоящий пароль, вспоминать его задом наперёд, не правда ли?
Ну, это верно. Но если запоминать пароли через парольные фразы(первые буквы не распространенной фразы), то в обратном порядке их можно без проблем пропустить.
Да и тем более, не все мы ставим вероятности на появление людей в масках одинаково. А кто предполагает, что они могут появиться, запомнят пароль в обратном направлении.
если запоминать пароли через парольные фразы(первые буквы не распространенной фразы), то в обратном порядке их можно без проблем пропустить.
«А Вы пробовали?» ©

С другой стороны, в прямом пароле тормоза тоже будут, потому что фразу надо будет задумаваться для перевода слов фразы в буквы пароля, так что разница в скорости ответа будет нивелирована.
Если уж на то пошло, то можно запомнить 2 пароля. Если есть реальная угроза маски-шоу, то я бы и с паяльником стирающий контур припаял. В этом направлении мы будем максимально поддерживать пользователей. Скорее всего на плате будет неиспользуемый контур, чтобы проще было самостоятельно напаять батарейку и кнопку стирания.
Зависит от того насколько это критично. Если к вам могут прийти люди, то вы об этом знаете. А если не знаете, то бояться нечего.
Если к вам могут прийти люди, то вы об этом знаете.
Ну мне просто кажется, что для тех, к кому не «могут прийти люди», Ваше устройство является «презервативом, натянутым на свечку» © анекдот.
Что именно наводит на такие мысли? Отличие от обычного менеджера паролей для пользователя лишь в том, что можно вводить пароли не руками, а, следовательно, придумывать более безумные пароли.
Возможно вы просто недооцениваете сервисы вроде хэшкиллера, которые достают совсем уж безумные штуки из хэшэй. Паролей, которые он не берет действительно единицы процентов. И это не на базах госработников, а на базах паролей людей, связанных с IT.
Так я про то и говорю: Ваше устройство для 5% людей, что-то понимающих в безопасности, а (магическое число) 95% и дальше будут пользоваться паролем «password1».
Ну, для использования устройства не нужно понимать в безопасности. Интерфейс очень прост, удобен и понятен. А 95% потом будут переходить на другую сторону, как только у них уведут какой-нибудь сервис.
Я так одного системного администратора обучил не использовать sshpass, например. Он тоже думал, что никто не сможет получить шелл доступ к его сайтам. Но после получения шелла я смог получить доступ к панели управления хостингом, т к через sshpass был слит пароль к ssh(совпадающий с панелью хостинга).
Будь я злоумышленником, у пользователя было бы очень много проблем с клиентами, которые потеряли бы как сайты, так и домены(к доменам привязана раскрутка, в которую вкинут не один млн рублей). И даже он использовал стойкий пароль. Но использовал неправильно.
Это я к тому, что дешевле слушать 5% параноиков, чем внезапно узнавать «ой, а так можно было сделать, имея мой пароль?».
Контрольный пример — владельцы icloud-ов, которых я одну ночь ковырял от скуки. Они ведь даже не поняли бы, залей я им в общий диск малварь, замаскированный под софт от эппла. А потом бы были очень удивлены, как это имея пароль от icloud можно увести банковский счет с двухфакторной авторизацией и паролем в 32 символа.
Незнание опаснее небрежности тем, что вы не знаете о своем незнании. Против вас играет умный противник и если он действительно умен, то вы и не знаете, что он против вас играет.
По поводу Вашей реплики в английском языке есть такая идиома «preaching to the choir» («читать проповедь церковному хору»), то есть «убеждать кого-то в чём-то, с чем он и без того полностью согласен».

Мне всё это рассказывать не надо, я с Вами согласен на все сто. Проблема в том, что те самые 95% «заказывают музыку» в мире, голосуя кошельками. :(
А, пардон. Мне казалось, что вы отнесли себя к 95%. Ну, достаточно очевидно, что я не собираюсь завладеть всеми мировыми финансами, предлагая универсальное решение.
Но аудитории мне пока и так хватит. 95% слишком глупы, чтобы что-то решать за себя. Они копируют поведение общества.
Если хотя бы 200 думающих людей(а 5% это таки много людей) купят девайс, то следующая партия будет значительно больше.
Я прочитал все комментарии и уже реализовал в новой версии протокола почти все предложенные фичи. Но даже до этого 180 человек проголосовало за эту идею. Мне этого вполне хватит, чтобы собрать денег на достаточно большую партию, чтобы цена устройства была низкой(25-30$, как и просили тут).
Я не вижу проблем с тем, что большинство не может за себя решать. Я ориентируюсь на думающих людей, которых достаточно много.
Если подходить без максимализма, то все хорошо. Если идея выстрелит среди адекватных людей, то и 95% подтянутся.
Ну и да, если продолжать бросаться пафосными фразами, то 5% могут влиять на 95%, но не наоборот
Да, я думал о таком варианте.
Еще лучше вариант, вроде два пароля:
первый пароль открывает базу в присутствии BT телефона, без него затирает базу;
второй пароль открывает базу без BT телефона, с ним затирает базу;
главное — не перепутать =)
ну и затирать базу при N неправильных попытках...
Я не до конца пояснил суть вопроса — извините, работаю со студентами, заставляю и х додумывать необходимое, иначе просто не научаться.
Смотрите, на флешке пароли уже есть. Просто их выбор/перебор и доступ осуществляется через органы управления на самом устройстве. А вот запись в шифрованном виде — через компьютер, как обычно. Неудобство в том, что нужен сам комп для ввода нового/изменения старого пароля. Но, опять же, кто сказал, что это нельзя сделать через тот терминал, к которому Вы подключились?
Через данный терминал (в который вводится пароль) в любом случае он попадает (в каком виде — второй вопрос), поэтому данный способ изначально небезопасен.
Тему выбора полей/форматов данных для ввода логина и пароля предлагаю пока не обсуждать — утонем в спецификациях.

Не понятно зачем тут смартфон?

В аппаратном хранителе Пастильда же нет нужды в смартфоне.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Изменить настройки темы

Истории