Здравствуйте, kochetkov.vladimir, Вы писали:
A>>Безумная мысль — GUID [частично] генерирует клиент. Ну или не GUID, а идентификатор вообще. KV>Я на выходных обычно впадаю в туплячку... А что это нам даст?
Даже при условии предсказуемости, теперь надо предсказать поведение сразу двух компьютеров в фиксированные моменты времени. Причём о клиентском информации нет.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, DOOM, Вы писали:
DOO>>
DOO>>- код или пароль, предъявленный при неуспешной попытке;
KV>Я писал все больше про успешные. А с отказами — тут палка о двух концах. С одной стороны — куда более качественная доказательная база из логов получается, случись вдруг что. С другой стороны, любой, кто имеет доступ к логам получит возможность существенно сузить количество перебираемых вариантов за счет анализа неуспешных попыток легальных пользователей. В принципе, можно шифровать все неправильные пароли ассиметрией, но это уже может вызвать вопросы у других умников
Мое мнение здесь однозначное — если распределенная система способна определить "код или пароль, предъявленный при неуспешной попытке", то у нее уже кривая схема аутентификации (правда здесь я бы не понят с такой точкой зрения ).
Re[11]: Разработчикам систем парольной аутентификации
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>>А еще можно просто прийти к юзеру с паяльником и он тебе идентификатор сам из куки на лист бумаги выпишет только все эти потуги будут иметь смысл только в том случае, идентификатор криптостойкий. Если же нет, то его в разы проще предсказать, а трояны, xss и паяльник отложить за ненадобностью. F>>В реальном мире терморектальный криптоанализ — значительно более действенное, а главное, значительно более дешёвое средство.
KV>С выделенным не согласен. Во-первых, оно требует наличия персональных данных атакующего. В общем случае, они тебе могут быть и неизвестны.
Ты, вероятно, имел ввиду ПД атакуемого.
Выше я приводил 2 случая применимости твоих рассуждений. Да, в случае "вконтактовского хомячка" персональные данные можно считать весьма условными, как и в случае с разными автоматическими вирусами/троянами, для которых раскрытие ПД жертвы — следствие их работы. Но, ещё раз, последствия таких атак для хомячка обычно очень небольшие.
KV>Во-вторых, для того, чтобы воспользоваться этим средством, необходимо твое физическое присутствие рядом с атакуемым. Или не тебя. Но это уже куда дороже.
Э... не обязательно с атакуемым. Цепочка, по которой проходят запросы от жертвы до сервера, обычно достаточно длинная. В некоторых случаях это может снизить цену физического присутствия в несколько раз.
И опять хочу подчеркнуть, что в основном рассматриваю существенные преступления — типа хищения миллиона баксов со счёта в банке, вскрытие базы данных центральной избирательной комиссии, перехват почты с обсуждением газовых контрактов и т.д. По сравнению с ними цена физических действий сильно ниже.
А так, ну подумаешь, уведут аську или отправят по контакт листу рекламу enlarge your penis. Ну даже если получат контроль над компом и превратят его в ноду ботнета. Делов-то
KV>В третьих, куда менее рискованно совершить преступление по 272ой или 273ей, находясь за сотни или тысячи километров от жертвы, нежели подписываться под вполне конкретные статьи УК, розыскная и судебная практика по которым значительно обширнее, чем по хайтековским статьям.
Насколько я знаю, "хайтековские статьи" не являются основными, а идут в довесок к тем самым вполне конкретным статьям УК. Небольшая практика по ним, скорее, следствие низкой социальной опасности. (Я уверен, что если вдруг действия злоумышленников реально затронут интересы властей, то и розыскные и судебные мероприятия будут молниеносными)
F>>Другой полуоффтопичный (но, мне кажется, имеющий прямое отношение к обсуждаемой теме) KV> Обсуждаемая тема — парольная аутентификация, если что.
Ну, во-первых, я указал на полуоффтопичность А. во-вторых, так я хотел продемонстрировать, как наличие административной составляющей сводит на нет все криптографические усилия.
Наверно да, оффтопик. Если бы можно было это выделить из темы в отдельную ветку... но скорее всего это не получится.
F>>Т.е. внезапно он узнал личности собеседников.
KV>Или сделал вид, что узнал, между прочим. Вообще, чтение той темы оставило на мой, дилетантский взгляд, ощущение значительного превосходства количества ников над количеством реально отписывающихся там людей.
Ну да. Часть сообщений под авторизованными никами, часть под "Alter Egо" — это такая модная замена здешнего слова "Anonim". Там при посылке поста есть галочка "опубликовать анонимно", тогда ник заменяется этим словом — для всех.
F>>Но вот вопрос, как эта инфа попала к неавторизованному сотруднику. Я понял бы, если бы он был местным безопасником или админом шлюза. Но простой сейлз?! KV>Даже если фишка с последующим разоблачением правда, то она могла попасть к нему кучей способов. Слишком мало информации, чтобы предметно фантазировать на эту тему
Вот у меня не получается придумать _хороших_ способов
F>>Вот представь, приходит к тебе кто-то и просит помочь вычислить коллегу, пишущего гадости на форуме — поможешь ему? KV>Нет конечно, по целому ряду причин. Но я — это я, а сотрудники ИВ — это сотрудники ИВ. Там может быть все, что угодно.
Тут очень тонкий момент, достойный отдельного обсуждения. С такой просьбой может прийти не простой сотрудник, а "большая шишка". И аргументация просьбы может быть очень разная, например, что в этих постах раскрыта важная информация, покрываемая NDA.
F>>Так что шифруй, не шифруй — всё равно получишь практически одно и то же. KV>Отлаживай, не отлаживай — все равно каждый баг будет предпоследним
Далеко не предпоследним это я тебе как разработчик говорю. Это, разумеется, не повод не отлаживаться. Но и впадать в паранойю тоже не стоит.
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>11. Доумившись до идентификаторов сессий (вам заняться больше нечем?) не изобретайте велосипед, вам и так есть где развернуть свою фантазию при реализации функции хэширования. Используйте в качестве идентификаторов GUID, или (вот это вообще будет бомба!) случайное двухзначное число, равное количеству секунд в момент входа в систему
Чем гуид не угодил? Слабый алгоритм генерации случайного числа? А что вместо него, если криптостойкий генератор в конкретной платформе недоступен?
KV>14. Капча — зло.
Это ты зря. В некоторых случаях это действительно зло. Мне попадались сайты, где угадать что написано удавалось с 3-4 попытки. На rsdn, кстати, хороший тому пример, периодически генерятся абсолютно нечитаемые картинки.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
Здравствуйте, AndrewVK, Вы писали:
KV>>14. Капча — зло.
AVK>Это ты зря. В некоторых случаях это действительно зло. Мне попадались сайты, где угадать что написано удавалось с 3-4 попытки. На rsdn, кстати, хороший тому пример, периодически генерятся абсолютно нечитаемые картинки.
Зло, зло. Простые капчи обходятся запросто (достаточно вспомнить кучу статей на хабре), а сложные по стоимости сопостовимы с затратами по обычной обработке роботных действий — причём и по стоимости создания, и по стоимости сопровождения (число жалоб на спам не сильно больше числа жалоб на сработавшую капчу).
А наличие на рынке тысяч китайцев по цене 10 баксов за тысячу капч вообще делает все поползновения бессмысленными
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Re[4]: Разработчикам систем парольной аутентификации
Здравствуйте, DOOM, Вы писали:
KV>>Ну, они там немножко не правы. Ведь кто-нибудь может вводить заведомо неправильные пароли, используя чужой логин. Или не кто-то, а скрипт. Или не логин, а логины. Получится DoS
DOO>Ну для этого и капча и ограничения per IP и все такое...
Публичные прокси и антикапча. Ваш ход.
Re[5]: Разработчикам систем парольной аутентификации
Здравствуйте, tlp, Вы писали:
DOO>>Ну для этого и капча и ограничения per IP и все такое... tlp>Публичные прокси и антикапча. Ваш ход.
Блокировать прокси по тем же листам
Использовать WAF'ы с динамической блокировкой по IP и т.п.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>12. Двухфакторная аутентификация, с отправкой сессионного пароля в SMS-сообщении снимает ровным счетом все угрозы, связанные с несанкционированным доступом. Плюньте в глаз тому, кто будет утверждать обратное. Кстати, в этом случае, будет очень удобно использовать мобильный телефон пользователя для восстановления его основного пароля.
2 раза перечитал, так и не понял. Чем вам OTP по SMS то не угодили?
Re[6]: Разработчикам систем парольной аутентификации
Здравствуйте, DOOM, Вы писали:
DOO>Здравствуйте, tlp, Вы писали:
DOO>>>Ну для этого и капча и ограничения per IP и все такое... tlp>>Публичные прокси и антикапча. Ваш ход. DOO>Блокировать прокси по тем же листам
Разговор идет про DoS с блокированием аккаунтов юзерам, вы предложили решение, оно не работает в случае проксей и антикапчи.
KV>Ну, они там немножко не правы. Ведь кто-нибудь может вводить заведомо неправильные пароли, используя чужой логин. Или не кто-то, а скрипт. Или не логин, а логины. Получится DoS
Re[9]: Разработчикам систем парольной аутентификации
Здравствуйте, tlp, Вы писали:
tlp>Причем тут брутфорс? tlp>Разговор идет про DoS с блокированием аккаунтов юзерам, вы предложили решение, оно не работает в случае проксей и антикапчи.
Дело в том, что целенаправленно блокировать аккаунты — это какое-то странное занятие. Профит где?
А как побочный эффект от брутфорса — вполне себе.
Про решение уже сказал — качественно настроенный WAF сможет выявить и шибко хитроумную атаку и через какое-то время просто заблокирует все твои открытые прокси.
Кстати, я еще не упоминал сервисы репутации — нынче они достаточно шустрые, поэтому открытый прокси попадет в черные списки примерно также быстро, как и открытый почтовый релэй.
Re[2]: Разработчикам систем парольной аутентификации
Здравствуйте, ArhAngelVezel, Вы писали:
KV>>12. Двухфакторная аутентификация, с отправкой сессионного пароля в SMS-сообщении снимает ровным счетом все угрозы, связанные с несанкционированным доступом. Плюньте в глаз тому, кто будет утверждать обратное. Кстати, в этом случае, будет очень удобно использовать мобильный телефон пользователя для восстановления его основного пароля.
AAV>2 раза перечитал, так и не понял. Чем вам OTP по SMS то не угодили?
Отжимаем у жертвы телефон. Если жертва этого не заметит и запросит OTP на теперь уже наш телефон — profit, мы в системе. Если заметит, но не сразу побежит блокировать sim’ку — у нас есть окно, в течение которого мы можем запросить восстановление основного пароля, и снова profit. В любом случае, мы заDoSили жертву до момента получения новой sim’ки.
Кроме того, мы можем заранее заразить комп юзера кейлоггером/сниффером/BHO, или же устроить man-in-the-middle на канал между компом юзера и сервером, или же заспуфить сервер и заманить юзера на подделку, и спереть его пароль. В этом случае мы можем попасть в систему, даже если восстановление основного пароля на телефон не предусмотрено, пока юзер блокирует и меняет sim’ку.
Re[3]: Разработчикам систем парольной аутентификации
Здравствуйте, Centaur, Вы писали:
AAV>>2 раза перечитал, так и не понял. Чем вам OTP по SMS то не угодили?
C>Отжимаем у жертвы телефон. Если жертва этого не заметит и запросит OTP на теперь уже наш телефон — profit, мы в системе. Если заметит, но не сразу побежит блокировать sim’ку — у нас есть окно, в течение которого мы можем запросить восстановление основного пароля, и снова profit. В любом случае, мы заDoSили жертву до момента получения новой sim’ки.
1. В хорошей системе OTP приходит с мобильного номера зашифрованное в несколько несвязных друг с другом слов. Понять что это за слова сложно.
2. Маска, темный переулок и горячий паяльник работают в разы эффективней. В данной же схеме мы видим больше социальную инженерию, чем кибер-атаку..
C>Кроме того, мы можем заранее заразить комп юзера кейлоггером/сниффером/BHO, или же устроить man-in-the-middle на канал между компом юзера и сервером, или же заспуфить сервер и заманить юзера на подделку, и спереть его пароль. В этом случае мы можем попасть в систему, даже если восстановление основного пароля на телефон не предусмотрено, пока юзер блокирует и меняет sim’ку.
Это делается и в случае с "постоянным паролем". С OTP через сим мы гарантируем, что вход юзвера будет единичным.
Re[4]: Разработчикам систем парольной аутентификации
Здравствуйте, SergH, Вы писали:
SH>Здравствуйте, kochetkov.vladimir, Вы писали:
SH>>>Ещё посолить неплохо бы.
KV>>И растянуть
SH>Я не знаю, что это значит SH>Объясни?
Здравствуйте, ArhAngelVezel, Вы писали:
AAV>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>12. Двухфакторная аутентификация, с отправкой сессионного пароля в SMS-сообщении снимает ровным счетом все угрозы, связанные с несанкционированным доступом. Плюньте в глаз тому, кто будет утверждать обратное. Кстати, в этом случае, будет очень удобно использовать мобильный телефон пользователя для восстановления его основного пароля.
AAV>2 раза перечитал, так и не понял. Чем вам OTP по SMS то не угодили?
Сами по себе, сеансовые пароли есть гуд. Но ровно до тех пор, пока канал пересылки сеансового пароля не начинает пересекаться с каналом передачи основного пароля в процессе его восстановления или замены. Ибо в этом случае происходят вот такие вот конфузы: http://www.personalmoney.ru/txt.asp?sec=1525&id=1196427
Самое забавное было в этой истории то, что незадолго до начала хищений, Альфа-банк сертифицировался на соответствие PCI DSS (http://www.itsec.ru/newstext.php?news_id=53489). Но пересечение каналов передачи основного и сеансового пароля почему-то в ходе сертификации выявлено не было
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>11. Доумившись до идентификаторов сессий (вам заняться больше нечем?) не изобретайте велосипед, вам и так есть где развернуть свою фантазию при реализации функции хэширования. Используйте в качестве идентификаторов GUID, или (вот это вообще будет бомба!) случайное двухзначное число, равное количеству секунд в момент входа в систему
AVK>Чем гуид не угодил? Слабый алгоритм генерации случайного числа?
Ага
AVK>А что вместо него, если криптостойкий генератор в конкретной платформе недоступен?
Берешь нестойкий GUID и sha-512-ишь его случайное число раз. Проверяешь, нет ли уже сессии с таким айдишником (мало-ли, свойство уникальности в этом случае может и нарушаться) и, если нет, то выдаешь в качестве айдишника. Если есть, то еще несколько раз sha-512-тишь и, см. выше.
KV>>14. Капча — зло.
AVK>Это ты зря. В некоторых случаях это действительно зло. Мне попадались сайты, где угадать что написано удавалось с 3-4 попытки. На rsdn, кстати, хороший тому пример, периодически генерятся абсолютно нечитаемые картинки.
Там где нет рисков, связанных с автоматическими регистрациями, там и капча не нужна. Там где есть, альтернатив ей особо пока и нет Мы — хороший тому пример
Здравствуйте, DOOM, Вы писали:
DOO>Мое мнение здесь однозначное — если распределенная система способна определить "код или пароль, предъявленный при неуспешной попытке", то у нее уже кривая схема аутентификации (правда здесь я бы не понят с такой точкой зрения ).
Да брось, тебя я в той теме поддерживал и еще несколько участников, так что все ок
Обсуждаемая тема — парольная аутентификация, если что.
