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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Да, тут всегда противоречие между безопасностью и удобством. Однако давайте сравним телодвижения при авторизации:
1. нужно ввести логин, нужно ввести пароль, нажать кнопку "OK" - много нажатий на клавиатуре, чего большинство не любит (?!).
(не беру в расчет тех, у кого логин/пароль запомнен в браузере, потому как такие просто не "выходят" с сайта, т.е. не закрывают сессию)
2. нужно нажать мышкой кнопку input file, потом "OK". при использовании методики HTML5- просто перетащить файл из одного окна в другое на страницу сайта. кстати, о флэшке я пишу потому что "так требуется", но уверен, что половина пользователей будет сохранять файл на рабочем столе или в папке "Мои Документы".
Так в каком варианте пользователю удобнее??

Это плохо, т.к. незнание алгоритма считается очень слабой защитой. рано или поздно алгоритм шифрования (или размещения чего-то в чем-то станет известен). Другое правило гласит, что в ключе/пароле/etc ни должно быть никакой логики, никакой закономерности, никаких данных типа ID... - только "белый шум". Соответственно мне кажется что предлагаемый мною вариант удовлетворяет этим требованиям.

Забегая немного вперед, скажу, что я тоже думал об использовании фото. Но это в основном для пользователей смартфонов. В данном случае сервер не будет присылать спецфайл. Пользователь сам делает свое "селфи" на камеру и отсылает на сервер в качестве своего идентификатора. Никакой речи о распознавании образов. Просто хеш файла сверяется с хешем в базе данных. Фотографировать не обязательно лицо. Можно кактус или орхидею.. Главная проблема, чтобы потом пользователь не запостил эту же фотку в Инстаграм!
Идея вполне осуществима, но.. меня терзают смутные сомнения ;)

Наблюдение за механизмом SMS-паролей.
Для тех сервисов, которые присылают пароль в SMS как вы думаете как поступает большинство? Наверное кажется, что они должны сменить пароль на сайте, удалить SMS... - нет! в моем окружении никто так не делает. Что интересно, (читал сообщения от пользователей) пишут: извините, я разбила телефон; у меня украли телефон; ... и теперь у меня нет SMS-пароля! Не могли бы вы мне выслать новый SMS-пароль?
Вот так вот. Так если пользователи хранят эти смски (и чистят только в случае переполнения памяти), то почему бы не хранить на телефоне файл-пароль?

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

А так бы было все хорошо, для входа с настольного компьютера, достаточно чтобы телефон был в зоне досягаемости WI-FI. Но опять таки, на компьютере должна быть либо карта либо внешнее WI-FI решение.

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

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

-под "флэшкой" я подразумевал внешний носитель информации. а смартфон он сам уже и есть и компьютер, и "внешний носитель".

-проблема в том, что на смартфоне так и получается: например, на моем самсунге нет какого-то навороченного файлового менеджера. я (честно) не знаю даже как на нем файлы переименовывать. поэтому файл с сервера упадет в легкодоступное место и будет иметь имя "PASSWORD" или "Переименуйте меня", что достаточно легко может быть подсмотрено другим лицом..

-ну лично я бы положил свой файл-пароль вглубину какого-то дерева каталогов (которое я всегда хорошо помню), во всяком случае не в корень C:\ - и мне не трудно взять этот файл оттуда, чтобы 1 раз загрузить его на сервер для авторизации (потом будет работать кука)

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

-Вы не поняли. при регистрации на сайте пользователь делает фото (например, своей кошки) cat.jpg и отсылает на сервер. на сервере производится (в простейшем случае) md5() содержимого cat.jpg и сохраняется в базе данных. При входе в следующий раз на сайт неавторизованный пользователь должен отправить ТОТ ЖЕ САМЫЙ файл cat.jpg, а не фотографировать беременную кошку снова.
Системы распознавания образов (идентификации лиц) наименее защищенные. Перед объективом можно поставить фото Клиента и большинство систем сработают положительно. Другое дело - отпечаток пальца (направление в Айфонах) и анализ радужной оболочи глаза (иридодиагностика). Однако пока такие датчик не будут распространены как сейчас хотя бы вебкамеры - об их массовом использовании говорить рано.

laimas,
если говорить не об удобстве, а о степени защищенности двух подходов (1.логин/пароль; 2-только файл-ключ), то Вы можете четко сказать, чем второй вариант хуже?
Я рассуждаю так: логин - это номер телефона или email, т.е. 10-20 практически несекретных символов, плюс 5-10 типо секретных символов пароля. Файл-ключ содержит 1024 символа случайной последовательности. Чем же второй вариант хуже первого?
Даже методом перебора и загрузки разных файлов на сервер со случайной текстовой последовательностью второй вариант на три порядка надежнее. В остальном они вроде бы равны.

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

Новая папка
    Новая папка
        Новая папка

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

В общем реальность покажет насколько это имеет право на существование.

Я предполагал, что речь идет о хеше единственного фото, но уж слишком это не серьезно, тут вообще никакой защищенности нет.

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

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

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

-не понял.. не услышал ничего конкретного, почему это не серьезно? и что значит "единственного" фото? речь об одном файле, хеш которого хранится в базе, также как хранят хеши паролей, а не сами пароли.

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

laimas,
про Инстаграм понятно, про фото в самом начале своего поста я ничего и не писал. речь ведь идет о файле со случайной последовательностью, присланном с сервера.
мне не понятна вот эта фраза "Я предполагал, что речь идет о хеше единственного фото" (или файла?) а если файл не единственный, то что??

Распознавание, то есть если не запомнен пользователь, то требует "селфи" новое, получили, сверили, типаж тот, Ок.

Я не говорю о распознавании фото и идентификации личности по фото при авторизации на сайте. Это полный бред. Хоть одно фото, хоть 10, хоть по старому, хоть по новому. Кто угодно может взять где угодно ВАШЕ фото и отправить JEPEG-файл для идентификации лица, соответственно, элементарно получить несанкционированный доступ. Даже Ваш товарищ, сидящий за соседним столом, может втихаря Вас сфоткать.
Распознавание образа лица реально применимо не по файлам, а по реальным объектам на видеокамере, например, в аэропорту или в банке, когда Вы в определенной комнате физически смотрите в объектив снимающей камеры. И то тут вопросы с прической, бородой, усами, очками..
Я говорю о файле со случайной последовательностью, который пользователь отправляет на сервер для авторизации. Как вариант, вместо такого файла может быть использовано какое-то самопальное фото. И "селфи" - это не обязательно лицо Клиента (что требует обычная система распознавания). сфотографировать можно пол, потолок или лампочку в люстре, что нет смысла отправлять в Инстаграм или в ВК. Важно то, что последовательность бит в этом фото-файле будет типа псевдослучайна и это можно отправлять на сервер. А если она и не сильно случайна, то 1 миллион RGB-байт в фото - это по-любому лучше, чем 10 байт обычного "секретного пароля" типа "mama123456".

Я понимаю, что имеется ввиду. Делайте, чем-то это выгоднее логина и пароля, я лично не считаю.

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

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

Судя по сообщениям и это хотят перенести в виртуальность. Сдается мне, что это станет реальностью, уверен.

Что это?? удаленно маячить лицом перед камерой? Не будет такого. Если Вас запрут в комнате и за камерой смартфона направят взведенный пистолет, то Вы будете мило улыбаться перед объективом, идентифицироваться в соответствующей банковской системе и... переводить деньги куда вам скажет владелец пистолета (изобретение 90-х..)

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

я же не сказал, что этого не будет, потому что ФАНТАСТИКА! технически это можно сделать просто сегодня. Вопрос как это люди будут использовать? Когда я только пришел в веб и не знал ни что такое SQL-инжекция, ни XSS.. я сделал чат вообще БЕЗ авторизации (ну не гений, аа?? ;) Каждый выбирал себе имя, все так радовались, всем так нравилось, все общались.. с месяц. а потом пришел один козел и как он выразился "начал учить меня жизни". Он постил порнуху, вставлял javascript и тд и тп. ммда.. хороший был урок. С тех пор на все фантастические нововведения я смотрю с точки зрения "того козла" и потенциального вреда, который он может нанести людям.
Ну ладно, раз Вы сказали "чем-то это выгоднее логина и пароля, я лично не считаю" и не привели технических аргументов, то, видимо, их уже и не будет.
Спасибо.

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

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

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

Что касается авторизации, построенной на принципе распознавания фото:
http://rootgadget.com/ubiraem-foto-parol/
Схема обхода фото-пароля достаточно несложная, вам надо разыскать фото лица овнера смартфона или видео крупным планом и вывести это на планшет, телевизор или монитор, после этого можно разблокировать Android смартфон, наведя переднюю камеру на выведенное изображени. В результате вы выдаёте фотку человека за настоящего кентяру. Даже сам Android уведомляем, что сей способ защиты очень неэффективен и любой кент, схожий с вами захочет сделать анлок вашего телефона.

И что? Touch ID тоже взломали, но это не означает, что от этого откажутся.

Программно можно различить фото и видео? Можно, а если так, прокатит ли проекция фото на экране ТВ?

Вы когда-то поступили опрометчиво и были наказаны взломом своего детища. Урок печальный заставил пересмотреть взгляды на безопасность и внести коррективы в код. И так будет всегда, а иначе и не может быть, лучшим и более надежным продукт делается за счет новых и программных решений, алгоритмов, и новых аппаратных решений. Так что не спешите выносить приговор. :)

-конечно прокатит! в смысле для взломщика аккаунта. по моему мнению на сегодняшний день достойно не работает ни одна система авторизации, построенная на принципе распознавания образов (будь то лицо, глаз, отпечаток пальца), потому что системе можно подсунуть "слепок" с оригинала, пусть и некачественный или мёртвый (гмм..) оригинал. система его всё-равно распознает, т.к. в неё изначально заложена помехоустойчивость.
Совсем другое дело - сравнение файла по цифровому содержимому (о котором я писал в посте) - здесь изменение хотя бы одного бита приведет отказу в авторизации.
Если злоумышленник попытается грузить на сервер разные файлы 1 раз в секунду, то для перебора последовательности из 1024 символов ему потребуется.. эээ... ну короче несколько сотен лет. или я не прав?

Ошибаетесь.

Ага, ну прям стена нерушимая. :)

Зачем вообще фото, которое ничем не отличается от передачи логина и пароля? Это просто подмена одного другим.

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

-докажите

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

-да, но, как говорится в одном анекдоте - "разница в цене!". логин/пароль - это 20 символов, зачастую с заложенным человеческим смыслом типа "vladivostok123". а 1000-2000 случайных символов - это... разве Вы не видите разницу??

-не забывайте, что так же развиваются и системы синтеза. имею ввиду, что из видео можно нарезать любые кадры, а из фото сделать любой видеоряд и подсунуть системе. даже по телевизору показывают мультики кукол с лицами президентов, а что мешает создать аналогичное видео с Вашим лицом?!
можно и аппаратно: сейчас видеокамеры уже размером с пуговицу - Вы не заметите, как Вас снимут в метро со всех ракурсов и пошлют видео в систему..
Короче говоря, мне некогда "терпеть, ждать.." пока кто-то разработает непробиваемую систему идентификации на основе распознавания фото/видео. Мне нужно внедрять приемлемую систему сейчас и сегодня.

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

Если вы занимались 3D моделированием, то должно быть известно о рендере сцен, просчетах теней в зависимости от источника освещения, его положения и его характеристик, а также перспективы объекта (камеры). То есть математические модели позволяющие определить движение 2D объекта перед нами или же это 3D объект.

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

-я знаю об этом. но в описываемом мною механизме не используется никакая PHP-библиотека работы с графикой, либо другая. отправляемый фото-файл не подвергается никаким преобразованиям типа ресайз/масштабирование и т.п. И никто не собирается считывать данные из BMP-матрицы на экране. Фото-файл - это просто stream (поток байт). С аналогичным успехом можно было бы использовать в качестве файла-пароля mp3-саундтрек. Однако его я рекомендовать не буду, т.к. практически все mp3 скачаны из интернета, а не сделаны владельцем смартфона с помощью своей видекамеры (т.е. эти файлы не уникальны).

А вы думаете, что я подвергаю изменениям загружаемый файл? Нет, но JPEG придет такой, каким определит его устройство, платформа, ПО, и каждый раз это по данным будут новый файл. А значит и md5 каждый раз будет новый.

Вы попробуйте, а GD для того, чтобы понять причину. А причина в том, что цвет (данные о цвете) зависят от выше указанного. Поэтому и существует такое понятие как "безопасная палитра", когда я писал, что делал на изображении, то упоминал, что это был файл с индексированной палитрой, иначе сервер будет получать мусор (шум) 100%.

и одновременно есть матмодели синтеза 3D объекта по трем 2D-фоткам (снятым с разного ракурса). Поэтому системе, которая отличает 3D от 2D будут показывать синтезированное виде с учетом всех источников света, перспективы и т.д. А, как известно, системы синтеза всегда на шаг впереди перед системами распознавания. Так было и с человеческой речью, и с вирусами..

эээ.... что-то тут не так. причем тут вообще JPEG? файл никак не может быть изменен скриптом загрузки от Клиента на сервер, независимо от его типа, формата, назначения! то, что Вы сказали, у меня просто в голове не укладывается. Может возьмем с javascript.ru пару картинок, посчитаем их MD5() и сверим данные? клянусь хеши будут одинаковые. на что бы поспорить?.. ;)

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