Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, kochetkov.vladimir, Вы писали:
C>>>Скажем, в Java он делается из криптографически-сильного генератора случайных чисел. KV>>Я не силен в java... это оговорено в стандарте? C>На что? GUID должен как-то генерироваться из MAC-адреса и ещё чего-то там, только все на это нафиг забили.
JUG, кажись, позволяет генерить UUID и через MAC, только через JNI-вызовы вроде как.
Ну и товарищи из редмонда в методе Guid.NewGuid небось не забили на MAC-адрес (в MSDN ни строчки не нашёл про стандарты), а мелкомягкие технологии имеют довольно неплохую массу инерции
Re[7]: Разработчикам систем парольной аутентификации
Здравствуйте, Курилка, Вы писали:
К>JUG, кажись, позволяет генерить UUID и через MAC, только через JNI-вызовы вроде как. К>Ну и товарищи из редмонда в методе Guid.NewGuid небось не забили на MAC-адрес (в MSDN ни строчки не нашёл про стандарты), а мелкомягкие технологии имеют довольно неплохую массу инерции
Здравствуйте, Cyberax, Вы писали:
C>>>Скажем, в Java он делается из криптографически-сильного генератора случайных чисел. KV>>Я не силен в java... это оговорено в стандарте? C>На что? GUID должен как-то генерироваться из MAC-адреса и ещё чего-то там, только все на это нафиг забили.
Я про то, возможна ли ситуация, когда при переносе твоей ИС на платформу со сторонней реализацией JDK, UUID'ы вдруг перестают быть рандомными?
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Я про то, возможна ли ситуация, когда при переносе твоей ИС на платформу со сторонней реализацией JDK, UUID'ы вдруг перестают быть рандомными?
Безумная мысль — GUID [частично] генерирует клиент. Ну или не GUID, а идентификатор вообще.
Здравствуйте, kochetkov.vladimir, Вы писали:
C>>>>Скажем, в Java он делается из криптографически-сильного генератора случайных чисел. KV>>>Я не силен в java... это оговорено в стандарте? C>>На что? GUID должен как-то генерироваться из MAC-адреса и ещё чего-то там, только все на это нафиг забили. KV>Я про то, возможна ли ситуация, когда при переносе твоей ИС на платформу со сторонней реализацией JDK, UUID'ы вдруг перестают быть рандомными?
В существующих реализациях JDK — всё ОК. В теории, конечно, возможно — на эти библиотеки нет официального стандарта.
KV>9. Да-да, обязательно отражайте в логах все вводимые пароли. Потом, если внезапно рухнет база, ее можно будет легко по ним восстановить.
Ну по этому вопросу надо другим умникам обращение писать:
Подсистема регистрации и учета:
должна осуществляться регистрация входа (выхода) субъектов доступа в систему (из системы), либо регистрация загрузки и инициализации операционной системы и ее программного останова. Регистрация выхода из системы или останова не проводится в моменты аппаратурного отключения АС. В параметрах регистрации указываются:
— дата и время входа (выхода) субъекта доступа в систему (из системы) или загрузки (останова) системы;
— результат попытки входа: успешная или неуспешная — несанкционированная;
— идентификатор (код или фамилия) субъекта, предъявленный при попытке доступа;
— код или пароль, предъявленный при неуспешной попытке;
Re[3]: Разработчикам систем парольной аутентификации
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Ну, они там немножко не правы. Ведь кто-нибудь может вводить заведомо неправильные пароли, используя чужой логин. Или не кто-то, а скрипт. Или не логин, а логины. Получится DoS
Ну для этого и капча и ограничения per IP и все такое...
Re[7]: Разработчикам систем парольной аутентификации
Здравствуйте, kochetkov.vladimir, Вы писали:
A>>Ну если идентификатор чужой? KV>Если идентификатор чужой, то как он оказался у тебя?
Успешный XSS, например. Мало ли способов.
Вообще это распространенная проблема, когда удержание сессии возможно потенциально бесконечное — что ты ни делай, хоть пароль меняй, хоть пользователя блокируй.
Re[2]: Разработчикам систем парольной аутентификации
Здравствуйте, Anton Batenev, Вы писали:
AB>Здравствуйте, kochetkov.vladimir, Вы писали:
k>> P.S: Уважаемые разработчики, убедительно прошу вас рассмотреть мои просьбы и, по-возможности, следовать им. А то работы у меня совсем не останется
AB>OpenID?
Ну это не первая проблема с OpenID, но тут другое важно — те ребята, которые занимаются OpenID явно сделают аутентификацию более надежной, поскольку это их основная задача. Самописное решение будет проигрывать практически всегда.
Re[7]: Разработчикам систем парольной аутентификации
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, kochetkov.vladimir, Вы писали:
A>>>Ну если идентификатор чужой? KV>>Если идентификатор чужой, то как он оказался у тебя?
A>Троян, например.
А еще можно просто прийти к юзеру с паяльником и он тебе идентификатор сам из куки на лист бумаги выпишет только все эти потуги будут иметь смысл только в том случае, идентификатор криптостойкий. Если же нет, то его в разы проще предсказать, а трояны, xss и паяльник отложить за ненадобностью.
Ага. Но я, например, вообще переложил проверку подписи на OpenID провайдера — он прислал ответ, так пусть он же его и валидирует. Но жаль, что OpenID практически невозможно использовать вне веб (например, для авторизации svn).
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>2. Если вы все же решились на столь смелый поступок и таки планируете хранить в базе хэши паролей — забудьте о стандартных функциях хэширования! Вы вообще — программист или где? А известная только вам функция хэширования только добавит защищенности к вашей системе.
Ещё посолить неплохо бы.
Делай что должно, и будь что будет
Re[9]: Разработчикам систем парольной аутентификации
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>А еще можно просто прийти к юзеру с паяльником и он тебе идентификатор сам из куки на лист бумаги выпишет только все эти потуги будут иметь смысл только в том случае, идентификатор криптостойкий. Если же нет, то его в разы проще предсказать, а трояны, xss и паяльник отложить за ненадобностью.
Вот мне почему-то кажется, что такие рассуждения применимы лишь в двух случаях:
— в некотором идеальном сферическом мире победивших роботов, где стоимость физического криминала на несколько порядков выше информационного, который за счёт цивилизованных действий всех сторон превращается в некое интеллектуальное состязание;
— в случае миллионов вконтактовских хомячков, где реальный ущерб от действий злоумышленников для каждого конкретного хомячка минимален, и все действия окупаются только за счёт массовости.
В реальном мире терморектальный криптоанализ — значительно более действенное, а главное, значительно более дешёвое средство. Но на первом месте — административный метод, сводящий всю криптостойкость к нулю за счёт "добровольного" раскрытия контента. Про blackberry ты же нам тут и рассказывал.
Другой полуоффтопичный (но, мне кажется, имеющий прямое отношение к обсуждаемой теме) пример происходит сейчас в прямом эфире на roem.ru. Там разгорелся невиданный доселе огнесрач (отголоски которого можно наблюдать и здесь в разделах "о работе" и "предложения от прямых работодателей") нынешних и бывших сотрудников компании Infowatch (что это за компания, что они производят, думаю, объяснять тебе не надо — предполагается, что знания в технической, теоретической и правовой составляющих ИБ среднего сотрудника этой компании на порядок выше среднего по больнице). Как и на многих ресурсах, на роеме существует возможность писать сообщения анонимно, что многие и делают. Так вот, этот огнесрач очень быстро перешёл в стадию личных оскорблений. И вот в какой-то момент я вижу пост от одного из участников "дискуссии", активно защищающего руководство компании и являющегося сотрудником отдела внедрения компаннии (что-то средее между сейлзом и аналитиком), и (что очень важно) не являющегося сотрудником отдела внутренней ИБ:
2 Alter Ego Я отписался Вам на корпоративную почту. Жду Вас Только не нужно тут писать, что боитесь замараться. Вы это уже сделали 2 раза, теперь докажите, что не даром в штанах.
2 Саша которой удовлетворитель Честно удивлен, что это оказался именно ты
Т.е. внезапно он узнал личности собеседников. Вот интересный вопрос, как он смог это сделать. Ну да, вроде как они писали с рабочих компов, можно на шлюзе отследить все пакетики с dst=roem.ru && port=80. Но, ещё раз, это сотрудники компании, создающие решения для ИБ. Неужели они настолько тупы, чтобы писать гадости про руководство с рабочего компа, не шифруя траффик и т.д.? Разумеется, нет. Вряд ли даже, что они использовали внешние http/socks proxy. Как кто-то там предположил, у них, вероятно, поднят vpn до какого-то подконтрольного им сервера снаружи, откуда они и писали.
Как их можно вычислить? Ну, можно посмотреть всех, у кого наружу торчит поднятый vpn/ssh. Это значительно сузит круг подозреваемых, а потом пытаться анализировать содержимое записей, их стиль, соотносить число отправленных пакетов с временем постов и т.д. Вероятно, всё так и было. Но вот вопрос, как эта инфа попала к неавторизованному сотруднику. Я понял бы, если бы он был местным безопасником или админом шлюза. Но простой сейлз?! Вот представь, приходит к тебе кто-то и просит помочь вычислить коллегу, пишущего гадости на форуме — поможешь ему?
Это реалии нашей жизни.
Так что шифруй, не шифруй — всё равно получишь практически одно и то же.
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Re[8]: Разработчикам систем парольной аутентификации
Здравствуйте, DOOM, Вы писали:
DOO>Здравствуйте, kochetkov.vladimir, Вы писали:
A>>>Ну если идентификатор чужой? KV>>Если идентификатор чужой, то как он оказался у тебя?
DOO>Успешный XSS, например. Мало ли способов.
Так а зачем нам XSS, если в данном случае, мы может просто подбирать все (почти все) идентификаторы, которые будут выданы после нас?
Здравствуйте, frogkiller, Вы писали:
F>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>А еще можно просто прийти к юзеру с паяльником и он тебе идентификатор сам из куки на лист бумаги выпишет только все эти потуги будут иметь смысл только в том случае, идентификатор криптостойкий. Если же нет, то его в разы проще предсказать, а трояны, xss и паяльник отложить за ненадобностью. F>В реальном мире терморектальный криптоанализ — значительно более действенное, а главное, значительно более дешёвое средство.
С выделенным не согласен. Во-первых, оно требует наличия персональных данных атакующего. В общем случае, они тебе могут быть и неизвестны. Во-вторых, для того, чтобы воспользоваться этим средством, необходимо твое физическое присутствие рядом с атакуемым. Или не тебя. Но это уже куда дороже. В третьих, куда менее рискованно совершить преступление по 272ой или 273ей, находясь за сотни или тысячи километров от жертвы, нежели подписываться под вполне конкретные статьи УК, розыскная и судебная практика по которым значительно обширнее, чем по хайтековским статьям.
F>Другой полуоффтопичный (но, мне кажется, имеющий прямое отношение к обсуждаемой теме)
Обсуждаемая тема — парольная аутентификация, если что.
F>Т.е. внезапно он узнал личности собеседников.
Или сделал вид, что узнал, между прочим. Вообще, чтение той темы оставило на мой, дилетантский взгляд, ощущение значительного превосходства количества ников над количеством реально отписывающихся там людей.
F>Но вот вопрос, как эта инфа попала к неавторизованному сотруднику. Я понял бы, если бы он был местным безопасником или админом шлюза. Но простой сейлз?!
Даже если фишка с последующим разоблачением правда, то она могла попасть к нему кучей способов. Слишком мало информации, чтобы предметно фантазировать на эту тему
F>Вот представь, приходит к тебе кто-то и просит помочь вычислить коллегу, пишущего гадости на форуме — поможешь ему?
Нет конечно, по целому ряду причин. Но я — это я, а сотрудники ИВ — это сотрудники ИВ. Там может быть все, что угодно.
F>Так что шифруй, не шифруй — всё равно получишь практически одно и то же.
Отлаживай, не отлаживай — все равно каждый баг будет предпоследним
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>Я про то, возможна ли ситуация, когда при переносе твоей ИС на платформу со сторонней реализацией JDK, UUID'ы вдруг перестают быть рандомными?
A>Безумная мысль — GUID [частично] генерирует клиент. Ну или не GUID, а идентификатор вообще.
Я на выходных обычно впадаю в туплячку... А что это нам даст?
DOO>- код или пароль, предъявленный при неуспешной попытке;
Я писал все больше про успешные. А с отказами — тут палка о двух концах. С одной стороны — куда более качественная доказательная база из логов получается, случись вдруг что. С другой стороны, любой, кто имеет доступ к логам получит возможность существенно сузить количество перебираемых вариантов за счет анализа неуспешных попыток легальных пользователей. В принципе, можно шифровать все неправильные пароли ассиметрией, но это уже может вызвать вопросы у других умников
Здравствуйте, SergH, Вы писали:
SH>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>2. Если вы все же решились на столь смелый поступок и таки планируете хранить в базе хэши паролей — забудьте о стандартных функциях хэширования! Вы вообще — программист или где? А известная только вам функция хэширования только добавит защищенности к вашей системе.
SH>Ещё посолить неплохо бы.
Только не нужно тут писать, что боитесь замараться. Вы это уже сделали 2 раза, теперь докажите, что не даром в штанах.
Обсуждаемая тема — парольная аутентификация, если что.