Авторизация на сайте без ввода логина/пароля

[Маэстро]

Речь пойдет не о javascript, но всё же хотелось бы узнать мнение специалистов по ИБ.

Аутентификация/авторизация пользователя на сайте происходит следующим образом:
-при регистрации нового пользователя сервер присылает на компьютер пользователя файл размером 1024 байт (или 2048), содержащий случайную последовательность символов.
-пользователь сохраняет этот файл в каком-то месте, желательно на флэшке или CD-карте.
-при последующем входе на сайт процедура залогинивания заключается в том, что пользователь должен отправить данный файл обратно на сервер (в соответствующей форме upload).
-идентификация пользователя производится сравнением содержимого файла с хранимым хешем в БД.

Как вы смотрите на такой механизм? Использует ли кто-нибудь нечто подобное?

[laimas]

Это давно используется, конечно не в таком упрощенном варианте. Вряд ли такое будет удобным для пользователей на "стандартном" сайте.

[Маэстро]

laimas,
про то, что внешние носители используются для хранения паролей я знаю.
Но речь как раз о том, что в файлике нет логина пользователя. И нет зашифрованного пароля (о методах расшифровки пишется в указанной Вами статье). Да, главной угрозой является кража флэшки. А в остальном?
И в чем на Ваш взгляд заключается неудобство пользователей на "стандартном" сайте? Я пока вижу некоторое неудобство только при работе на смартфоне (IPhone) с сохранением файлов..

[laimas]

Да, главной угрозой является кража флэшки.

Нет, защищенное соединение и то не гарантирует от атаки "человек посередине", а ваш файлик тем более.

И в чем на Ваш взгляд заключается неудобство пользователей на "стандартном" сайте?

А вы заставьте своих пользователей так авторизоваться, затем проанализируйте их мнения.

[Маэстро]

Нет, защищенное соединение и то не гарантирует от атаки "человек посередине", а ваш файлик тем более.

-это почему же? https как раз и защищает передачу контента клиент-сервер (при правильных сертификатах)

А вы заставьте своих пользователей так авторизоваться, затем проанализируйте их мнения.

-ответ, не несущий никакой полезной информации. если бы у меня было 1000 тестеров, то я бы не задавал свой вопрос на форуме специалистов.

[laimas]

https как раз и защищает передачу контента клиент-сервер

Почитайте об атаках, там все рассказано.

ответ, не несущий никакой полезной информации. если бы у меня было 1000 тестеров

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

В эру доступности моб. связи смотрите тогда в сторону авторизации через CMS например.

[Маэстро]

В эру доступности моб. связи смотрите тогда в сторону авторизации через CMS например.

Об атаках я, конечно, почитал. Но в том варианте как описываю, информации о взломах не нашел. Что касается технологии отправки паролей/кодов подтверждения на мобильный - в этом как раз и проблема. И эта проблема всё больше увеличивается: доступ посредников к тексту SMS, блокирование номеров как отправителей, так и получателей, клонирование SIM-карт, установка посреднических фальшивых сотовых станций, ...,... и заканчивая нежеланием людей указывать номер телефона в тех странах, где при покупке номера требуется паспорт со всеми своими данными и т.д.

[laimas]

Странно, столько над этим бьются, защищают, шифруют, пришел Маэстро с файликом и решил проблему.

Ну что смеяться то. Если у вас есть сайт, если вы собираете по нему статистику, если общаетесь с пользователями по поводу их жалоб, вопросов, то не вам рассказывать, что большая масса пользователей привыкла "щелкнул и все", и любителей паролей от "я" до 12345 еще очень много, и всякие доводы "это опасно" для них пустое, потому что так удобно, и трава не расти. А тут вы с флешкой.

PS. Можно далеко не ходить, на донном форму столько тем, когда отправляется данные северу, которые вообще даже и "не слышали" о таком как "проверка". И сколь не говори об этом, все без толку. И это не пользователи, это "программист" так порешил.

Делайте, анализируйте в реальности, получите ответ. А здесь никто не станет тестировать ваше "изобретение", а скажу только свое мнение.

Об атаках я, конечно, почитал. Но в том варианте как описываю, информации о взломах не нашел.

Атаки не обязательно ради взлома. MITM-атака опасная штука, посредством ее можно изменять данные обмена сервер-клиент - получая доступ к учетным записям, внедряя код...

[Маэстро]

Странно, столько над этим бьются ... пришел Маэстро ... и решил проблему.

Я обслуживаю организацию около 7000 человек уже более 10 лет. И Вы знаете, именно так уже было и не раз. Люди (даже хорошие специалисты) иногда не видят простых решений, "лежащих на поверхности". Я не боюсь нестандартных решений, не боюсь экпериментировать. Однако всегда хочется узнать/спрогнозировать наперед возможные проблемы, уберечься от ошибки, а не узнавать мнение пользователей по факту.
Что касается мнений: уже много лет таможенные брокеры работают с программой (например, MD Office), для которой нужно вставлять флэшку в комп. На флэшке ключ/пароль для шифрования документов. Это несколько не про авторизацию, но факт в том, что они уже привыкли и чувствуют себя спокойно.
С другой стороны я наблюдаю ужесточение правил составления паролей каждый год. Админы относятся к этому всё строже. Пароли заставляют делать сложными и менять каждый месяц. И знаете, к чему это приводит? чего я только не видел.. сотрудники пишут свои пароли в текстовый файл "ПАРОЛЬ.txt" и сохраняют на рабочем столе, пишут карандашом с обратной стороны на клавиатуре, на бумажке - и в карман. У одной девушки стикер с паролем был приклеен прямо на дисплее. Смешно? Нет, грустно.
Таким образом, есть предложение хранить тысячесимвольный код доступа в файле. По крайней мере это лучше, чем пользователи сделают такой же файл и запишут в него "A12345!".
Что касается атак, то сказанное Вами с тем же успехом можно отнести и к "классичесому" вводу логина/пароля. Только ещё хуже, т.к. возможен подбор пароля методом перебора по словарю и всё это на два порядка с большей скоростью.

Спасибо за Ваше мнение. Однако хотелось бы больше не общих фраз, а точной технической информации и аргументов.

[laimas]

Что касается атак, то сказанное Вами с тем же успехом можно отнести и к "классичесому" вводу логина/пароля.

Ну так речь тогда о чем? Если не касается безопасности (а ваш подход небезопасен), остается удобство: для организации - необходимость (может быть), для рядового пользователя - слишком много мороки (не будет он об этом заботится, мое мнение).

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

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