Здравствуйте, frogkiller, Вы писали:
KV>>С выделенным не согласен. Во-первых, оно требует наличия персональных данных атакующего. В общем случае, они тебе могут быть и неизвестны.
F>Ты, вероятно, имел ввиду ПД атакуемого.
Да, конечно
F>Выше я приводил 2 случая применимости твоих рассуждений. Да, в случае "вконтактовского хомячка" персональные данные можно считать весьма условными, как и в случае с разными автоматическими вирусами/троянами, для которых раскрытие ПД жертвы — следствие их работы. Но, ещё раз, последствия таких атак для хомячка обычно очень небольшие.
KV>>Во-вторых, для того, чтобы воспользоваться этим средством, необходимо твое физическое присутствие рядом с атакуемым. Или не тебя. Но это уже куда дороже.
F>Э... не обязательно с атакуемым. Цепочка, по которой проходят запросы от жертвы до сервера, обычно достаточно длинная. В некоторых случаях это может снизить цену физического присутствия в несколько раз. F>И опять хочу подчеркнуть, что в основном рассматриваю существенные преступления — типа хищения миллиона баксов со счёта в банке,
Чуть выше, я привел ссылку, где описывается атака отнюдь не на хомячков и где наличия ПДн и дырки в парольной защите банка оказалось достаточно, чтобы успешно ее провести. Физического присутствия рядом с атакуемымии не потребовалось, что характерно. Не миллион баксов, конечно, но тем не менее. Впрочем, и миллионы тоже были (вспоминаем ситибанк и сколько из похищенного ему удалось вернуть).
Тех парней (поимевших Альфа-банк), кстати, так и не нашли, AFAIK. Но и их тела тоже, если что.
F>А так, ну подумаешь, уведут аську или отправят по контакт листу рекламу enlarge your penis. Ну даже если получат контроль над компом и превратят его в ноду ботнета. Делов-то
Либо разломают через него Альфа банк...
F>Насколько я знаю, "хайтековские статьи" не являются основными, а идут в довесок к тем самым вполне конкретным статьям УК.
Нет, это не так. Если совершается мошенничество с применением вредоносного ПО, то осуждают по 159-ой, а в довесок цепляют 273-ью. Если был осуществлен неправомерный доступ к информации через мошенничество, то осуждают по 272-ой, а в довесок идет 159-ая. Зависит только от того, на что был направлен умысел совершившего преступление.
F>Небольшая практика по ним, скорее, следствие низкой социальной опасности. (Я уверен, что если вдруг действия злоумышленников реально затронут интересы властей, то и розыскные и судебные мероприятия будут молниеносными)
Интересами властей в области хайтека у нас занимается ведомство, несколько отличающееся от БСТМ. Хотя бы тем, что у них аббревиатура чуть короче
F>Ну, во-первых, я указал на полуоффтопичность А. во-вторых, так я хотел продемонстрировать, как наличие административной составляющей сводит на нет все криптографические усилия.
Та тема вообще ничего не доказывает. Повторюсь, она может быть как целиком и полностью фантазией двух-трех человек, захотевшись развести черный пиар в адрес ИВ, так и частично, с той же целью Если же принимать на веру все, написанное там, то не "наличие административной составляющей", а ее отсутствие вообще-то. То, что у них имеют возможность получить доступ к таким данным все, кому не лень, говорило бы о крайне слабой административной составляющей их политики безопасности.
F>>>Но вот вопрос, как эта инфа попала к неавторизованному сотруднику. Я понял бы, если бы он был местным безопасником или админом шлюза. Но простой сейлз?! KV>>Даже если фишка с последующим разоблачением правда, то она могла попасть к нему кучей способов. Слишком мало информации, чтобы предметно фантазировать на эту тему
F>Вот у меня не получается придумать _хороших_ способов
Есть, например очень хороший способ, который называется "подглядеть-через-плечо-в-чужой-монитор"...
F>Тут очень тонкий момент, достойный отдельного обсуждения. С такой просьбой может прийти не простой сотрудник, а "большая шишка". И аргументация просьбы может быть очень разная, например, что в этих постах раскрыта важная информация, покрываемая NDA.
Большая шишка не может подойти ко мне с такой просьбой. Только мой непосредственный шеф (специфика управления ИБ в нашей конторе). Но извини, если ко мне подходит шеф, говорит, что была разглашена КИ и просит выдать ему перечень сотрудников, которые могли бы это сделать — то он вообще-то тем самым, просит выполнить меня мои прямые обязанности, если что
F>>>Так что шифруй, не шифруй — всё равно получишь практически одно и то же. KV>>Отлаживай, не отлаживай — все равно каждый баг будет предпоследним
F>Далеко не предпоследним это я тебе как разработчик говорю. Это, разумеется, не повод не отлаживаться. Но и впадать в паранойю тоже не стоит.
Хочешь сказать, что эти 15 пунктов (даже 14, т.к. один там просто про отношение к безопасникам) попахивают паранойей? И это при том, что еще про 12 я решил не писать?!
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, kochetkov.vladimir, Вы писали:
A>>>Безумная мысль — GUID [частично] генерирует клиент. Ну или не GUID, а идентификатор вообще. KV>>Я на выходных обычно впадаю в туплячку... А что это нам даст?
A>Даже при условии предсказуемости, теперь надо предсказать поведение сразу двух компьютеров в фиксированные моменты времени. Причём о клиентском информации нет.
Пока на всякий случай согласился, но еще подумаю над этим предметнее
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, DOOM, Вы писали:
DOO>>Дело в том, что целенаправленно блокировать аккаунты — это какое-то странное занятие. Профит где? KV>Это тот же DoS, вид с боку. Какой профит от DoS'а? Шантаж, борьба с конкурентами и т.п.
Это какой-то сложный DoS. Гораздо проще ломануться ботнетом на произвольную страничку ресруса и повалить его этим
Стоимость такого DDoS'а настолько смешна, что выдумывать что-то другое профита уж точно нет...
Re[3]: Разработчикам систем парольной аутентификации
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, ArhAngelVezel, Вы писали:
AAV>>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>>12. Двухфакторная аутентификация, с отправкой сессионного пароля в SMS-сообщении снимает ровным счетом все угрозы, связанные с несанкционированным доступом. Плюньте в глаз тому, кто будет утверждать обратное. Кстати, в этом случае, будет очень удобно использовать мобильный телефон пользователя для восстановления его основного пароля.
AAV>>2 раза перечитал, так и не понял. Чем вам OTP по SMS то не угодили?
KV>Сами по себе, сеансовые пароли есть гуд. Но ровно до тех пор, пока канал пересылки сеансового пароля не начинает пересекаться с каналом передачи основного пароля в процессе его восстановления или замены. Ибо в этом случае происходят вот такие вот конфузы: http://www.personalmoney.ru/txt.asp?sec=1525&id=1196427
Поясни, в чём тут "пересечение"?
Re[13]: Разработчикам систем парольной аутентификации
Здравствуйте, kochetkov.vladimir, Вы писали:
F>>А так, ну подумаешь, уведут аську или отправят по контакт листу рекламу enlarge your penis. Ну даже если получат контроль над компом и превратят его в ноду ботнета. Делов-то KV>Либо разломают через него Альфа банк...
Использовать для таких вещей ботнеты из позользовательских машин — довольно рискованное занятие, в любой момент может отключиться. Уж лучше через тот же gprs с телефона, зарегистриованного на какого-нибудь бомжа. И то, что через день место звонка будут обследовать куча людей с собаками — фигня, а быстрее с нуля без предварительной разработки вряд ли можно отреагировать, какие бы крутые спецслужбы не были.
KV>Та тема вообще ничего не доказывает. Повторюсь, она может быть как целиком и полностью фантазией двух-трех человек, захотевшись развести черный пиар в адрес ИВ, так и частично, с той же целью Если же принимать на веру все, написанное там, то не "наличие административной составляющей", а ее отсутствие вообще-то. То, что у них имеют возможность получить доступ к таким данным все, кому не лень, говорило бы о крайне слабой административной составляющей их политики безопасности.
Не-не-не. Административная составляющая в данном случае зло не потому, что плохо организована. А в силу самих предоставляемых возможностей. И я хотел показать, что это не обязательно исходит от государства (как в примере с blackberry), это может быть на всех уровнях.
Наличие возможности "специально обученным людям" иметь доступ к части системы в обход общей защиты автоматически означает, что на первое место выходит человеческий фактор, и, как следствие, основная угроза — в виде ли паяльника, неуставных отношений, подкупа или социальной инженерии — не важно, — идёт оттуда.
F>>Тут очень тонкий момент, достойный отдельного обсуждения. С такой просьбой может прийти не простой сотрудник, а "большая шишка". И аргументация просьбы может быть очень разная, например, что в этих постах раскрыта важная информация, покрываемая NDA. KV>Большая шишка не может подойти ко мне с такой просьбой. Только мой непосредственный шеф (специфика управления ИБ в нашей конторе).
Очень рад за вашу контору.
KV>Но извини, если ко мне подходит шеф, говорит, что была разглашена КИ и просит выдать ему перечень сотрудников, которые могли бы это сделать — то он вообще-то тем самым, просит выполнить меня мои прямые обязанности, если что
А с какой целью он их просит? Что если большая шишка пришёл к нему Да, я понимаю, что подобные вопросы лежат вне зоны твоей ответственности, но это не значит, что при этом нет никакой угрозы безопасности системы.
KV>Хочешь сказать, что эти 15 пунктов (даже 14, т.к. один там просто про отношение к безопасникам) попахивают паранойей? И это при том, что еще про 12 я решил не писать?!
Угу. Уровень технической безопасности, имхо, должне соотвтетствовать уровню человеческого фактора. Сначала людям нужно привить культуру обращения с информацией, причём всем людям, а не отдельным высокоморальным личностям, а потом только подгонять средства защиты. В противном случае никакого реального профита от крутой криптографии и сложных многоуровневых систем аутентификации не будет. А будет просто лишний геморрой разработчикам, которым в условиях жёстких проектных сроков придёт делать существенно больший объём работ — "для галочки".
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Re[5]: Разработчикам систем парольной аутентификации
Здравствуйте, Курилка, Вы писали:
KV>>Сами по себе, сеансовые пароли есть гуд. Но ровно до тех пор, пока канал пересылки сеансового пароля не начинает пересекаться с каналом передачи основного пароля в процессе его восстановления или замены. Ибо в этом случае происходят вот такие вот конфузы: http://www.personalmoney.ru/txt.asp?sec=1525&id=1196427
К>Поясни, в чём тут "пересечение"?
Основную вину за кражу денег потерпевшие возложили на банк. "Альфа-банк допустил халатность при разработке системы безопасности для удаленной работы со счетами. Ну как можно обеспечить сохранность наших средств, если банк высылает постоянный пароль и пароли на операции по счетам с помощью SMS", — возмущается Андрей.
Видимо, для работы нужно знать два пароля, один постоянный, второй получается через мобильник. Это типа "многфакторная аутентификация". Но из-за того, что через мобильник можно получить и постоянный пароль тоже, получается однофакторная, причём номер, как выясняется, можно неожиданно легко увести и тогда вся система ломается.
Делай что должно, и будь что будет
Re[5]: Разработчикам систем парольной аутентификации
Здравствуйте, SergH, Вы писали:
SH>Видимо, для работы нужно знать два пароля, один постоянный, второй получается через мобильник. Это типа "многфакторная аутентификация". Но из-за того, что через мобильник можно получить и постоянный пароль тоже, получается однофакторная, причём номер, как выясняется, можно неожиданно легко увести и тогда вся система ломается.
А, там ещё и основной можно (было) узнать разве? Это "весело", конечно...
Re[6]: Разработчикам систем парольной аутентификации
Здравствуйте, frogkiller, Вы писали:
F>Здравствуйте, kochetkov.vladimir, Вы писали:
F>>>А так, ну подумаешь, уведут аську или отправят по контакт листу рекламу enlarge your penis. Ну даже если получат контроль над компом и превратят его в ноду ботнета. Делов-то KV>>Либо разломают через него Альфа банк...
F>Использовать для таких вещей ботнеты из позользовательских машин — довольно рискованное занятие, в любой момент может отключиться.
Весь ботнет разом? И если таки-да, в чем риск-то?
F>Уж лучше через тот же gprs с телефона, зарегистриованного на какого-нибудь бомжа. И то, что через день место звонка будут обследовать куча людей с собаками — фигня, а быстрее с нуля без предварительной разработки вряд ли можно отреагировать, какие бы крутые спецслужбы не были.
Меня всегда улыбали подобные рассуждения, больше характерные для технарей. Ну переведешь ты со обчищаемого счета нужное тебе количество денежных средств (кстати, куда переведешь-то?). Выводить как будешь? А обналичивать? А тратить?
Я это к тому, что если на "разломают Альфа-банк" смотреть не как на "получат доступ к чужому счету, покрутятся и уйдут" (нафига оно кому-то нужно?), а как на "завладеют денежными средствами клиентов Альфа-банка", то резко появляется огромное количество мест, где могут остаться следы по которым тебя смогут взять за известное место.
F>Наличие возможности "специально обученным людям" иметь доступ к части системы в обход общей защиты автоматически означает, что на первое место выходит человеческий фактор,
Человеческий фактор всегда в топе, независимо от наличия или отсутствия каких-либо возможностей у специально обученных людей.
F> и, как следствие, основная угроза — в виде ли паяльника, неуставных отношений, подкупа или социальной инженерии — не важно, — идёт оттуда.
И?
KV>>Но извини, если ко мне подходит шеф, говорит, что была разглашена КИ и просит выдать ему перечень сотрудников, которые могли бы это сделать — то он вообще-то тем самым, просит выполнить меня мои прямые обязанности, если что
F>А с какой целью он их просит? Что если большая шишка пришёл к нему Да, я понимаю, что подобные вопросы лежат вне зоны твоей ответственности, но это не значит, что при этом нет никакой угрозы безопасности системы.
Что ты подразумеваешь под выделенным? Если кто-то из топов, хочет узнать о содержимом логов, хранящихся на серверах его компании, то никаких угроз безопасности для компании это не несет.
F>Уровень технической безопасности, имхо, должне соотвтетствовать уровню человеческого фактора. Сначала людям нужно привить культуру обращения с информацией, причём всем людям, а не отдельным высокоморальным личностям, а потом только подгонять средства защиты.
Я не совсем понимаю, о чем ты пытаешься спорить? Культуру безусловно прививать нужно, но разве это задача разработчиков систем? Думаю что нет. А вот приблизительный список того, что требуется от разработчиков (и только от них) я и озвучил
F>В противном случае никакого реального профита от крутой криптографии и сложных многоуровневых систем аутентификации не будет. А будет просто лишний геморрой разработчикам, которым в условиях жёстких проектных сроков придёт делать существенно больший объём работ — "для галочки".
"Каждый пользователь ИС должен быть успешно идентифицирован и аутентифицирован на основании введенного им пароля до разрешения любого действия в системе."
Знакомая строчка из ТЗ? Вот список из исходного сообщения и есть необходимый (но не всегда достаточный) перечень того, что нужно учесть при реализации процитированного требования. Невыполнение одного из этих 14 пунктов сведет на нет всю работу по реализации системы аутентификации по одной простой причине: в этом случае она (аутентификации) не будет успешной, что будет доказано на первом же тесте на проникновение. Вот и все, не более, но и не менее.
Здравствуйте, DOOM, Вы писали:
DOO>Гораздо проще ломануться ботнетом на произвольную страничку ресруса и повалить его этим DOO>Стоимость такого DDoS'а настолько смешна, что выдумывать что-то другое профита уж точно нет...
Если этой страничкой будет форма аутентификации, на которую ноды ботнета будут слать POST-запросы с левыми паролями, перебирая при этом все возможные логины, то ущерб от такой атаки будет на порядок существеннее из-за того, что помимо отказа в обслуживании на уровне канала передачи данных и/или сервера приложений, будет также иметь место отказ в обслуживании на уровне подсистемы аутентификации.
Здравствуйте, Курилка, Вы писали:
KV>>Сами по себе, сеансовые пароли есть гуд. Но ровно до тех пор, пока канал пересылки сеансового пароля не начинает пересекаться с каналом передачи основного пароля в процессе его восстановления или замены. Ибо в этом случае происходят вот такие вот конфузы: http://www.personalmoney.ru/txt.asp?sec=1525&id=1196427
К>Поясни, в чём тут "пересечение"?
Выше уже пояснили. Раньше (как сейчас — увы не знаю, давно свои пароли не забывал) когда клиент Альфа-банка забывал пароль на https://click.alfabank.ru, то его восстанавливали по звонку, отправкой нового пароля SMS'ом на телефон клиента. Т.е. тем же самым способом, что и сеансовый.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Собственно, просьбы:
Собственно из личного юзерского опыта — чем параноидальнее сайт, тем чаще пароли приходится записывать на бумажке и вешать на монитор
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Re[2]: Разработчикам систем парольной аутентификации
Здравствуйте, olegkr, Вы писали:
O>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>Собственно, просьбы: O>Собственно из личного юзерского опыта — чем параноидальнее сайт, тем чаще пароли приходится записывать на бумажке и вешать на монитор
"Параноидальнее" — не очень правильная оценка. Если сайт предоставляет пользователю какие-либо сервисы и при этом особо не обещает каких-либо мер, направленных на защиту пользовательского аккаунта, то излишнее закручивание гаек в плане требований к паролю там будет вряд ли уместно. Если пользователь захочет — он сам обеспечит себе определенную степень защиты, используя стойкий пароль. Если нет, то его можно предупредить об этом, но не более того.
Если же сайт берет на себя определенные обязательства, как в случае с Альфа-банком, либо безопасность сайта находится в некоторой зависимости от безопасности аккаунта пользователя (так тоже бывает), то и обязательные требования к паролям должны быть жестче, чтобы сайт имел возможность эти требования выполнить либо обеспечить свою безопасность.
Кроме того, я считаю, что проблема "пользователи не могут запоминать стойкие пароли" несколько надумана. Правильнее было бы говорить о проблеме "пользователи не хотят запоминать стойкие пароли". Пароль, который я использую на этом сайте выглядит примерно так: ~rM@0%s_jR4q| при этом он довольно стойкий (энтропия около 80 бит), учитывая его периодическую замену, т.к. безопасность моего аккаунта кореллирует с безопасностью всего сайта. Но на его запоминание у меня ушло от силы полчаса. Не думаю, что мои мнемонические навыки развиты как-то сильно особенно по сравнению со всеми остальными.
Для некоторых других сайтов и систем я использую менее стойкие, но легко запоминающиеся пароли, для некоторых (типа ибанкинга, админских аккаунтов на VDS и т.п.) — гораздо более сложнее приведенного. Но у меня ни разу не возникало проблем с их запоминанием, даже с учетом их регулярной замены в случае с некоторыми сайтами или системами
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>"Параноидальнее" — не очень правильная оценка. Если сайт предоставляет пользователю какие-либо сервисы и при этом особо не обещает каких-либо мер, направленных на защиту пользовательского аккаунта, то излишнее закручивание гаек в плане требований к паролю там будет вряд ли уместно. Если пользователь захочет — он сам обеспечит себе определенную степень защиты, используя стойкий пароль. Если нет, то его можно предупредить об этом, но не более того. KV>Если же сайт берет на себя определенные обязательства, как в случае с Альфа-банком, либо безопасность сайта находится в некоторой зависимости от безопасности аккаунта пользователя (так тоже бывает), то и обязательные требования к паролям должны быть жестче, чтобы сайт имел возможность эти требования выполнить либо обеспечить свою безопасность. KV>Кроме того, я считаю, что проблема "пользователи не могут запоминать стойкие пароли" несколько надумана. Правильнее было бы говорить о проблеме "пользователи не хотят запоминать стойкие пароли". Пароль, который я использую на этом сайте выглядит примерно так: ~rM@0%s_jR4q| при этом он довольно стойкий (энтропия около 80 бит), учитывая его периодическую замену, т.к. безопасность моего аккаунта кореллирует с безопасностью всего сайта. Но на его запоминание у меня ушло от силы полчаса. Не думаю, что мои мнемонические навыки развиты как-то сильно особенно по сравнению со всеми остальными. KV>Для некоторых других сайтов и систем я использую менее стойкие, но легко запоминающиеся пароли, для некоторых (типа ибанкинга, админских аккаунтов на VDS и т.п.) — гораздо более сложнее приведенного. Но у меня ни разу не возникало проблем с их запоминанием, даже с учетом их регулярной замены в случае с некоторыми сайтами или системами
А вот мой юзерский экспиренс несколько иной.
Возьмем интернет банки. Пару-тройку лет назад у меня была следующая ситуация: я держал свой основной счет в одном банке, а зарплатный проект у меня был в другом банке.
И тот и другой обладали интернет банками (кстати, оба неплохие, а во втором банке это был лучший в России интернет банк по версии какого-то там конкурса).
В общем на тот момент первый банк я использовал для выплаты ипотечного взноса. В общем-то только по той причине, что на нем я консолидировал основные средства, а на зарплатный счет тогда мне поступало недостаточно средств для выплаты взноса (шла только официальная часть з/п, которая у меня тогда была порядка половины от всей з/п).
И вот я пользовался интернет банком того первого банка ровно раз в месяц — для выплаты ипотечного взноса. При этом там система логин/пароль + одноразовые ключи. Пароль надо менять раз в 3 месяца. К паролю предъявляются определенные требования сложности (по-моему не менее 6-ти символов, обязательное наличие цифры или спецсимвола). Пароли не могут повторяться никогда.
Один раз это привело к тому, что я забыл пароль напрочь. Потому что это невозможно — использовать пароль 3 раза (причем с перерывом в месяц) а потом выдумать новый. Забыв пароль я добился своей блокировки в системе (сначала на 2 часа, потом на 4, а потом на какое-то нереальное время). Пошел в представительство, меня разблокировали — заплатил. Однако, это заставило меня сильно побегать (был риск просрочки ипотечного платежа).
Во втором же интернет банке все было проще — у меня была флешка с сертификатом, закрытым ключом (зашифрованным) + софтом для доступа к интернет банку (интер-про).
Никаких одноразовых ключей, постоянных смен пароля и т.п. При этом общая защищенность второй системы даже выше (кстати, сейчас тот первый банк купил интернет банк того второго банка, который был уничтожен альфой в конце 2008, которые оказались полными м..ками и выкинули на помойку продажу лучшие в России интернет и SMS банки. После покупки они доработали этот интернет банк и теперь там, вроде, можно использовать USB токены вместо флешек и, вроде бы, еще и с аппаратной реализацией гостового алгоритма — т.е. ключ носитель не покидает никогда).
Вывод: пароли вообще не стоит применять там, где нужна шибко непробиваемая защита. Есть много других методов аутентификации, которые уже давно стали более, чем доступны по цене (я уж молчу, что сертифицированный в ФСБ токен с родной криптографией удовлетворяет закону об ЭЦП, в отличие от).
Re[2]: Разработчикам систем парольной аутентификации
Здравствуйте, olegkr, Вы писали:
O>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>Собственно, просьбы: O>Собственно из личного юзерского опыта — чем параноидальнее сайт, тем чаще пароли приходится записывать на бумажке и вешать на монитор
Однажды Сисадмин пожаловался Учителю:
– Мы выдали всем нашим пользователям индивидуальные пароли, а они не желают хранить их в тайне. Записывают на листочках и приклеивают к мониторам. Что нам делать? Как заставить их?
Инь Фу Во спросил:
– Сначала скажи, почему они это делают.
Сисадмин подумал и ответил:
– Может быть, они не считают пароль ценным?
– А разве пароль сам по себе ценный?
– Не сам по себе. Ценна информация, которая под паролем.
– Для кого она ценна?
– Для нашего предприятия.
– А для пользователей?
– Для пользователей, видимо, нет.
– Так и есть, – сказал Учитель. – Под паролем нет ничего ценного для наших работников. Надо, чтоб было.
– Что для них ценно? – спросил Сисадмин.
– Догадайся с трёх раз, – рассмеялся Учитель.
Сисадмин ушёл просветлённый и сделал на корпоративном портале персональные странички для всех работников. И на тех страничках был указан размер зарплаты. Узнав об этом, все пользователи забеспокоились о своих паролях. На другой день в курилке обсуждали размер зарплаты Главбуха. На третий день ни у кого не было видно листочков с паролями.
Re[4]: Разработчикам систем парольной аутентификации
Здравствуйте, DOOM, Вы писали:
DOO>это невозможно — использовать пароль 3 раза (причем с перерывом в месяц) а потом выдумать новый.
Невозможно. Если только при конструировании пароля тобой не используется какая-нибудь функция, скажем от периода действия пароля. Ну например:
fG)4)5)6!0Pe+3 пароль на апрель, май и июнь
fG)7)8)9!0Pe+3 он же на июль, август и сентябрь
но все равно муторно, согласен. Фишка в том, что помнить целесообразно (и легко) только часто используемые пароли. Остальные — помнить не нужно, да и не очень реально.
DOO>кстати, сейчас тот первый банк купил интернет банк того второго банка, который был уничтожен альфой в конце 2008, которые оказались полными м..ками и выкинули на помойку продажу лучшие в России интернет и SMS банки. После покупки они доработали этот интернет банк и теперь там, вроде, можно использовать USB токены вместо флешек и, вроде бы, еще и с аппаратной реализацией гостового алгоритма — т.е. ключ носитель не покидает никогда).
Нифига не понял, кто кого купил и выкинул, но последнюю фразу одобряю
DOO>Вывод: пароли вообще не стоит применять там, где нужна шибко непробиваемая защита. Есть много других методов аутентификации, которые уже давно стали более, чем доступны по цене (я уж молчу, что сертифицированный в ФСБ токен с родной криптографией удовлетворяет закону об ЭЦП, в отличие от).
С одной только оговоркой, что для того, чтобы раздавать клиентам такие токены, нужно получить лицензию на эксплуатацию криптосредств, если что. А это (по личному опыту) далеко не всегда легко и дешево.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>С одной только оговоркой, что для того, чтобы раздавать клиентам такие токены, нужно получить лицензию на эксплуатацию криптосредств, если что.
Нет такой лицензии. Получать заставят лицензию на тех. обслуживание (хотя и тут есть способы отъехать). Не сказал бы, что это сложно.
KV>А это (по личному опыту) далеко не всегда легко и дешево.
Ну значит у вас УФСБ какое-то зверское. У нас это достаточно просто.
Re[6]: Разработчикам систем парольной аутентификации
Здравствуйте, DOOM, Вы писали:
DOO>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>С одной только оговоркой, что для того, чтобы раздавать клиентам такие токены, нужно получить лицензию на эксплуатацию криптосредств, если что. DOO>Нет такой лицензии. Получать заставят лицензию на тех. обслуживание (хотя и тут есть способы отъехать). Не сказал бы, что это сложно.
Я имел ввиду, пакет лицензий, связанных с эксплуатацией шифросредств, т.к. в описываемом тобой случае совершенно точно понадобятся лицензиии на:
а) распространение шифросредств (т.к. ключи будут являться неотъемлемой частью поставляемого продукта / сервиса);
б) их же техобслуживание (и как с этого съехать, учитывая что это в т.ч. "работы по обслуживанию шифровальных (криптографических) средств, предусмотренные технической и эксплуатационной документацией на эти средства" я хз. Допускаю, что можно, буду рад узнать как).
в) на предоставление услуг в области шифрования, в том случае, если ключи для клиентов будут генерироваться не поставщиком криптосредств, а в результате его эксплуатации сотрудниками компании.
KV>>А это (по личному опыту) далеко не всегда легко и дешево. DOO>Ну значит у вас УФСБ какое-то зверское. У нас это достаточно просто.
Если выполнены требования, предъявляемые к соискателю — у нас тоже. Если нет, то их выполнение может влететь в копеечку. Хотя, конечно, для компании уровня банка, она так копеечкой и останется.
А. во-вторых, так я хотел продемонстрировать, как наличие административной составляющей сводит на нет все криптографические усилия.
