Всем доброго дня Есть проект (внутренняя crm). Вход в нее по логину и паролю. В зависимости от логина присваивается роль и т.д. - Это неинтересно. Возник интересный вопрос. Руководство хочет обезопасить систему путем введения помимо логинов и паролей некоего уникально идентификатора пользователя. Т.е. помимо логина и пароля нужно проверять еще кое-что. Будучи сутра не выспавшимся я и ляпнул "помимо авторизации проверять железо пользователя" - видел на какой-то платежной системе. Как мне тогда казалось perfect pay. Сейчас сижу (уже день) и понимаю какой накуренный я был предложив эту идею. Перепутал perfect pay и webmoney (декстопным приложением), забыв что java апплеты практически везде отключены (особенно на телефонах и планшетах). Вот сижу день у разбитого корыта и не знаю что делать дальше. Идея начальству очень понравилась, они ее просто за яйца схватили и чтобы отказались нужно предложить что-то похожее, только еще и с плюсами. Из прочитанного имею это: http://samy.pl/evercookie/ http://yro.slashdot.org/story/08/10/14/1656251/flash-cookie ... acy-threat и на закуску это (от чего сам афанарел (см. последнюю вкладку)) http://www.macromedia.com/support/documentation/en/flashpla ... ger06.html ну и это https://panopticlick.eff.org/ Прошу помощи!!! Есть ли еще кое-что, что поможет обезопасить систему помимо логина и пароля пользователя. Отзовитесь!!!
двухфазная (двухфакторная) аутентификация. например с подтверждением кода из смс или с помощью локального генератора ответов - типа Google Auth в андроиде. http://habrahabr.ru/post/150106/
Спасибо за ответ. В системе работает около 500 человек. Штука классная, но ее применение в наших условиях проблематично. Пользователи - порядка 30% стационарные ПК, 35-40% нотики на винде, остальные телефон или планшеты с разными операционками. Брелки носить никто не будет, платить за брелки - никто не будет. Видел лет 5 назад у знакомого в дойчланде - у них vpn так поднят был. Как вы смотрите на отпечаток браузера (https://panopticlick.eff.org/), который складывать в куку (evercookie или флешкуку)? Это дело также писать в БД. При вводе логина и пароля сверять и делать выводы. Если кука пуста или не равна значению в БД отсылать на почту пользователю уникальный хеш. Если этот хеш правильно введен - ставим куку заново и обновляем запись в БД . Разрешаем пользователю войти. Также не помню в какой платежке встречал, смена ip также влияет на обновление куки. IP поменял - проверяешь почту, и начинаешь все заново. Можете раскритиковать данный алгоритм!?
Фингерпринт он и в африке фингерпринт. Главное чтобы малейший чих не означал, что надо заново лезть на почту за новым кодом, а то иначе в день люди будут хватать по десятку таких писем счаться, и каждое будет бесить больше предыдущего. А так - снимайте хеш с IP+юзерагент+логин, вам за глаза хватит. Если еще ajax-ом соберете инфу, идентифицирующую как-нибудь устройство, например, разрешение экрана, то еще забавнее.
Может домен тогда уж? А брелки стоят дешево, если по многу брать. И не обязательно USB, бывают просто с числом.
Есть жеж pm_fp, достаточно популярная хрень, в узких кругах https://www.onlinebanking.pnc.com/JavaScriptLib/pm_fp.js
да, это он самый, дополнительно можно его разбавить чем-нибудь, например при регистрации пользователь картинку выбирает какую-то из предложенных, а потом если вдруг отпечатки не сходются, но юзер/пароль верны, попросить его тыкнуть в пикчу.
Спасибо, такое в принципе рассмотреть можно и нужно наверное. Самое легкое и в пределах одной страницы. Вчера еще посоветовали карты изображений (типа 30 картинок и в случае проблемы надпись "Выберите седьмую и нажмите ОК") - это тяжеловато мне кажется. А так просто ради любопытства. Почему производители браузеров не могут хранить хеш слепка железа системы в переменной js, которая будет тупо для чтения (как user agent и пр.). Это избавит разработчиков от такого онанизма как fingerprint, позволит сделать безопасные авторизации. Из минусов как я вижу - это типа privacy policy, но блин пускай хранят его в не расшифровываемом хеше. Какие проблемы?
Еще можно придумать такой вариант: ты на сервере генерируешь по одному тебе известному алгоритму хэш, и js сует его в localStorage.
такие, что расшифруют. Это же будет стандартом. У всех браузеров один алгоритм. Один метод сборки. Одна строка на хеширование. Ведь все браузеры на одном компе должны давать единый хеш. Длина строки известна, ее структура известна, возможные фрагменты известны, алгоритмы шифрования известны. Тут даже не радугой, а просто брутфорсом можно будет управиться. Это раз. Браузер не должен иметь такого доступа к системе, чтобы иметь возможность хотя бы опрашивать ее железки - это два. Из соображений безопасности.
Я имел ввиду что-то типа imei для телефона (но не так строго). Т.е. сделать уникальный индентификатор - не проблема. Опрашивать железо каждый раз не нужно. Нужно это сделать один раз при установке браузера и на основании этого сгенерировать уникальный код, который не пихать в папку профиля, а куда-то выше. Но это к теме не относиться это так мысли вслух.
В симфоневском Sonata User Bundle есть готовая двухфазная аутентификация. Бесплатно Один раз считываешь QR-код своим телефоном чтобы создать учетку в приложении Затем, когда надо авторизоваться, после логина/пароля запрашивается код. Подсматриваешь его в телефоне (здесь у меня две учетки - родная гуглевая и для тестового сайта) и вводишь: магия!
Спасибо гляну. Насчет уникального идентификатора в браузере - сам себя подправлю. Народ сказал что типа такого в IOS было. Там эти св...лочи для показа рекламы предусматривали. Так вот выпилили эту функцию быстро. Причины выпиливания не озвучивают, но видать их много.