[CNick]

Смысл в то, что таким образом кейлоггеру будет доступны только некоторые пароли. Те, которые на ней набирались. А не вся база и ключевая фраза к ней.

Может гораздо рациональней усилия на создания девайса с офлайновой забой паролей потратить на усиление безопасности воркстейшина? Например разделить ворстейшин виртуализацией на разные безопасные зоны. Мне вот приходилось в одном большом банке работать, там просто интранет с виндовым доменом где политиками все запрещенно + хардварный OTP токен. Дальше разве что полностью изолированый интранет без выходов в другие сети или полностью оффлайновый комьютер как у вояк :)

[nuclearcat]

Те специальные усилия надо прилагать для поддержания всего этого в порядке.

Ну те на комп - синхронизировалку и не забывать регулярно к соответствующему компу такой 'плеер' цеплять?

 

Это fail по юзабилити. Для особо важных паролей паранойя по поводу WiFi может быть и надо. А для кучи умеренно важных, имеющих существенную ценность только всей кучей - нет.

Доверенная WiFi сетка для таких целей достаточно надежна.

Fail или нет - токенами пользуются почти все крупные компании, банки и другие организации, которые хоть немного заботятся о безопасности.

Кстати если уж очень хочется синхронизироваться по USB - простейшая софтина определит подключившийся токен и сделает синхронизацию автоматически.

Вводить имена и генерить пароли нужды нет, просто сервера назначаются с id в конце hostname, т.е. например centaur-123, antares-764 и т.п., на токене для получения пароля вводится этот самый уникальный id.

Если подходить неправильно, даже в андроиде прийдется тратить время на набивку имен серверов - да, это бардак и fail usability, потому как сам подход колхозный.

 

А какой смысл так париться с офлайновой хранилке паролей если потом этот пароль вбивать на основном онлайновом воркстейшине? :)

Я вообще-то использую двухфакторную авторизацию, так что могут хоть облогироваться с TOTP, но с некоторым оборудованием это трудновато.

У паролей есть несколько проблем, которые это устройство решает:

1)Трудно запомнить много разных. Если один -то в случае его увода происходит катастрофа. Если несколько в текстовом файлике - та же фигня. Если это keepass - то увод мастер пароля приведет к потере всех паролей. Если даже переписать его и сделать динамический пароль - программы под винду и линух очень просто реверсятся.

2)Если пароль сложный - его тоже сложно запомнить и набрать, с экрана вводить намного проще

3)Динамические пароли, где это поддерживается

4)Сам вход в устройство можно сделать динамическим. К примеру при входе вам высвечивается 5678 (каждый раз случайное число), и вы знаете, что надо первые две цифры умножить на 2, а вторые отнять единицу от каждой цифры. Кроме того можно сделать спец. пароль который заблокирует устройство, если вас принуждают ввести ваш пин.

 

Может гораздо рациональней усилия на создания девайса с офлайновой забой паролей потратить на усиление безопасности воркстейшина? Например разделить ворстейшин виртуализацией на разные безопасные зоны. Мне вот приходилось в одном большом банке работать, там просто интранет с виндовым доменом где политиками все запрещенно + хардварный OTP токен. Дальше разве что полностью изолированый интранет без выходов в другие сети или полностью оффлайновый комьютер как у вояк :)

Это и есть хардварный OTP токен. Просто не черный ящик с возможными закладками, а открытая реализация. Тем более все равно эти OTP токены используют стандартизованные алгоритмы.

[Sergey Gilfanov]

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

[CNick]

Это и есть хардварный OTP токен. Просто не черный ящик с возможными закладками, а открытая реализация. Тем более все равно эти OTP токены используют стандартизованные алгоритмы.

Мне идея не понравилась, наверно просто потому что мне такое не нужно :) , но если выбирать между вариантами реализации именно вашей идеи то ИМХО нужно что-то в форм факторе как Ipod/ipod nano или если с хардварной клавиатурой как Nokia Asha 210. 5 хардварных кнопок на плеере это слишком уныло если прийдется вводить новый пароль вручную.

[nuclearcat]

Можно генерить ID/юзернейм по имени вебсайта, простеньким плагинчиком в браузере hash(domain+sequence) = user/pwd.

sequence на случай если надо сменить пароль.

 

По БД тоже надо определить ключевую фразу, например host+dbid+sequence для генерации хеша. Главное чтобы это все генерило нужный числовой id для токена.

[nuclearcat]

Мне идея не понравилась, наверно просто потому что мне такое не нужно :) , но если выбирать между вариантами реализации именно вашей идеи то ИМХО нужно что-то в форм факторе как Ipod/ipod nano или если с хардварной клавиатурой как Nokia Asha 210. 5 хардварных кнопок на плеере это слишком уныло если прийдется вводить новый пароль вручную.

В смысле вручную? В устройство вводится только seed - один раз.

Потом в лучшем случае недлинный цифровой ID пароля и выбрать один раз - динамический или постоянный.

[Sergey Gilfanov]

Можно генерить ID/юзернейм по имени вебсайта, простеньким плагинчиком в браузере hash(domain+sequence) = user/pwd.

Нет уж, спасибо. Я хочу иметь в хранилке паролей нормальную запись

Сайт: forum.nag.ru

Юзернейм: Sergey Gilfanov

Пароль:

 

И без всякой установки непонятно чего в браузер/систему.

 

По БД тоже надо определить ключевую фразу, например host+dbid+sequence для генерации хеша. Главное чтобы это все генерило нужный числовой id для токена.

А подписать в базе, что вот то, что получилось - это для host + dbid? Или мне наизусть помнить надо, что если я на проекте N в базу заглянуть хочу, то мне нужно

набирать 448877, а если на проекте Y - то 993210?

 

В смысле вручную? В устройство вводится только seed - один раз.

Потом в лучшем случае недлинный цифровой ID пароля и выбрать один раз - динамический или постоянный.

Нет, паролей много. Для каждого места - свой seed для генерации. Соответственно, нужно как-то заполнить (понятно!) список, что к чему относиться.

Можно, конечно, как в Google Authenticator делать - там камерой QR код снимают, в котором сразу имя учетки вбито. Но у плеера же камеры нет?

Вообще, это же легко проверить на собственной шкуре. Найдите андроид, поставте на него FreeOTP какой-нибудь. Введите пару произвольных учеток ручным вводом. А потом попробуйте представить, что это все нужно будет вводить с 5 кнопок плеера.

[nuclearcat]

Нет уж, спасибо. Я хочу иметь в хранилке паролей нормальную запись

Сайт: forum.nag.ru

Юзернейм: Sergey Gilfanov

Пароль:

 

И без всякой установки непонятно чего в браузер/систему.

Ну значит вам такое решение не подходит :) Прийдется дальше носится с планшетом, синхронизировать все записи с компом, и фактически иметь только иллюзию безопасности.

 

По поводу google authenticator - вы похоже плохо представляете принцип работы OTP. QR всего лишь один из многих методов ввода, seed можно загнать по USB, файликом, если очень хочется.

Генерировать множество seed - неправильно. Обычно сервера завязываются на радиус, где есть возможность динамического пароля, создается также механизм failover со статическим паролем, который после использования желательно менять. Если это приложения со статическим паролем - можно использовать отдельный и единственный seed для их генерации.

[Sergey Gilfanov]

Ну значит вам такое решение не подходит :) Прийдется дальше носится с планшетом, синхронизировать все записи с компом, и фактически иметь только иллюзию безопасности.

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

 

По поводу google authenticator - вы похоже плохо представляете принцип работы OTP. QR всего лишь один из многих методов ввода, seed можно загнать по USB, файликом, если очень хочется.

Те сначала мы на каком-то компе этот файлик делаем, потом в 'плеер' загоняем. Сразу при генерации учетки вбить ее в такой 'плеер' - никак или задолбаешься.

 

Генерировать множество seed - неправильно. Обычно сервера завязываются на радиус, где есть возможность динамического пароля, создается также механизм failover со статическим паролем, который после использования желательно менять. Если это приложения со статическим паролем - можно использовать отдельный и единственный seed для их генерации.

Те речь идет о системе где мы можем настраивать серверную часть OTP так как надо. В таком случае проще просто систему на основе Yubikey построить.

[Ivan_83]

а нельзя сделать что-то такое, что генерирует ключ на основании папиллярного узора пальца?

Это лажа полная.

Там при сравнении идёт не чёткое сравнение и вероятностное.

[nuclearcat]

Те речь идет о системе где мы можем настраивать серверную часть OTP так как надо. В таком случае проще просто систему на основе Yubikey построить.

 

И как вы воспользуетесь Yubikey если у вас планшет и вы в поездке?

[Sergey Gilfanov]

И как вы воспользуетесь Yubikey если у вас планшет и вы в поездке?

Через USB кабель. Он же тоже из себя клавиатуру изображает.

[nuclearcat]

Это если у вас есть шнурок и мобилка умеет host. И официально для андроида они предлагают только приложение, что мягко говоря не то.

Кстати как вы будете выбирать между разными seed? Технически некоторое количество разных может быть - например у меня несколько клиентов, которым я предоставляю IT саппорт, и они конкурируют. Ясно, что я не могу им назначить один ключ.

[Sergey Gilfanov]

Это если у вас есть шнурок и мобилка умеет host.

Вот это ни разу не проблема. Смотреть надо, что за мобилку покупаешь.

 

Кстати как вы будете выбирать между разными seed? Технически некоторое количество разных может быть - например у меня несколько клиентов, которым я предоставляю IT саппорт, и они конкурируют. Ясно, что я не могу им назначить один ключ.

Так у каждого будет своя учетка, свой seed и свой Yubikey ключ. Но вообще-то, хорош запутывать.

Совсем недавно на подбный же мой аргумент был ответ:

Генерировать множество seed - неправильно. Обычно сервера завязываются на радиус, где есть возможность динамического пароля, создается также механизм failover со статическим паролем, который после использования желательно менять. Если это приложения со статическим паролем - можно использовать отдельный и единственный seed для их генерации.

Если человек использует одну учетку и seed плюс сам учеток не создает - используем Yubikey и не парим себе мозги. Если seed-ов и учеток на человека несколько, и он сам иногда должен себе делать - нужны нормальные способы ввода для этих учеток. Плеер с 5 кнопками будет крайне неудобен.

 

Целевая аудитория предполагаемого устройства какая?

[nuclearcat]

Если человек использует одну учетку и seed плюс сам учеток не создает - используем Yubikey и не парим себе мозги. Если seed-ов и учеток на человека несколько, и он сам иногда должен себе делать - нужны нормальные способы ввода для этих учеток. Плеер с 5 кнопками будет крайне неудобен.

Речь шла о том, что seed не создается для каждой системы, а один на организацию.

У yubikey нет возможности гибкого выбора режима работы, вообще.

[Sergey Gilfanov]

Так. Я запутался. А есть разница, несколько организаций или несколько систем? Результат один - несколько учеток со своим seed.

[nuclearcat]

Так. Я запутался. А есть разница, несколько организаций или несколько систем? Результат один - несколько учеток со своим seed.

Да, конечно. Несколько систем обычно завязаны через что-то на сервер авторизации.

Но несколько организацией не могут использовать один и тот же сервер авторизации, lockheed martin уже на этом сильно обжегся.

[Sergey Gilfanov]

А хранилке паролей какая разница, есть там центральный сервер авторизации, или нет? Ей нужно знать seed учетки, куда логинимся, и счетчик/время, чтобы текущий пароль сгенерировать. Как выглядит OTP с одним общим seed на центральном сервере?

[nuclearcat]

Две конкурирующие организации принципиально не согласятся иметь что-то общее в авторизации.

Потому разница есть. А горку токенов я носить не хочу.

[Sergey Gilfanov]

Две конкурирующие организации принципиально не согласятся иметь что-то общее в авторизации.

Потому разница есть. А горку токенов я носить не хочу.

Разница есть для фирм. А для самой хранилки паролей - никакой разницы. Все равно несколько seed-ов и учеток вводить.

 

Правильно ли я понимаю, что имеется в виду что-то вроде подобной схемы:

 

1) Есть фирмы A, B с кучей серверов в каждой

2) У каждой есть, соответственно, центральный key-A, key-B

3) У каждого сервера есть короткий id-1, id-2, id-3..

4) OTP для конкретного сервера фирмы A работает, комбинируя key-A + <id сервера>

 

Соответственно, использование обсуждаемой парольницы происходит так:

 

Появление новой записи о фирме:

5) Время от времени появляется новая фирма С

6) у ней на центральном сервере генерируется и заносится key-C

7) этот же key-C заносится в парольницу

8) пункты 6 и 7 происходят достаточно редко, поэтому неудобство ввода этих данных нам не важно.

 

Использование записи о фирме:

9) Когда надо залогинится в сервер фирмы C, мы выбираем из списка в парольнице <фирма C> и набираем (короткий) id конкретного сервера.

10) Парольница по уже известному ей ключу key-C и введенному id-у сервера + счетчик/время генерирует текущий пароль сервера.

10) Отдельного ввода учетных записей серверов в парольнице нет. Счетчики конкретного сервера инициализируются автоматически, без ввода пользователя.

[nuclearcat]

Да, приблизительно так и есть.

Но я уже понял, что кроме меня это никому не нужно :) Надо думать над другими вариантами, которые пригодились бы всем.

 

Кстати, еще вариант применения, учитывая обьем памяти и скорость обмена - устройство может выступать хардварным токеном авторизации и хранения личных данных для массовых сервисов.

Т.е. скажем есть форум, в форуме пароли не хранятся, они в этом устройстве. Юзеру подсовывается salt от токена, когда он вводит пароль, при отправке форме пароль хешим с солью, и на сервер отправляется засоленный хеш пароля, сервер просто передает токену полученное - а тот отписывает - ОК или fail. Можно предусмотреть защиту от выдергивания определенных личных данных, над этим надо думать. Например фоновое дергание странички с логином с другого сервера на предмет отключения кода засаливания, и если код куда-то делся - закрываем доступ к серверу.

В это случае при взломе форума - массовая утечка паролей невозможна, убрать js и поснифать - тоже весьма сложно, сработает защита.

[Sergey Gilfanov]

Ой, ой. Это все у меня протестует против одного из основных правил криптографии - "не делай самоделки".

То что описано - это уже реализовано в гораздо лучшем виде. Называется проверка сертификата пользователя. Или OAuth какой-нибудь.

[nuclearcat]

Вы где-то видели сервис с сертификатом пользователя?

Oauth используют очень редко, и уже частенько ограничиваются только популярными сервисами.

[Sergey Gilfanov]

Вы где-то видели сервис с сертификатом пользователя?

В местах, подобных тем, где любят использовать железячный токен - видел. А аналогом (ssh ключ) -- так и вообще крайне распространен.

 

Oauth используют очень редко, и уже частенько ограничиваются только популярными сервисами.

"Внутренний" вариант(те OAuth сервер тоже под нашим контролем, поэтому мы не надоедаем вопросами "разрешить такому-то сайту доступ"), судя по всему, используется достаточно часто.

[nuclearcat]

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

Кстати это не велосипед, подобные вещи применяются повсеместно в серьезных конторами.