Comments 53
1. Простое шифрование по алгоритму md5 и передача...Если речь идет о шифровании на стороне пользователя, то какие средства для шифрования использовать? Где хранить secret key для hmac? На первый взгляд, притянутая за уши к ssl технология. Все-таки, если есть свой айпи, лучшего решения, чем использует вебмани не найти.
3. Блокировка пользователя после 7-10 неудачных попыток входа.Пользователя или его айпи (если речь идет о компаниях с филиалами? Если настоящий захочет зайти?
Практически исключает взлом пароля путём перебора.
И пиктокод после трех).
8. Система привязки пользователей к конкретным IP/дням/времени работы.Понравилось. Вспомнил школу, где нам выдавали машинное время по расписанию уроков.
В принципе, интранет-системы на базе LAMP-а это часть поддержки бизнеса. Например, интернет-магазин интегрированный со складом, бухгалтерией, а не банально присылающий письма, что пришел заказ, и пр. Риск потери информации чреват банкротством или снижением капитализации компании (речь не о нашей стране, где основные риски — "неверный выбор стратегии развития, ценовые и экологические" - мнение РБК-дэйли).
1. Спасибо за (опосредованное) указание на ошибку. Имелось ввиду хеширование.
В данном случае SSL технология позволяет забыть о нюансах использования HMAC со стороны клиента, шифруя данные. Согласен с её "притянутостью".
Secret key для HMAC приходит к пользователю вместе со страницей. Меняется с каждой перезагрузкой страницы.
Со стороны сервера он хранится в сессии. Сессия хранится исключительно в БД.
Можно ссылку или подробнее про "решение вебмани"? Подразумевается софт-клиент или что?
2. Блокировку IP считаю бессмысленной, именно пользователя.
В случае блокировки, человек, имеющий права на управление аккаунтами получает уведомление.
Так же, к данному человеку может обратиться и "настоящий пользователь".
Это - безопасно.
3. Если я вас правильно понял, то вы зря недооцениваете привязку к IP/времени.
Благодаря данной возможности и подробному мониторингу реально пресекаются "ненужные действия" пользователя.
В том числе и "вынос" информации за пределы компании.
А неудобства данная мера (будучи один раз настроенной) не приносит никакого.
4. Системы, описанные вами, ещё более сложны. Я говорю о системе с надводной частью (пусть будет интернет-магазин, доступный абсолютно всем) и подводной - доступной только сотрудниками компании.
Если бизнес компании построен исключительно вокруг данной системы - это очень и очень рискованно.
Грамотно написанных текстов о безопасности подобных систем я не встречал.
В данном случае SSL технология позволяет забыть о нюансах использования HMAC со стороны клиента, шифруя данные. Согласен с её "притянутостью".
Secret key для HMAC приходит к пользователю вместе со страницей. Меняется с каждой перезагрузкой страницы.
Со стороны сервера он хранится в сессии. Сессия хранится исключительно в БД.
Можно ссылку или подробнее про "решение вебмани"? Подразумевается софт-клиент или что?
2. Блокировку IP считаю бессмысленной, именно пользователя.
В случае блокировки, человек, имеющий права на управление аккаунтами получает уведомление.
Так же, к данному человеку может обратиться и "настоящий пользователь".
Это - безопасно.
3. Если я вас правильно понял, то вы зря недооцениваете привязку к IP/времени.
Благодаря данной возможности и подробному мониторингу реально пресекаются "ненужные действия" пользователя.
В том числе и "вынос" информации за пределы компании.
А неудобства данная мера (будучи один раз настроенной) не приносит никакого.
4. Системы, описанные вами, ещё более сложны. Я говорю о системе с надводной частью (пусть будет интернет-магазин, доступный абсолютно всем) и подводной - доступной только сотрудниками компании.
Если бизнес компании построен исключительно вокруг данной системы - это очень и очень рискованно.
Грамотно написанных текстов о безопасности подобных систем я не встречал.
Мне приходилось делать такую систему более года назад — управление контейнерным стоком в Северном порту южной столицы. Это был ппц интересный проект. Компания перешла с экселя на эту систему. Более того, потом понадобилась поддержка мультиязычности для филиала компании в Антверпене. Сейчас перевожу на аякс и некоторое подобие гуглшита и обязательно приму во внимание вашу статью. Спасибо)
>хочу рассказать о собственном опыте защиты веб-приложений, используемых на предприятиях/фирмах с ограниченным числом сотрудников.
Если число сотрудников ограничено (пусть и большим числом, но ограниченно) - первой линией обороны должно стать ограничение списка IP. Причем на уровне железа - взломать Cisco несколько сложнее, чем приложение. Например, система газовых аукционов, которую довелось проектировать, разрабатывать и внедрять для Газпрома, жестко ограничена в доступе по списку IP адресов.
Если число сотрудников ограничено (пусть и большим числом, но ограниченно) - первой линией обороны должно стать ограничение списка IP. Причем на уровне железа - взломать Cisco несколько сложнее, чем приложение. Например, система газовых аукционов, которую довелось проектировать, разрабатывать и внедрять для Газпрома, жестко ограничена в доступе по списку IP адресов.
Честно говоря если Вы пишете о своем личном опыте, то наверное имело бы смысл не абстрактно перечислить возможные методы решения, а описать конкретное решение, реализованное вами. Описать решаемую задачу и архитектуру (подходы) более детально. В данном случае Вы перечислили достаточно очевидные вещи, к тому же малосистематизированные (на мой личный взгляд) и без привязки к конкретным ситуациям. Создается впечатление, что целью топика было притянуть за уши количество методов к числу 10.
Чтобы не быть голословным:
- пункт 2 малоприменим и неудобен в большинстве веб приложений, в то же время в банковской сфере достаточно активно внедряется для защиты пинкодов и прочих банкоматных несложных паролей.
- пункт 3 для защиты приложений в вебе сложноосуществим
- пункт 4 не относится к проблеме аутентификации по логину-паролю, сессия есть следующая фаза работы
- пункт 5 не работает для предприятий с одним IP и типовой настройкой рабочего места (читай "большинства корпоративных юзеров")
- пункт 6 не раскрыт, смысл малопонятен
- пункты 7 и 8 на практике создадут больше проблем, чем повысят защиту. Менеджер Катя будет долго материться в момент демонстрации прототипа системы заказчику находясь в Далласе на слете соучредителей. А требования постоянной смены пароля приведут к записям на липких бумажках и критике системы, что в потенциале приведет к переходу на другой продукт.
- пункты 9 и 10 - фантазия, которая на практике может быть реализована, но не может быть внедрена.
Поэтому еще раз просьба - напишите что же конкретно сделали Вы в рамках своего решения. Тема эта достаточно актуальна и важна для обсуждения в среде профессионалов.
Кстати, есть такая книжка как "Аутентификация", автор Р.Смит. Возможно не лучшая. Но тем, кто интересуется темой но еще не копал - рекомендую. Многие вопросы будут сняты.
Чтобы не быть голословным:
- пункт 2 малоприменим и неудобен в большинстве веб приложений, в то же время в банковской сфере достаточно активно внедряется для защиты пинкодов и прочих банкоматных несложных паролей.
- пункт 3 для защиты приложений в вебе сложноосуществим
- пункт 4 не относится к проблеме аутентификации по логину-паролю, сессия есть следующая фаза работы
- пункт 5 не работает для предприятий с одним IP и типовой настройкой рабочего места (читай "большинства корпоративных юзеров")
- пункт 6 не раскрыт, смысл малопонятен
- пункты 7 и 8 на практике создадут больше проблем, чем повысят защиту. Менеджер Катя будет долго материться в момент демонстрации прототипа системы заказчику находясь в Далласе на слете соучредителей. А требования постоянной смены пароля приведут к записям на липких бумажках и критике системы, что в потенциале приведет к переходу на другой продукт.
- пункты 9 и 10 - фантазия, которая на практике может быть реализована, но не может быть внедрена.
Поэтому еще раз просьба - напишите что же конкретно сделали Вы в рамках своего решения. Тема эта достаточно актуальна и важна для обсуждения в среде профессионалов.
Кстати, есть такая книжка как "Аутентификация", автор Р.Смит. Возможно не лучшая. Но тем, кто интересуется темой но еще не копал - рекомендую. Многие вопросы будут сняты.
< Оправдываюсь>
Если честно, то сначала пунктов было 4. Самые первые 4 пункта.
Но после прочтения своей же статьи, я решил, что меня обвинят в непонимании предмета .
Поэтому я перечислил почти всё, что реально использую для защиты и позже добавил сноску - "update".
Если описывать конкретные решения, то на каждый уйдёт как минимум не меньше места, сколько ушло на все. Согласны? И кто осилит хотя бы половину?
Если тема реально интересна, можно описать реальные решения.
< /Оправдываюсь>
п.2
Чем?
п.3
Тем более не понимаю.
Простым языком:
Есть логин. Есть пароль. Если 10 раз ввели неверный пароль - логин заблокирован.
п.4
Не согласен.
Сессия есть начало работы пользователя с системой вообще.
И тот самый secret key для HMAC хранится именно в ней.
И "отпечаток пользователя" - тоже.
п.5
Понял о чём вы. О работе кучи пользователей через NAT.
Но это совершенно не важно для пункта 5. Привязка работать будет.
Пункт 5 говорит лишь о том, что если у пользователя сессию украдут, то воспользоваться ей не смогут. И ведь реально не смогут.
В вашем же случае становится возможным использование сворованной сессии сослуживцем, при условии работы с одного IP и использовании абсолютно идентичного браузера.
И, согласитесь, это требует вполне конкретных и определённых навыков.
п. 6
Пример: на данный момент я сижу на хабре и имею 7 кук от него. В этих куках лежат разные вещи типа "hbuid 543".
Ничего подобного в куках защищаемого веб-приложения быть не должно. Только имя куки и идентификатор (например "1f3870be274f6c49b3e31a0c6728957f").
п. 7-8
Вы меня не поняли. Читайте статью, что я привёл в голове своего хабротопика.
Там же я написал и комментарий: "Что хотелось бы добавить - имеет смысл проводить с пользователями дружеские беседы для чёткого понимания людьми зачем всё это нужно. Как показывает практика - это реально помогает."
п. 9
Частично согласен.
п. 10
Категорически не согласен.
Любая система, написанная человеком, имеет уязвимости. Невозможность создать полностью безопасной системы.
И мониторинг работы системы позволяет находить проблемы (и в том числе) с безопасностью. Я считаю мониторинг системы «победой малой кровью».
Повторюсь, если тема интересна - можно (сообща) выработать пункты и написать по ним цикл статей с реальными решениями.
Если честно, то сначала пунктов было 4. Самые первые 4 пункта.
Но после прочтения своей же статьи, я решил, что меня обвинят в непонимании предмета .
Поэтому я перечислил почти всё, что реально использую для защиты и позже добавил сноску - "update".
Если описывать конкретные решения, то на каждый уйдёт как минимум не меньше места, сколько ушло на все. Согласны? И кто осилит хотя бы половину?
Если тема реально интересна, можно описать реальные решения.
< /Оправдываюсь>
п.2
Чем?
п.3
Тем более не понимаю.
Простым языком:
Есть логин. Есть пароль. Если 10 раз ввели неверный пароль - логин заблокирован.
п.4
Не согласен.
Сессия есть начало работы пользователя с системой вообще.
И тот самый secret key для HMAC хранится именно в ней.
И "отпечаток пользователя" - тоже.
п.5
Понял о чём вы. О работе кучи пользователей через NAT.
Но это совершенно не важно для пункта 5. Привязка работать будет.
Пункт 5 говорит лишь о том, что если у пользователя сессию украдут, то воспользоваться ей не смогут. И ведь реально не смогут.
В вашем же случае становится возможным использование сворованной сессии сослуживцем, при условии работы с одного IP и использовании абсолютно идентичного браузера.
И, согласитесь, это требует вполне конкретных и определённых навыков.
п. 6
Пример: на данный момент я сижу на хабре и имею 7 кук от него. В этих куках лежат разные вещи типа "hbuid 543".
Ничего подобного в куках защищаемого веб-приложения быть не должно. Только имя куки и идентификатор (например "1f3870be274f6c49b3e31a0c6728957f").
п. 7-8
Вы меня не поняли. Читайте статью, что я привёл в голове своего хабротопика.
Там же я написал и комментарий: "Что хотелось бы добавить - имеет смысл проводить с пользователями дружеские беседы для чёткого понимания людьми зачем всё это нужно. Как показывает практика - это реально помогает."
п. 9
Частично согласен.
п. 10
Категорически не согласен.
Любая система, написанная человеком, имеет уязвимости. Невозможность создать полностью безопасной системы.
И мониторинг работы системы позволяет находить проблемы (и в том числе) с безопасностью. Я считаю мониторинг системы «победой малой кровью».
Повторюсь, если тема интересна - можно (сообща) выработать пункты и написать по ним цикл статей с реальными решениями.
п.2 - решения с виртуальными клавиатурами:
- для обеспечения приемлемого уровня защиты требуют установки ActiveX компонентов или java-апплета или еще чего-нибудь в этом роде, поскольку на чистом Javascript+HTML+CSS это все достаточно ненадежно будет работать. Поэтому это либо интранет, либо терминалы.
- в вебе виртуальные клавиатуры непривычны пользователю. Это тоже минус решению, рассчитанному на массу.
п.3 - проблема заключается в "заблокировать пользователя". В интернет это малоосуществимо, сопряжено с риском отсечь нужных пользователей. Корень проблемы - сложность идентификации конкретного пользователя. Про анонимные прокси вы знаете, про стирание и подделыванию куки тоже. Вариант с идентификацией по железу (номер проца и проч) малоосуществим для массового решения (см. комментарий выше по п.2).
п.5 - вы сами все написали, остался только один шаг - понять, что в крупных компаниях идентичные по настройкам рабочие места - обычная практика. Поэтому идентификация IP+браузер на деле работать не будет.
п.6 - не вижу ничего плохого в том, что какая-то несущественная информация хранится в cookies. Нужны конкретные примеры уязвимостей (они есть в любой литературе), это я как иллюстрацию к недостаткам изложения в статье привел. Напишите конкретнее - вопросов не будет.
п.7-8 - я все нормально понял. Рекомендую четко разделять в статьях идеальное и реальное. В теории вы все правильно написали. На практике работать не будет.
п.10 - да я не спорю что мониторинг нужен. Просто это не метод защиты от кражи пароля или его подделки, к аутентификации отношения не имеет. Это некий комплекс мер по минимизации убытков, то есть опять же процесс во времени происходящий ПОСЛЕ авторизации. Собственно я к тому, чтобы вы более четко фокусировали внимание читателя на какой-то мысли и не мешали все в кучу.
Возможно, мои мысли будут полезны когда будете писать что-то еще.
- для обеспечения приемлемого уровня защиты требуют установки ActiveX компонентов или java-апплета или еще чего-нибудь в этом роде, поскольку на чистом Javascript+HTML+CSS это все достаточно ненадежно будет работать. Поэтому это либо интранет, либо терминалы.
- в вебе виртуальные клавиатуры непривычны пользователю. Это тоже минус решению, рассчитанному на массу.
п.3 - проблема заключается в "заблокировать пользователя". В интернет это малоосуществимо, сопряжено с риском отсечь нужных пользователей. Корень проблемы - сложность идентификации конкретного пользователя. Про анонимные прокси вы знаете, про стирание и подделыванию куки тоже. Вариант с идентификацией по железу (номер проца и проч) малоосуществим для массового решения (см. комментарий выше по п.2).
п.5 - вы сами все написали, остался только один шаг - понять, что в крупных компаниях идентичные по настройкам рабочие места - обычная практика. Поэтому идентификация IP+браузер на деле работать не будет.
п.6 - не вижу ничего плохого в том, что какая-то несущественная информация хранится в cookies. Нужны конкретные примеры уязвимостей (они есть в любой литературе), это я как иллюстрацию к недостаткам изложения в статье привел. Напишите конкретнее - вопросов не будет.
п.7-8 - я все нормально понял. Рекомендую четко разделять в статьях идеальное и реальное. В теории вы все правильно написали. На практике работать не будет.
п.10 - да я не спорю что мониторинг нужен. Просто это не метод защиты от кражи пароля или его подделки, к аутентификации отношения не имеет. Это некий комплекс мер по минимизации убытков, то есть опять же процесс во времени происходящий ПОСЛЕ авторизации. Собственно я к тому, чтобы вы более четко фокусировали внимание читателя на какой-то мысли и не мешали все в кучу.
Возможно, мои мысли будут полезны когда будете писать что-то еще.
п. 2
Никаких ActiveX и прочих проприетарных технологий! :)
Посмотрите как клавиатура реализованна на сайте Яндекса.
Впрочем, я могу согласиться, что это непривычно.
Плюс, можно придраться, это пример защиты веб-приложения не от угрозы со стороны веба, а со стороны компьютера пользователя. Впрочем как и работа с куками.
п. 3
Здесь часть ответа.
Я упорно отказываюсь видеть невозможность блокировки/разблокировки пользователей.
п. 5
Я написал развёрнутый ответ на этот вопрос.
Плюс, вы забываете, что если это крупная компания, сервер будет стоять на её собственной площадке, рядом с сервером почты, интернета и домена. Отсюда вытекает что все пользователи для системы (сервера) будут иметь разный IP.
А если у этой крупной компании 2 - n крупных офисов, то это уже вопрос не работы системы, а настройки связи между офисами компании.
п. 7-8
Лично у меня это работает на практике.
Не так страшен чёрт, как его малюют :)
п. 10
Да почему после аутентификации?? (кстати не путаем с авторизацией)
Если вы (система) видите что пользователь пытается аутентифицироваться в нетипичное время, меняя IP каждые 3-5 неудачных попыток входа, с тех же IP прошло сканирование на типичные уязвимости - это не повод для принятия некоторых мер?
Мониторинг после аутентификации и авторизации - естесственно. Но он применим и во время.
Спасибо за замечания, постараюсь учесть.
Никаких ActiveX и прочих проприетарных технологий! :)
Посмотрите как клавиатура реализованна на сайте Яндекса.
Впрочем, я могу согласиться, что это непривычно.
Плюс, можно придраться, это пример защиты веб-приложения не от угрозы со стороны веба, а со стороны компьютера пользователя. Впрочем как и работа с куками.
п. 3
Здесь часть ответа.
Я упорно отказываюсь видеть невозможность блокировки/разблокировки пользователей.
п. 5
Я написал развёрнутый ответ на этот вопрос.
Плюс, вы забываете, что если это крупная компания, сервер будет стоять на её собственной площадке, рядом с сервером почты, интернета и домена. Отсюда вытекает что все пользователи для системы (сервера) будут иметь разный IP.
А если у этой крупной компании 2 - n крупных офисов, то это уже вопрос не работы системы, а настройки связи между офисами компании.
п. 7-8
Лично у меня это работает на практике.
Не так страшен чёрт, как его малюют :)
п. 10
Да почему после аутентификации?? (кстати не путаем с авторизацией)
Если вы (система) видите что пользователь пытается аутентифицироваться в нетипичное время, меняя IP каждые 3-5 неудачных попыток входа, с тех же IP прошло сканирование на типичные уязвимости - это не повод для принятия некоторых мер?
Мониторинг после аутентификации и авторизации - естесственно. Но он применим и во время.
Спасибо за замечания, постараюсь учесть.
Пожалуй последний мой комментарий, а то спорить можно до бесконечности, а на теоретическую часть тратить время скучно. Все таки хотелось бы о конкретных примерах поговорить.
по п.5 - особенно если это крупная компания, ее веб-сервер (как пример) будет стоять на хостинге где-нибудь на М9. Так что идентификация по IP не работает. А если это интранет система, то парольная авторизация там несет на порядок меньшие угрозы, и акцент на защите там совсем другой, поскольку возможности сисадмина совсем другие (+намного шире полномочия).
по п.5 - особенно если это крупная компания, ее веб-сервер (как пример) будет стоять на хостинге где-нибудь на М9. Так что идентификация по IP не работает. А если это интранет система, то парольная авторизация там несет на порядок меньшие угрозы, и акцент на защите там совсем другой, поскольку возможности сисадмина совсем другие (+намного шире полномочия).
Почему не раздать людям сертификаты и не забыть про парольную аутентификацию? Если это интранет, то это легко.
См. https://light.webmoney.ru
См. https://light.webmoney.ru
Вы сами говорите - если это интранет. Кроме того, данный процесс (раздача и использование) весьма непрост с организационной точки зрения. Технически же - все достаточно просто. А вот в промышленных объемах чтобы это организовать - это уже проблема и для большинства CIO и большинства сисадминов.
Электронные ключи решают эту проблему. Кстати у вас тут еще одного механизма авторизации нет. К сожалению он пока работает только под IE. Я говорю про SPANEGO.
На, это не очень просто, но, по-моему, проще 10 пунктов, о которых говорится в статье. А в качестве условия там написано "веб-приложений, используемых на предприятиях/фирмах с ограниченным числом сотрудников", то есть всё-таки интранет.
На=Да
К сожалению это не только интранет.
Так как большинство руководящих сотрудников не привязано к офису.
Так как большинство руководящих сотрудников не привязано к офису.
Сертификат поставить в браузер на ноутбуке.
лучше электронные ключи. Существенно надежней и безопасней.
Что вы имеете в виду? Где в браузере поддержка электронных ключей?
Самое смешное, что ключ украсть или потерять проще чем обычный пароль.
Что самое смешное этот ключ существует в одном экземпляре и в случае потери позвонить админу, чтобы он отозвал ключ минутное дело. В случае же если сертификат лежит на диске его можно в тихую скопировать и про это никто не узнает. К тому же кроме ключа обазательно должна быть парольная авторизация.
учим матчасть ;)
Я честно прочитал статью по ссылке. "Матчасти" там не увидел вообще. Каких-либо расхождений с моей статьёй тоже.
Да и вообще, мы здесь не о специфике работы интернет-банка говорим, ведь правда?
А если брать во внимание то, что автор рекомендует банк № 3, то предлагается всем пользователям раздать по конверту с кодами? :)
Да и вообще, мы здесь не о специфике работы интернет-банка говорим, ведь правда?
А если брать во внимание то, что автор рекомендует банк № 3, то предлагается всем пользователям раздать по конверту с кодами? :)
Привязка к IP и блокировка по IP плохо применимы в вебе. IP может быть динамическим (в случае diulup-а, например), кроме того, за одним IP могут жить несколько пользователей. И блокировкой такого IP можно отключить не один хост, а сегмент сети неопределённых размеров. Список вариантов защиты хороший, но для полноты картины не помешало бы уточнение случаев, когда каждый из них применим.
Пункт 4 можно развить: смену ID для сессий залогиненых пользователей можно делать не однократно после логина (если у вас это имелось ввиду), но и с заданным периодом. Теоретически это должно повысить сложность подмены SID.
Пункт 4 можно развить: смену ID для сессий залогиненых пользователей можно делать не однократно после логина (если у вас это имелось ввиду), но и с заданным периодом. Теоретически это должно повысить сложность подмены SID.
У меня нет ни слова по блокировку IP. Более того,я считаю её бессмысленной.
Привязка к IP - да.
В случае диал-апа пользователю после дисконнекта приходится заново коннектиться к провайдеру, ведь так?
Так вот пусть заново соединится и с корпоративным веб-приложением.
Конечно можно развить, это статья - пробный камень. Она вообще ни на что не претендует )
Привязка к IP - да.
В случае диал-апа пользователю после дисконнекта приходится заново коннектиться к провайдеру, ведь так?
Так вот пусть заново соединится и с корпоративным веб-приложением.
Конечно можно развить, это статья - пробный камень. Она вообще ни на что не претендует )
Если сильно заботится о безопасности, можно поставить и VPN.
Забыли одну важную вещь, практически панацею в некоторых случаях - это обычные таймауты.
На малых предприятиях все решается гораздо проще. Читал статью, где человек купил горсть мышек со сканером отпечатков пальцев.
Чтобы предотвратить кражу паролей можно использовать так называемые "Графические пароли": http://www.vipkonsalt.ru/index.php?ids=3…
Их реализация не настолько сложна, как может показаться.
Чтобы предотвратить кражу паролей можно использовать так называемые "Графические пароли": http://www.vipkonsalt.ru/index.php?ids=3…
Их реализация не настолько сложна, как может показаться.
Вот это действительно качественно. Спасибо за ссылку.
По графическим паролям - я полностью согласен!
Я писал в статье "... парольная защита – не единственный способ проверки подлинности ...".
Если вы имели реальный опыт внедрения (или есть ссылки) - с большим удовольствием бы почитал!
Я писал в статье "... парольная защита – не единственный способ проверки подлинности ...".
Если вы имели реальный опыт внедрения (или есть ссылки) - с большим удовольствием бы почитал!
кстати графические пароли можно с системой одноразовых паролей совместить.
Опыт внедрения - скоро будет. В данный момент ведется разработка второй версии одного городского портала, на котором будут внедряться новые, а также хорошо забытые старые технологии. Если к тому времени наберу достаточно кармы, обязательно все расскажу.
На данный момент есть наработки по вычислению и отсеиванию роботов при регистрации, например, на форумах. Скорее всего большинство из этого уже кто-то придумал, но во всяком случае один из простейших способов я удачно применяю на своих проектах. Если интересно могу поделиться.
На данный момент есть наработки по вычислению и отсеиванию роботов при регистрации, например, на форумах. Скорее всего большинство из этого уже кто-то придумал, но во всяком случае один из простейших способов я удачно применяю на своих проектах. Если интересно могу поделиться.
Кстати, раз пошла такая пьянка с привязкой к IP, к браузеру, невозможность для клиентов работать через прокси... Не проще-ли тогда написать своего клиента для юзверей?
Очень меня смущает второй пункт.
Какое же это усиление безопасности, если по сути печатать пароль большими буквами на экране?!
Тем более, что множество общедоступных шпионов снимают данные не только с клавиатуры.
Чисто гипотетически: если давать пользователям не короткие логин + пароль, а длинные, но легко запоминающиеся фразы - поговорки, слова из песен, стихов? А вместе с ключевой фразой снимать таймауты в наборе букв. Если менеджер Катя (© stealthy) всегда набирала 2мя пальцами, а тут вдруг "запорхала по клавиатуре всеми десятью" - повод задуматься ..или навставлять дюлей за copy-paste :D
Какое же это усиление безопасности, если по сути печатать пароль большими буквами на экране?!
Тем более, что множество общедоступных шпионов снимают данные не только с клавиатуры.
Чисто гипотетически: если давать пользователям не короткие логин + пароль, а длинные, но легко запоминающиеся фразы - поговорки, слова из песен, стихов? А вместе с ключевой фразой снимать таймауты в наборе букв. Если менеджер Катя (© stealthy) всегда набирала 2мя пальцами, а тут вдруг "запорхала по клавиатуре всеми десятью" - повод задуматься ..или навставлять дюлей за copy-paste :D
В теории все красиво. Да только менеджер Катя (© mot) может после корпоратива попробовать залогиниться в нажратом состоянии чтобы почту проверить, да и попасть от системы безопасности под раздачу из-за неожиданно увеличенных промежутков между попаданиями по клавишам :).
А с длинными фразами это конечно хорошо, только память у человека не резиновая. И набор длинной фразы для многих пользователей, которые медленно печатают да еще и с ошибками - это очень сложно будет. Тем паче что набор пароля как правило скрыт (звездочками).
А с длинными фразами это конечно хорошо, только память у человека не резиновая. И набор длинной фразы для многих пользователей, которые медленно печатают да еще и с ошибками - это очень сложно будет. Тем паче что набор пароля как правило скрыт (звездочками).
Согласен по спорности второго пункта.
Способ снятия данных с вирт. клавиатуры - слежение за отображением информации на экране?
Или запоминание передвижения/кликов мыши?
Способ снятия данных с вирт. клавиатуры - слежение за отображением информации на экране?
Или запоминание передвижения/кликов мыши?
Шпионить я так понимаю нынче можно только типа через видеокамеру через плечо (на это есть защита в виде мониторов с ограниченным углом обзора) или пытаться снять побочные излучения (что в реальной жизни только у шпиёнов получалось).
Поэтому виртуальная клавиатура - это для определенных применений очень хорошая защита. Те же движения мыши бесполезно перехватывать, поскольку у тебя кнопки в которые нужно тыкать меняются местами при каждом входе. Антифрауд системы для банкоматов еще дополнительно (знаю такое решение английской фирмы одной) красят кнопки для каждого юзера персонализированно, чтобы он привык к личной своей картинке на экране. И типа когда ему хацкер подсунет левый экран, типа "введи ка пароль" - он сразу понял что цвета то не его.
Поэтому виртуальная клавиатура - это для определенных применений очень хорошая защита. Те же движения мыши бесполезно перехватывать, поскольку у тебя кнопки в которые нужно тыкать меняются местами при каждом входе. Антифрауд системы для банкоматов еще дополнительно (знаю такое решение английской фирмы одной) красят кнопки для каждого юзера персонализированно, чтобы он привык к личной своей картинке на экране. И типа когда ему хацкер подсунет левый экран, типа "введи ка пароль" - он сразу понял что цвета то не его.
HMAC?! (потрясённо). И как у вас это работатает? Какой броузер это поддерживает?
И как выглядит менеджмент ключей в этой технологии, поделитесь?
Клиенты все, как зайки, субмитят свои ключи на сервер, перед тем, как авторизоваться?
Причём делают это на дискетках, в оффлайне?
И потом эти дискетки вставляют каждый раз, когда нужно установить сессию? И хранят под подушкой?
Только не скажите сейчас, что у вас клиентский ключ для HMAC один на всех. Не разрушайте мою веру в людей.
И кстати, в чём трудности использования SSL, технологии, которая поддерживатеся всеми клиентами и серверами?
И как выглядит менеджмент ключей в этой технологии, поделитесь?
Клиенты все, как зайки, субмитят свои ключи на сервер, перед тем, как авторизоваться?
Причём делают это на дискетках, в оффлайне?
И потом эти дискетки вставляют каждый раз, когда нужно установить сессию? И хранят под подушкой?
Только не скажите сейчас, что у вас клиентский ключ для HMAC один на всех. Не разрушайте мою веру в людей.
И кстати, в чём трудности использования SSL, технологии, которая поддерживатеся всеми клиентами и серверами?
Да-да, были мысли внедрить это именно так как вы описывали, в теории было красиво :)
Но на деле внедрилось именно то, что я описал - ключ приходит к клиенту вместе со страницей.
Новая (обновлённая) страница - новый ключ.
Если имеет место двусторонний перехват данных - то никакого толку (в случае достаточной квалификации взломщика) от данной системы нет. Если односторонний, от клиента к серверу (а часто его осуществить проще) - толк есть.
На клиенте это реализованно с помощью библиотеки Paul Johnston'a.
Трудности использования SSL в моём случае (а статья именно о моём опыте) - чисто организационные.
Но на деле внедрилось именно то, что я описал - ключ приходит к клиенту вместе со страницей.
Новая (обновлённая) страница - новый ключ.
Если имеет место двусторонний перехват данных - то никакого толку (в случае достаточной квалификации взломщика) от данной системы нет. Если односторонний, от клиента к серверу (а часто его осуществить проще) - толк есть.
На клиенте это реализованно с помощью библиотеки Paul Johnston'a.
Трудности использования SSL в моём случае (а статья именно о моём опыте) - чисто организационные.
уже сам наверное пожалел, что написал, да?
нормальная статья!
нормальная статья!
Sign up to leave a comment.
Парольная защита веб-приложений