WCH>Так пусть хоть он будет не столь тривиальным, не 'lenochka', а '#lenOchka720' — уже лучше, злоумышленника из числа хорошо знающих данного человека людей это может остановить.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Я повторю еще раз: существует стандарт, который предписывает всем банкам, обеспечивающим процессинг платежных карт, вводить меры по обеспечению безопасности, в т.ч. (я цитирую стандарт http://pcidss.ru/files/pub/pdf/pcidss_v2.0_russian.pdf): KV>
KV>8.5.9 Изменение пароля пользователя не реже одного раза в 90 дней.
Я честно говоря считаю такой пункт вредным. На основе наблюдений как поступают пользователи когда их принуждают часто менять пароль.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, mrTwister, Вы писали:
T>>А вот интересно, много ли есть людей, которие при принудительной смене пароля новый получают не из старого путем замены одного символа (password1, password2 и т.д.)? Защищенность очень сильно повысились, гемор пользователям добавили не зря!
KV>Есть системы, где подобные меры закрывают слишком мало рисков, чтобы их вводить (да вот, RSDN, например).
вообще с паролями ситуация интересная. длинный пароль, состоящий из комбинации букв и цифр -- хрен запомнишь, особенно если не пользуешься им постоянно. вот сейчас у меня возникла необходимость запонить опросник на одном из внутренних ресурсов нашей компании, который меня "проробатывал" года полтора тому назад. для входа нужен пароль. отсылка пароля на мыло не предусмотрена и для его сброса нужно писать прошение в саппорт. интересно, а есть тут на форуме люди, которые вспомнят пароль, который они использовали ровно один раз полтора года тому назад? (при условии, что пароль не записывали и что на разные ресурсы, а их больше десятка, разные пароли, т.к. у них разные требования к паролю и разные требования к смене пароля).
ЗЫ. последнее время я в 90% случаев при заходе на ресурс (которым не пользуюсь каждый день) просто тупо сбрасываю пароль, т.к. у меня голова не дом советов. а записывать пароли на папирусе это против правил
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Бред редкосный, такое действительно только в хумор.
Например, вместо того чтоб сделать нормальную защиту от брутфорса, иметь пользователям мозг со сложножностью пароля.
Re[2]: Разработчикам систем парольной аутентификации
КВ>Авторы: КВ> Кочетков Владимир
КВ>Аннотация: КВ>Советы разработчикам систем парольной аутентификации
Если никакой придурок не озадачил вас в ТЗ необходимостью реализации периодической принудительной смены пароля
А вот интересно, много ли есть людей, которие при принудительной смене пароля новый получают не из старого путем замены одного символа (password1, password2 и т.д.)? Защищенность очень сильно повысились, гемор пользователям добавили не зря!
лэт ми спик фром май харт
Re[14]: Разработчикам систем парольной аутентификации
Здравствуйте, Nik_1, Вы писали:
KV>>Вообще-то порядок у них разный, если что. N_>Поряд — это вообщето в 10 раз, так? для сведения или ты будешь утверждать что 1000/400 >= 10
Для сведения: порядок — это количество разрядов в числе.
Здравствуйте, Nik_1, Вы писали:
KV>>Для сведения: порядок — это количество разрядов в числе. N_>Тебя послушать, так 999999 и 1000000 тоже на порядок разлечуются
Первое — сотни тысяч, второе — миллионы. Порядок разный.
N_>Порядок, это какраз в 10 раз, а в твоем случаи 1000/400=2.5 называется "в разы"
Прости, но столь резкий переход от управления ИБ к курсу школьной арифметики, как-то обескураживает, что-ли
Здравствуйте, Nik_1, Вы писали:
N_>Здравствуйте, keenn, Вы писали:
D>>>Если честно, даже не припомню сайтов с требованием минимальной длины пароля более 8 символов. Не могли бы вы привести примеры таких сайтов?
K>>тут же вроде имеется в виду ограничение на максимальную длину N_>Темболее, ограничения сверху я еще реже встречал, чем ограничения снизу
С года полтора назад регистрировался на world community grid, сразу же после регистрации пришлось восстанавливать пароль — не удавалось войти. При восстановлении прислали изначально введенный пароль, но — сюрприз! — обрезанный до какой-то там длины.
Re[2]: Разработчикам систем парольной аутентификации
Здравствуйте, Nik_1, Вы писали:
N_>Бред редкосный, такое действительно только в хумор.
Я тебя тоже искренне рад видеть
N_>Например, вместо того чтоб сделать нормальную защиту от брутфорса, иметь пользователям мозг со сложножностью пароля.
В чем должна заключаться такая защита? Чем она поможет пользователям в случае компрометации сервера, когда у атакующего на руках будут и хэши пароль и значение, используемое в качестве соли?
N_>Бред редкосный, такое действительно только в хумор. N_>Например, вместо того чтоб сделать нормальную защиту от брутфорса, иметь пользователям мозг со сложножностью пароля.
Помимо защиты от брутфорса подумайте вот о чем: вы же не можете запретить глупому (считаем по умолчанию) юзеру использовать имя своей кошечки-собачки-любимой девушки-мальчика в качестве пароля. А ведь будут ставить. Так пусть хоть он будет не столь тривиальным, не 'lenochka', а '#lenOchka720' — уже лучше, злоумышленника из числа хорошо знающих данного человека людей это может остановить.
Re[6]: Разработчикам систем парольной аутентификации
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>Я повторю еще раз: существует стандарт, который предписывает всем банкам, обеспечивающим процессинг платежных карт, вводить меры по обеспечению безопасности, в т.ч. (я цитирую стандарт http://pcidss.ru/files/pub/pdf/pcidss_v2.0_russian.pdf):
T>Я спрашивал не с точки зрения стандартов, а с точки зрения здравого смысла. А стандарты могут быть любыми.
С т.з. здравого смысла, чтобы эта процедура действительно работала, нужно идти до конца и генерировать случайные пароли пользователю без его участия при каждом истечении срока жизни пароля. Процедура смены пароля должна быть реализована точно также.
В любом другом случае, периодическая смена паролей зависима от человеческого фактора и, со стороны владельца системы, является скорее механизмом передачи ответственности на сторону пользователя и, возможно, выполнением требований обязательного стандарта, не более того.
Здравствуйте, Nik_1, Вы писали:
KV>>Я это говорил к тому, что легко давать советы, не находясь внутри всего этого, не зная всей "кухни" и даже десятой части тех критериев, на основе которых принимается то или иное решение в рамках выработки контрмер. N_>Т.е. проще говоря приминил стандартный прием демагога "сначало добейся".
Если бы я его применил, то кроме той фразы больше бы ничего не написал. Тут дело не в добейся, а в том, что профессионал в одной области, рассказывающий профессионалу в другой области, как ему работать и чем заниматься — выглядит, по меньшей мере, странно.
Здравствуйте, Nik_1, Вы писали:
N_>прогрессивным увелечением времени на повторную попытку, например : 10с, 20с,30с, 1м, 5м, 15м, ... Вслучаи, если речь идет о доступе к деньгам то допустимо будет вообще на день блокировать при 5 неправильных попытках ввода.
Отлично. Я, являсь атакующим, генерирую десятки-сотни неправильных попыток в секунду в отношении всех пользователей интернет-банка, используя для этого распределенный ботнет, чем всерьез и надолго парализую возможность нормальной работы настоящих клиентов. Что дальше?
Здравствуйте, mrTwister, Вы писали:
T>А вот интересно, много ли есть людей, которие при принудительной смене пароля новый получают не из старого путем замены одного символа (password1, password2 и т.д.)? Защищенность очень сильно повысились, гемор пользователям добавили не зря!
На одной из прошлых работе и это (смена одного символа) тоже проверялось, приходилось раз в три месяца переключаться между двумя паролями туда-обратно.
Re[19]: Разработчикам систем парольной аутентификации
С тобой можно будет продолжить дескутировать лишь после того, как разберешся с базовыми понятиями из школьной математики. Такими как "отличается в разы" и "отличается на порядок".
Re[20]: Разработчикам систем парольной аутентификации
Здравствуйте, Nik_1, Вы писали:
N_>С тобой можно будет продолжить дескутировать лишь после того, как разберешся с базовыми понятиями из школьной математики. Такими как "отличается в разы" и "отличается на порядок".
Во-первых, капчи ломаются и любая капча на сегодняшний день ничуть не лучше "своего" алгоритма хеширования. Уж сколько Гугл не вкладывался в свою капчу, а и её сломали. Да и кучи дешёвых китайских рукоглаз никуда не исчезли.
Во-вторых, капча — суть оскорбление пользователя, презумпция виновности. Ты, скорее всего, робот, но, может быть, человек. А должно быть наоборот — ты, скорее всего, человек, но может быть робот. И даже какая-то польза человечеству от ReCaptcha никак не отправдывает ту настойчивость с которой капчи вставляют. Это не очень-то и сложно, начать показывать капчу не сразу при логине, а после например, неудачной попытки авторизации, но так сложно отказать себе в удовольствии крикнуть всему миру "Hello World Я знаю что такое капча!".
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, Nik_1, Вы писали:
N_>>Здравствуйте, kochetkov.vladimir, Вы писали: N_>>>>а не над пользователями измываться заставляя их каждый месяц зазубривать очередные '#lenOchka720'.
KV>>>Приходи к нам в отрасль — покажешь, как надо N_>>Да мне как-то и в моей неплохо платят Уверен что сможете заинтересвать чтоб туда перебрался?
KV>Я это говорил к тому, что легко давать советы, не находясь внутри всего этого, не зная всей "кухни" и даже десятой части тех критериев, на основе которых принимается то или иное решение в рамках выработки контрмер.
Т.е. проще говоря приминил стандартный прием демагога "сначало добейся".
Re[6]: Разработчикам систем парольной аутентификации
Здравствуйте, Nik_1, Вы писали:
N_>С учетом того что не все хранят кешь вместо открытого пароля, то какой хитровывернутый пароль не придумай — всеравно свиснут.
Вообще говоря, существуют реализации хэширования паролей, устойчивые к краже базы с сервера. Например Lamport hash chain. Другой вопрос, что если сервер взломали и смогли слить базу, то, вполне вероятно, смогут и записать в базу сервера для интересующего пользователя свои значения, чтобы пройти авторизацию, т.е. попросту сбросить пароль на известный.
Здравствуйте, Working Class Hero, Вы писали:
WCH>А если квалифицированный хакер сможет действовать непосредственно на сервере и обойти участок кода, отвечающий за задержку? Это же возможно.
Можно (и нужно) сделать так, чтобы это было в принципе невозможно.
Требование слишком длинного пароля крайне неудобно для пользователей и вполне может снижать безопасность системы (будут записывать где ни попадя)
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, Nik_1, Вы писали:
N_>>Здравствуйте, kochetkov.vladimir, Вы писали: KV>>>В чем должна заключаться такая защита? Чем она поможет пользователям в случае компрометации сервера, когда у атакующего на руках будут и хэши пароль и значение, используемое в качестве соли? N_>>И каким образом требование хитровывернутых паролей типа '#lenOchka720' спасет от этого ??
KV>Я предлагаю не верить мне на слово, а взять любой md5 крэкер и самостоятельно проверить, сколько времени займет получения пароля lenochka из 4855d3ec96264f93ef6eb61c09a3c14b и #lenOchka720 из f20025e85f38e95e091069ed327f454e, если учитывать, что для получения этих хешей использовалась соль kochetkov.vladimir, добавленная к концу каждого из паролей.
С учетом того что не все хранят кешь вместо открытого пароля, то какой хитровывернутый пароль не придумай — всеравно свиснут.
Re[2]: Разработчикам систем парольной аутентификации
Здравствуйте, mrTwister, Вы писали:
T>А вот интересно, много ли есть людей, которие при принудительной смене пароля новый получают не из старого путем замены одного символа (password1, password2 и т.д.)? Защищенность очень сильно повысились, гемор пользователям добавили не зря!
Есть системы, где подобные меры закрывают слишком мало рисков, чтобы их вводить (да вот, RSDN, например). Есть системы, где их владельцы несут перед пользователями некоторую ответственность, например банки. И банки обязаны вводить подобные меры, как из соображений здравого смысла, так и в соответствии с требованиями стандартнов (PCIDSS, к примеру, если речь идет о процессинге платежных карт). И если пользователь изменяет лишь один символ, хотя его предупреждают о том, что пароль должен быть не похож на предыдущие, то он ССЗБ и банк ответственности за его действия в части, касающейся нарушения конфиденциальности его пароля, нести уже не должен.
Здравствуйте, Nik_1, Вы писали:
N_>С учетом того что не все хранят кешь вместо открытого пароля, то какой хитровывернутый пароль не придумай — всеравно свиснут.
ЛОЛ. Простите. Первый пункт статьи как раз говорит о том, что делать так не надо
Re[3]: Разработчикам систем парольной аутентификации
Здравствуйте, kochetkov.vladimir, Вы писали: KV>Есть системы, где подобные меры закрывают слишком мало рисков, чтобы их вводить (да вот, RSDN, например). Есть системы, где их владельцы несут перед пользователями некоторую ответственность, например банки. И банки обязаны вводить подобные меры, как из соображений здравого смысла, так и в соответствии с требованиями стандартнов (PCIDSS, к примеру, если речь идет о процессинге платежных карт). И если пользователь изменяет лишь один символ, хотя его предупреждают о том, что пароль должен быть не похож на предыдущие, то он ССЗБ
ССЗБ здесь какраз таки банк, потому что ни один нормальный человек каждый месяц зазубривать очередную хню типа Luz1XSQc0s небудет, а буджет их записывать KV>и банк ответственности за его действия в части, касающейся нарушения конфиденциальности его пароля, нести уже не должен.
Ага, у банка слямзили базу паролей с серверов, а он ответственность нести не должен лол!
Re[5]: Разработчикам систем парольной аутентификации
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, Nik_1, Вы писали:
N_>>ССЗБ здесь какраз таки банк, потому что ни один нормальный человек каждый месяц зазубривать очередную хню типа Luz1XSQc0s небудет, а буджет их записывать
KV>Я повторю еще раз: существует стандарт, который предписывает всем банкам, обеспечивающим процессинг платежных карт, вводить меры по обеспечению безопасности, в т.ч. (я цитирую стандарт http://pcidss.ru/files/pub/pdf/pcidss_v2.0_russian.pdf):
KV>
KV>8.5.9 Изменение пароля пользователя не реже одного раза в 90 дней.
Тебя удевляет что среди чиновников встречаются тупые, которые принимают тупые законы? Ну ты прям как не в России живешь KV>>>и банк ответственности за его действия в части, касающейся нарушения конфиденциальности его пароля, нести уже не должен. N_>>Ага, у банка слямзили базу паролей с серверов, а он ответственность нести не должен лол!
KV>Откуда взялось выделенное допущение?
Ты сам рассматриваешь случай когда у сервиса базу слямзили
Re[3]: Разработчикам систем парольной аутентификации
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, mrTwister, Вы писали:
T>>А вот интересно, много ли есть людей, которие при принудительной смене пароля новый получают не из старого путем замены одного символа (password1, password2 и т.д.)? Защищенность очень сильно повысились, гемор пользователям добавили не зря!
KV>Есть системы, где подобные меры закрывают слишком мало рисков, чтобы их вводить (да вот, RSDN, например). Есть системы, где их владельцы несут перед пользователями некоторую ответственность, например банки. И банки обязаны вводить подобные меры, как из соображений здравого смысла, так и в соответствии с требованиями стандартнов (PCIDSS, к примеру, если речь идет о процессинге платежных карт). И если пользователь изменяет лишь один символ, хотя его предупреждают о том, что пароль должен быть не похож на предыдущие, то он ССЗБ и банк ответственности за его действия в части, касающейся нарушения конфиденциальности его пароля, нести уже не должен.
То есть ССЗБ ка к был без принудительной смены пароля, так и с ней остался. И чем принудительность от ССЗБ спасает? Буратин столько же, но теперь с геморроем.
лэт ми спик фром май харт
Re[5]: Разработчикам систем парольной аутентификации
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Я повторю еще раз: существует стандарт, который предписывает всем банкам, обеспечивающим процессинг платежных карт, вводить меры по обеспечению безопасности, в т.ч. (я цитирую стандарт http://pcidss.ru/files/pub/pdf/pcidss_v2.0_russian.pdf):
Я спрашивал не с точки зрения стандартов, а с точки зрения здравого смысла. А стандарты могут быть любыми.
лэт ми спик фром май харт
Re[4]: Разработчикам систем парольной аутентификации
Здравствуйте, Nik_1, Вы писали:
N_>Здравствуйте, kochetkov.vladimir, Вы писали: N_>>>а не над пользователями измываться заставляя их каждый месяц зазубривать очередные '#lenOchka720'.
KV>>Приходи к нам в отрасль — покажешь, как надо N_>Да мне как-то и в моей неплохо платят Уверен что сможете заинтересвать чтоб туда перебрался?
Я это говорил к тому, что легко давать советы, не находясь внутри всего этого, не зная всей "кухни" и даже десятой части тех критериев, на основе которых принимается то или иное решение в рамках выработки контрмер.
N_>Точно так же можно сказать : админы сервиса всегда является слабым звеном,
Админы сервиса тоже его пользователи, только с расширенными правами и...
N_>хотя бы потому что он неконтролируем пользователем системы, а его поведение недетерминировано и не может быть сформулировано сколь-нибудь формально.
... частично контролируемые владельцем системы за счет принятия на себя письменных обязательств в рамках трудового договора, более жесткого регламетирования их деятельности (в т.ч. техническими мерами), грамотного разделения их полномочий и контроля в т.ч. за соблюдением ими парольных политик.
N_>>>Если нормально защищать свои сервера от взлома и брутфорса, то даже примитивный пароль "lenochka" фиг сломаешь. KV>>Мне хотелось услышать хоть какие-то аргументы в пользу этого утверждения. N_>При атаке по словарю для подобного пароля будет использоваться словарь где-нить на миллион вариантов,
скажи, а вот про миллион, ты сделал вывод на основании каких-то аргументов или так, с потолка взял? Например, в словаре паролей от Грея (http://letitbit.net/download/1525508/33428.316e864f00e53485996577047a85/dic-from-Grey.txt.html
) на 429439 слов, этот пароль находится на 189261 строке
N_>а при наличии в сервисе защиты от брутфорса наврятли злоумышленнику удастся сделать столько попыток.
Как уже сказали, ему вполне может быть известна информация о владельце, которая позволит сделать допущение, что этот пароль нужно попробовать одним из первых. И социальная инженерия тут не всегда нужна, пользователя могут банально звать Леной и это вполне может быть общедоступная информация.
Здравствуйте, Working Class Hero, Вы писали:
WCH>Здравствуйте, Nik_1, Вы писали:
WCH>>>Ну, влезть в квартиру с целью украсть бумажку с паролем — дело несколько более хлопотное, шумное и грязное (в прямом смысле этого слова), чем угадать пароль, имея некоторые вводные данные. N_>>Зачем влезать Ты ж сам пишешь что хорошо знает человека, и тогда вполне вероятно временами бывает унего дома.
WCH>Хорошо знает != знает, где лежит бумажка.
Хорошо знает != знает какой пароль поставил.
Re[4]: Разработчикам систем парольной аутентификации
Здравствуйте, мыщъх, Вы писали:
М>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>Здравствуйте, mrTwister, Вы писали:
T>>>А вот интересно, много ли есть людей, которие при принудительной смене пароля новый получают не из старого путем замены одного символа (password1, password2 и т.д.)? Защищенность очень сильно повысились, гемор пользователям добавили не зря!
KV>>Есть системы, где подобные меры закрывают слишком мало рисков, чтобы их вводить (да вот, RSDN, например).
М>вообще с паролями ситуация интересная. длинный пароль, состоящий из комбинации букв и цифр -- хрен запомнишь, особенно если не пользуешься им постоянно. вот сейчас у меня возникла необходимость запонить опросник на одном из внутренних ресурсов нашей компании, который меня "проробатывал" года полтора тому назад. для входа нужен пароль. отсылка пароля на мыло не предусмотрена и для его сброса нужно писать прошение в саппорт. интересно, а есть тут на форуме люди, которые вспомнят пароль, который они использовали ровно один раз полтора года тому назад? (при условии, что пароль не записывали и что на разные ресурсы, а их больше десятка, разные пароли, т.к. у них разные требования к паролю и разные требования к смене пароля).
М>ЗЫ. последнее время я в 90% случаев при заходе на ресурс (которым не пользуюсь каждый день) просто тупо сбрасываю пароль, т.к. у меня голова не дом советов. а записывать пароли на папирусе это против правил
Тоже не запомню. Но обязательно занесу новый пароль в базу Password Commander (или KeePass, если пароль рабочий), ибо! А мастер-пароли от баз я не забываю.
ORIGIN:Плохо знать много шуток: когда надо — не вспомнишь, а когда кто-то рассказывает — не смешно
Re[13]: Разработчикам систем парольной аутентификации
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, Nik_1, Вы писали:
WCH>>>А если злоумышленники знают жертву и ее привычки, то начнут с перебора самых простых вариантов и где-нибудь на 3-й попытке откроют аккаунт паролем, совпадающим с именем любимой девушки N_>>От социального инжиниринга требование каждый месяц запоминать новый пароль вида Luz1XSQc0s неспасет, ибо он будет записываться где-нибуть, а не запоминаться.
KV>Тебе дать базу keepassx с записанными в ней паролями?
Мы тут вроде блондинку обсуждаем, поставившую простой пароль, а не продвинутого пользователя, использующего keepassx Что ты сам там выше по треду говорил про типичного пользователя? Иль когда тебе выгодно, он сразу становится "нетипичным" и весьма продвинутым Толсто...
Re[2]: Разработчикам систем парольной аутентификации
Здравствуйте, mrTwister, Вы писали:
T>А вот интересно, много ли есть людей, которие при принудительной смене пароля новый получают не из старого путем замены одного символа (password1, password2 и т.д.)? Защищенность очень сильно повысились, гемор пользователям добавили не зря!
Исчезающе мало ИМХО.
Такая система лишь провоцирует на создание простого пароля с инкрементом.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[9]: Разработчикам систем парольной аутентификации
Здравствуйте, kochetkov.vladimir, Вы писали: KV>1. ограничения времени, доступного атакующему, владеющему какой-либо информацией, которая может способствовать воссозданию или подбору пароля.
Для этого есть более действенные способы : временные лимиты на попытки при подборе пароля. KV>2. ограничения времени, в течении которого атакующий может использовать скомпрометированный пароль.
Если пароль скопроментирован, то чтоб все деньги свиснуть надо менее 90 дней, так что опять мимо
N_>> и делать его вида Luz1XSQc0s? KV>это требование вводится для того, чтобы увеличить время, необходимое атакующему для компрометации пароля и сделать его заведомо большим, чем доступное ему, с учетом ограничений, упомянутых выше.
Затыкание одно дыры путем создания другой, офигеть хорошее решение. Когда дыру можно было заткнуть другими методами, не создающими дополнительной уязвимости.
Не удивлюсь, если привиденный тобой стандарт писали такие же "специалисты", а ты теперь на него как на мега авторитетный и неоспоримый источник ссылаешься
Re[7]: Разработчикам систем парольной аутентификации
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, mrTwister, Вы писали:
T>>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>>Я повторю еще раз: существует стандарт, который предписывает всем банкам, обеспечивающим процессинг платежных карт, вводить меры по обеспечению безопасности, в т.ч. (я цитирую стандарт http://pcidss.ru/files/pub/pdf/pcidss_v2.0_russian.pdf):
T>>Я спрашивал не с точки зрения стандартов, а с точки зрения здравого смысла. А стандарты могут быть любыми.
KV>С т.з. здравого смысла, чтобы эта процедура действительно работала, нужно идти до конца и генерировать случайные пароли пользователю без его участия при каждом истечении срока жизни пароля. Процедура смены пароля должна быть реализована точно также.
KV>В любом другом случае, периодическая смена паролей зависима от человеческого фактора и, со стороны владельца системы, является скорее механизмом передачи ответственности на сторону пользователя
Втом то и дело, что это лишь перекладывание с больной головы на здоровую, а не повышение защищенности системы
Re[19]: Разработчикам систем парольной аутентификации
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, Nik_1, Вы писали:
KV>>>Честно говоря, я устал спорить с необоснованными заявлениями. Приведи статистические данные, подтверждающие выделенное утверждение. N_>>Большинство компроментаций пароля к картам происходит скраммерами. Или по твоему пользователь виноват что банк не следит за своими банкоматами и позволяет скраммерам ставить на них считывающие устройства?
KV>К пин-кодам карт не выставляются требования, которые мы здесь обсуждаем. В чем смысл их упоминания здесь?
А про какие пароли у банков мы говорим? Я чет сходу не припомню других.
Re[23]: Разработчикам систем парольной аутентификации
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, Nik_1, Вы писали:
KV>>>Например, которые нужно вводить тут: https://click.alfabank.ru или тут: https://connect.raiffeisen.ru/rba/Login.do N_>>Вроде подобные системы используют не пароль, а ssl сертификат, который в отделении банка пользователю генерят и выдают на флешке.
KV>Обе приведенные системы используют парольную аутентификацию. Это я тебе, как их клиент говорю. Альфа-банк при этом использует еще и мультифакторную аутентификацию на основе не только постоянного, но и одноразовых паролей, присылаемых по SMS на каждую вновь создаваемую сессию.
Не знаю как в альфе, но в райфайзине по паролю можно тока статистику по счету смотреть и прочие мелкие неопасные операции. А для совершения платежей со счета кудато насторону нужен сертификат
N_>>Бред редкосный, такое действительно только в хумор. N_>>Например, вместо того чтоб сделать нормальную защиту от брутфорса, иметь пользователям мозг со сложножностью пароля.
WCH>Помимо защиты от брутфорса подумайте вот о чем: вы же не можете запретить глупому (считаем по умолчанию) юзеру использовать имя своей кошечки-собачки-любимой девушки-мальчика в качестве пароля. А ведь будут ставить. Так пусть хоть он будет не столь тривиальным, не 'lenochka', а '#lenOchka720' — уже лучше, злоумышленника из числа хорошо знающих данного человека людей это может остановить.
А почему из-за пары дураков нормальные пользователи должны страдать? Да и никто не мешает поставить проверку по словарю популярных паролей( который при подборах используют). При этом не ограничивая сложность в виде подобных извращений : '#lenOchka720'. Потому что такой пароль большинство не запомнят, а потому будут записывать, что снижает защищенность.
Да и зачем требовать 20 символов, когда 8 символов если поставить задержку между попытками хотябы минуту за всю жизнь не подберут(даже если там будут только латинские символы в одном регистре).
Re[4]: Разработчикам систем парольной аутентификации
Здравствуйте, Nik_1, Вы писали:
N_>А почему из-за пары дураков нормальные пользователи должны страдать? Да и никто не мешает поставить проверку по словарю популярных паролей( который при подборах используют). При этом не ограничивая сложность в виде подобных извращений : '#lenOchka720'. Потому что такой пароль большинство не запомнят, а потому будут записывать, что снижает защищенность.
Ну конечно, палка о двух концах. Ну сами себе злобные Буратины, если записывают, что поделаешь.
N_>Да и зачем требовать 20 символов, когда 8 символов если поставить задержку между попытками хотябы минуту за всю жизнь не подберут(даже если там будут только латинские символы в одном регистре).
А если квалифицированный хакер сможет действовать непосредственно на сервере и обойти участок кода, отвечающий за задержку? Это же возможно. И сразу же ставим под удар данные пользователей. Кстати, не забывайте про недобросовестных инсайдеров — им ваша схема сильно облегчит задачу. А ведь защита должна предусматривать и такой сценарий.
Ну и плюс задержка — банально снижение юзабилити.
Re[5]: Разработчикам систем парольной аутентификации
Здравствуйте, Working Class Hero, Вы писали:
WCH>А если квалифицированный хакер сможет действовать непосредственно на сервере и обойти участок кода, отвечающий за задержку? Это же возможно. И сразу же ставим под удар данные пользователей. Кстати, не забывайте про недобросовестных инсайдеров — им ваша схема сильно облегчит задачу. А ведь защита должна предусматривать и такой сценарий.
Если у кого-то есть доступ к серверу, то итак уже есть доступ к пользовательским данным. Никтобольшинство сервисов их не шифрует, так что если есть доступ к базам, то и ко всем данным. WCH>Ну и плюс задержка — банально снижение юзабилити.
Для пользователя знающего пароль никакой задержки не будет. А если уж, например, умудрился 10 раз подряд неправильно ввести пароль, то ничего страшного что подождет минуту до следующей попытки.
Разумеется, ваши сервера не халявная рапидшара и нечего позволять пользователям засорять место на жестких дисках своими ублюдскими 20-символьными паролями. 8 символов хватит всем! Это в конце 90-ых всем доступно объяснил Microsoft, если кто не помнит.
Если честно, даже не припомню сайтов с требованием минимальной длины пароля более 8 символов. Не могли бы вы привести примеры таких сайтов?
Re[2]: Разработчикам систем парольной аутентификации
Здравствуйте, keenn, Вы писали:
D>>Если честно, даже не припомню сайтов с требованием минимальной длины пароля более 8 символов. Не могли бы вы привести примеры таких сайтов?
K>тут же вроде имеется в виду ограничение на максимальную длину
Темболее, ограничения сверху я еще реже встречал, чем ограничения снизу
Re[4]: Разработчикам систем парольной аутентификации
Здравствуйте, Nik_1, Вы писали:
N_>А почему из-за пары дураков нормальные пользователи должны страдать?
Ты оцениваешь пользовательскую массу, исходя из того, что считаешь себя попадающим по критерии среднестатистического пользователя. Можешь взять любую из утекших в этом году баз пользовательских данных и убедиться в том, что тут речь идет "паре умных" и всех остальных, а не наоборот.
Здравствуйте, Domanser, Вы писали:
D>Если честно, даже не припомню сайтов с требованием минимальной длины пароля более 8 символов. Не могли бы вы привести примеры таких сайтов?
Речь шла об ограничении максимальной длины. Около года назад, когда я писал исходный пост, примерами были сервис заказа билетов РЖД и интернет-банк Альфа-банка, хотя бы. И помимо ограничения длины пароля сверху там было еще и ограничение на используемый алфавит (нельзя было использовать символы, только буквы в обоих регистрах и цифры).
Здравствуйте, keenn, Вы писали:
КВ>>Советы разработчикам систем парольной аутентификации
K>кстати по поводу гуидов как сессионных ключей, чем они особо плохи кроме вероятности вычислять след значение?
Ну, например, у нас, этого в общем-то достаточно, чтобы приложение не было принято в продакшн Криптографическая нестойкость GUID — их единственный недостаток (AFAIK), для использования в качестве ключей сессий. Но он легко устраняется, достаточно подсунуть в конструктор Guid'а в качестве seed'а годную псевдослучайную последовательность, сгенеренную например RNGCryptoServiceProvider'ом.
KV>Ну, например, у нас, этого в общем-то достаточно, чтобы приложение не было принято в продакшн
сие понятно, не в этом вопрос
KV>Криптографическая нестойкость GUID — их единственный недостаток (AFAIK), для использования в качестве ключей сессий. Но он легко устраняется, достаточно подсунуть в конструктор Guid'а в качестве seed'а годную псевдослучайную последовательность, сгенеренную например RNGCryptoServiceProvider'ом.
мы говорим только о винде?
но в целом то ясно, вообщем других недостатков нет. я просто хотел еще узнать, есть ли еще что нибудь.
Re[3]: Разработчикам систем парольной аутентификации
Здравствуйте, kochetkov.vladimir, Вы писали: KV>В чем должна заключаться такая защита? Чем она поможет пользователям в случае компрометации сервера, когда у атакующего на руках будут и хэши пароль и значение, используемое в качестве соли?
И каким образом требование хитровывернутых паролей типа '#lenOchka720' спасет от этого ??
Re[5]: Разработчикам систем парольной аутентификации
Здравствуйте, Michael Chelnokov, Вы писали:
MC>Здравствуйте, Nik_1, Вы писали:
N_>>Темболее, ограничения сверху я еще реже встречал, чем ограничения снизу
MC>Одноклассники, например. Может уже изменили, но раньше долго было ограничение.
на 8 символов?
Re[4]: Разработчикам систем парольной аутентификации
Здравствуйте, Nik_1, Вы писали:
N_>Здравствуйте, kochetkov.vladimir, Вы писали: KV>>В чем должна заключаться такая защита? Чем она поможет пользователям в случае компрометации сервера, когда у атакующего на руках будут и хэши пароль и значение, используемое в качестве соли? N_>И каким образом требование хитровывернутых паролей типа '#lenOchka720' спасет от этого ??
Я предлагаю не верить мне на слово, а взять любой md5 крэкер и самостоятельно проверить, сколько времени займет получения пароля lenochka из 4855d3ec96264f93ef6eb61c09a3c14b и #lenOchka720 из f20025e85f38e95e091069ed327f454e, если учитывать, что для получения этих хешей использовалась соль kochetkov.vladimir, добавленная к концу каждого из паролей.
Здравствуйте, Working Class Hero, Вы писали:
WCH>Здравствуйте, Nik_1, Вы писали:
N_>>С учетом того что не все хранят кешь вместо открытого пароля, то какой хитровывернутый пароль не придумай — всеравно свиснут.
WCH>ЛОЛ. Простите. Первый пункт статьи как раз говорит о том, что делать так не надо
Тут вообщето расматривается случай кражи хакером базы с сервера — а у таких лолов может быть все что угодно
Re[6]: Разработчикам систем парольной аутентификации
Здравствуйте, Nik_1, Вы писали:
KV>>Я предлагаю не верить мне на слово, а взять любой md5 крэкер и самостоятельно проверить, сколько времени займет получения пароля lenochka из 4855d3ec96264f93ef6eb61c09a3c14b и #lenOchka720 из f20025e85f38e95e091069ed327f454e, если учитывать, что для получения этих хешей использовалась соль kochetkov.vladimir, добавленная к концу каждого из паролей. N_>С учетом того что не все хранят кешь вместо открытого пароля, то какой хитровывернутый пароль не придумай — всеравно свиснут.
Зачастую риск (и не только информационной безопасности, но и в принципе, в терминах риск-менеджмента) предполагает наличие одного или даже нескольких факторов, контрмеры к которым невозможны на том же уровне, на котором существует этот риск. Является ли это поводом для принятия такого риска (т.е. отказу от каких-либо контрмер вообще) или нет — зависит от конкретной системы, ее модели угроз и т.п. Универсального решения здесь быть не может.
Здравствуйте, Nik_1, Вы писали:
WCH>>ЛОЛ. Простите. Первый пункт статьи как раз говорит о том, что делать так не надо N_>Тут вообщето расматривается случай кражи хакером базы с сервера — а у таких лолов может быть все что угодно
Для кражи базы достаточно лишь одной таблэтки sql-инъекции или LFI/RFI на стороне сервера, в общем случае.
Здравствуйте, Nik_1, Вы писали:
N_>ССЗБ здесь какраз таки банк, потому что ни один нормальный человек каждый месяц зазубривать очередную хню типа Luz1XSQc0s небудет, а буджет их записывать
Я повторю еще раз: существует стандарт, который предписывает всем банкам, обеспечивающим процессинг платежных карт, вводить меры по обеспечению безопасности, в т.ч. (я цитирую стандарт http://pcidss.ru/files/pub/pdf/pcidss_v2.0_russian.pdf):
8.5.9 Изменение пароля пользователя не реже одного раза в 90 дней.
KV>>и банк ответственности за его действия в части, касающейся нарушения конфиденциальности его пароля, нести уже не должен. N_>Ага, у банка слямзили базу паролей с серверов, а он ответственность нести не должен лол!
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, Nik_1, Вы писали:
KV>>>Я предлагаю не верить мне на слово, а взять любой md5 крэкер и самостоятельно проверить, сколько времени займет получения пароля lenochka из 4855d3ec96264f93ef6eb61c09a3c14b и #lenOchka720 из f20025e85f38e95e091069ed327f454e, если учитывать, что для получения этих хешей использовалась соль kochetkov.vladimir, добавленная к концу каждого из паролей. N_>>С учетом того что не все хранят кешь вместо открытого пароля, то какой хитровывернутый пароль не придумай — всеравно свиснут.
KV>Зачастую риск (и не только информационной безопасности, но и в принципе, в терминах риск-менеджмента) предполагает наличие одного или даже нескольких факторов, контрмеры к которым невозможны на том же уровне, на котором существует этот риск. Является ли это поводом для принятия такого риска (т.е. отказу от каких-либо контрмер вообще) или нет — зависит от конкретной системы, ее модели угроз и т.п. Универсального решения здесь быть не может.
Тока начинать надо фиксить дыры безопасности со слабого, а не над пользователями измываться заставляя их каждый месяц зазубривать очередные '#lenOchka720'. А слабым звеном тут какраз являются сервера сервиса, а не пользователь. Если нормально защищать свои сервера от взлома и брутфорса, то даже примитивный пароль "lenochka" фиг сломаешь.
Re[8]: Разработчикам систем парольной аутентификации
Здравствуйте, Nik_1, Вы писали:
N_>Тока начинать надо фиксить дыры безопасности со слабого,
Это неверно. Начинать фиксить дыры нужно с угроз наиболее высокой степени риска.
N_>а не над пользователями измываться заставляя их каждый месяц зазубривать очередные '#lenOchka720'.
Приходи к нам в отрасль — покажешь, как надо
N_>А слабым звеном тут какраз являются сервера сервиса, а не пользователь.
Пользователь всегда является слабым звеном, хотя бы потому что он неконтролируем владельцем системы, а его поведение недетерминировано и не может быть сформулировано сколь-нибудь формально.
N_>Если нормально защищать свои сервера от взлома и брутфорса, то даже примитивный пароль "lenochka" фиг сломаешь.
Мне хотелось услышать хоть какие-то аргументы в пользу этого утверждения.
Здравствуйте, Nik_1, Вы писали:
N_>Тебя удевляет что среди чиновников встречаются тупые, которые принимают тупые законы? Ну ты прям как не в России живешь
Меня удивляет, что ты даже не поинтересовался, чем является PCI DSS и какое он имеет отношение к российским чиновникам, а спорить продолжил
KV>>>>и банк ответственности за его действия в части, касающейся нарушения конфиденциальности его пароля, нести уже не должен. N_>>>Ага, у банка слямзили базу паролей с серверов, а он ответственность нести не должен лол!
KV>>Откуда взялось выделенное допущение? N_>Ты сам рассматриваешь случай когда у сервиса базу слямзили
В этой ветке — ни слова об этом не упоминал Разве кража базы пользователей с сервера — единственный возможный канал утечки пароля?
Здравствуйте, kochetkov.vladimir, Вы писали: N_>>а не над пользователями измываться заставляя их каждый месяц зазубривать очередные '#lenOchka720'.
KV>Приходи к нам в отрасль — покажешь, как надо
Да мне как-то и в моей неплохо платят Уверен что сможете заинтересвать чтоб туда перебрался?
N_>>А слабым звеном тут какраз являются сервера сервиса, а не пользователь.
KV>Пользователь всегда является слабым звеном, хотя бы потому что он неконтролируем владельцем системы, а его поведение недетерминировано и не может быть сформулировано сколь-нибудь формально.
Точно так же можно сказать : админы сервиса всегда является слабым звеном, хотя бы потому что он неконтролируем пользователем системы, а его поведение недетерминировано и не может быть сформулировано сколь-нибудь формально.
N_>>Если нормально защищать свои сервера от взлома и брутфорса, то даже примитивный пароль "lenochka" фиг сломаешь.
KV>Мне хотелось услышать хоть какие-то аргументы в пользу этого утверждения.
При атаке по словарю для подобного пароля будет использоваться словарь где-нить на миллион вариантов, а при наличии в сервисе защиты от брутфорса наврятли злоумышленнику удастся сделать столько попыток.
Re[7]: Разработчикам систем парольной аутентификации
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, Nik_1, Вы писали:
N_>>Тебя удевляет что среди чиновников встречаются тупые, которые принимают тупые законы? Ну ты прям как не в России живешь
KV>Меня удивляет, что ты даже не поинтересовался, чем является PCI DSS и какое он имеет отношение к российским чиновникам, а спорить продолжил
Да мне пофиг кто именно написал, сути это не меняет KV>>>>>и банк ответственности за его действия в части, касающейся нарушения конфиденциальности его пароля, нести уже не должен. N_>>>>Ага, у банка слямзили базу паролей с серверов, а он ответственность нести не должен лол!
KV>>>Откуда взялось выделенное допущение? N_>>Ты сам рассматриваешь случай когда у сервиса базу слямзили
KV>В этой ветке — ни слова об этом не упоминал Разве кража базы пользователей с сервера — единственный возможный канал утечки пароля?
ну и для защиты от какого канала утечки требуется требование менять каждый месяц пароли и делать его вида Luz1XSQc0s? Я тебе писал про те уезвимости которые ты сам упоминал в э той ветке
Re[10]: Разработчикам систем парольной аутентификации
Здравствуйте, Nik_1, Вы писали:
N_>>>Если нормально защищать свои сервера от взлома и брутфорса, то даже примитивный пароль "lenochka" фиг сломаешь.
KV>>Мне хотелось услышать хоть какие-то аргументы в пользу этого утверждения. N_>При атаке по словарю для подобного пароля будет использоваться словарь где-нить на миллион вариантов, а при наличии в сервисе защиты от брутфорса наврятли злоумышленнику удастся сделать столько попыток.
А если злоумышленники знают жертву и ее привычки, то начнут с перебора самых простых вариантов и где-нибудь на 3-й попытке откроют аккаунт паролем, совпадающим с именем любимой девушки
Re[11]: Разработчикам систем парольной аутентификации
Здравствуйте, Working Class Hero, Вы писали:
WCH>Здравствуйте, Nik_1, Вы писали:
N_>>>>Если нормально защищать свои сервера от взлома и брутфорса, то даже примитивный пароль "lenochka" фиг сломаешь.
KV>>>Мне хотелось услышать хоть какие-то аргументы в пользу этого утверждения. N_>>При атаке по словарю для подобного пароля будет использоваться словарь где-нить на миллион вариантов, а при наличии в сервисе защиты от брутфорса наврятли злоумышленнику удастся сделать столько попыток.
WCH>А если злоумышленники знают жертву и ее привычки, то начнут с перебора самых простых вариантов и где-нибудь на 3-й попытке откроют аккаунт паролем, совпадающим с именем любимой девушки
От социального инжиниринга требование каждый месяц запоминать новый пароль вида Luz1XSQc0s неспасет, ибо он будет записываться где-нибуть, а не запоминаться.
Re[12]: Разработчикам систем парольной аутентификации
Здравствуйте, Nik_1, Вы писали:
WCH>>А если злоумышленники знают жертву и ее привычки, то начнут с перебора самых простых вариантов и где-нибудь на 3-й попытке откроют аккаунт паролем, совпадающим с именем любимой девушки N_>От социального инжиниринга требование каждый месяц запоминать новый пароль вида Luz1XSQc0s неспасет, ибо он будет записываться где-нибуть, а не запоминаться.
Ну, влезть в квартиру с целью украсть бумажку с паролем — дело несколько более хлопотное, шумное и грязное (в прямом смысле этого слова), чем угадать пароль, имея некоторые вводные данные.
Re[13]: Разработчикам систем парольной аутентификации
Здравствуйте, Working Class Hero, Вы писали:
WCH>Здравствуйте, Nik_1, Вы писали:
WCH>>>А если злоумышленники знают жертву и ее привычки, то начнут с перебора самых простых вариантов и где-нибудь на 3-й попытке откроют аккаунт паролем, совпадающим с именем любимой девушки N_>>От социального инжиниринга требование каждый месяц запоминать новый пароль вида Luz1XSQc0s неспасет, ибо он будет записываться где-нибуть, а не запоминаться.
WCH>Ну, влезть в квартиру с целью украсть бумажку с паролем — дело несколько более хлопотное, шумное и грязное (в прямом смысле этого слова), чем угадать пароль, имея некоторые вводные данные.
Зачем влезать Ты ж сам пишешь что хорошо знает человека, и тогда вполне вероятно временами бывает унего дома.
Re[14]: Разработчикам систем парольной аутентификации
Здравствуйте, Nik_1, Вы писали:
WCH>>Ну, влезть в квартиру с целью украсть бумажку с паролем — дело несколько более хлопотное, шумное и грязное (в прямом смысле этого слова), чем угадать пароль, имея некоторые вводные данные. N_>Зачем влезать Ты ж сам пишешь что хорошо знает человека, и тогда вполне вероятно временами бывает унего дома.
Хорошо знает != знает, где лежит бумажка.
Re[8]: Разработчикам систем парольной аутентификации
Здравствуйте, Nik_1, Вы писали:
KV>>Меня удивляет, что ты даже не поинтересовался, чем является PCI DSS и какое он имеет отношение к российским чиновникам, а спорить продолжил N_>Да мне пофиг кто именно написал, сути это не меняет
По сути — это обязательный для российских банков стандарт, который оны обязаны выполнять, чтобы обслуживать карты Visa на территории РФ. Ты об этой сути или о какой-то другой?
KV>>В этой ветке — ни слова об этом не упоминал Разве кража базы пользователей с сервера — единственный возможный канал утечки пароля? N_>ну и для защиты от какого канала утечки требуется требование менять каждый месяц пароли
Не каждый месяц, а не реже чем раз в 90 дней, как я написал выше. И я разве где-то сказал, что это мера по устранению канала утечки? Требования периодической смены паролей вводится для:
1. ограничения времени, доступного атакующему, владеющему какой-либо информацией, которая может способствовать воссозданию или подбору пароля.
2. ограничения времени, в течении которого атакующий может использовать скомпрометированный пароль.
N_> и делать его вида Luz1XSQc0s?
это требование вводится для того, чтобы увеличить время, необходимое атакующему для компрометации пароля и сделать его заведомо большим, чем доступное ему, с учетом ограничений, упомянутых выше.
Здравствуйте, Nik_1, Вы писали:
WCH>>А если злоумышленники знают жертву и ее привычки, то начнут с перебора самых простых вариантов и где-нибудь на 3-й попытке откроют аккаунт паролем, совпадающим с именем любимой девушки N_>От социального инжиниринга требование каждый месяц запоминать новый пароль вида Luz1XSQc0s неспасет, ибо он будет записываться где-нибуть, а не запоминаться.
Тебе дать базу keepassx с записанными в ней паролями?
Ну и к чему ты это написал?? По порядку величины я не ошибся, уровень сложности вполне нормально оценил. Чем принципиально при брутфорсе 400к отличается от 1000к
Re[7]: Разработчикам систем парольной аутентификации
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Зачастую риск (и не только информационной безопасности, но и в принципе, в терминах риск-менеджмента) предполагает наличие одного или даже нескольких факторов, контрмеры к которым невозможны на том же уровне, на котором существует этот риск. Является ли это поводом для принятия такого риска (т.е. отказу от каких-либо контрмер вообще) или нет — зависит от конкретной системы, ее модели угроз и т.п. Универсального решения здесь быть не может.
Один из самых больших рисков это енфорсинг частой смены пароля и то, что гордо называют "password complexity requirements"
В результате вместо нормальных паролей юзер ставит слово, начинающееся с большой буквы + цифра в конце, которую просто инкрементят когда система в очередной раз заставляет сменить пароль.
В итоге хотели как лучше а выходит как всегда.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[4]: Разработчикам систем парольной аутентификации
K>>тут же вроде имеется в виду ограничение на максимальную длину N_>Темболее, ограничения сверху я еще реже встречал, чем ограничения снизу
Было такое.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[3]: Разработчикам систем парольной аутентификации
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>И если пользователь изменяет лишь один символ, хотя его предупреждают о том, что пароль должен быть не похож на предыдущие, то он ССЗБ и банк ответственности за его действия в части, касающейся нарушения конфиденциальности его пароля, нести уже не должен.
А пользователь изменяет лишь один символ потому как он задолбался каждый раз выдумывать новый пароль, который будет нормально запоминаться. Его больше парят рабочие вопросы а тут вдруг к нему пристали со своими дурацкими паролями
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[5]: Разработчикам систем парольной аутентификации
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, mrTwister, Вы писали:
T>>То есть ССЗБ ка к был без принудительной смены пароля, так и с ней остался.
KV>Ну, поэтому он и ССЗБ. Не был бы им, не остался бы без принудительной смены пароля.
Т.е. вы посматриваете вручную пароли пользователей, и тех у кого простые заставляете переодически менять? ну вы жжоте
Re[12]: Разработчикам систем парольной аутентификации
Здравствуйте, Nik_1, Вы писали:
N_>Здравствуйте, kochetkov.vladimir, Вы писали: KV>>скажи, а вот про миллион, ты сделал вывод на основании каких-то аргументов или так, с потолка взял? Например, в словаре паролей от Грея (http://letitbit.net/download/1525508/33428.316e864f00e53485996577047a85/dic-from-Grey.txt.html KV>>) на 429439 слов, этот пароль находится на 189261 строке
N_>Ну и к чему ты это написал?? По порядку величины я не ошибся, уровень сложности вполне нормально оценил. Чем принципиально при брутфорсе 400к отличается от 1000к
Вообще-то порядок у них разный, если что. Но в целом ты прав, относительно применимости онлайн брутфорса в подобной ситуации. Написал я это для того, чтобы подать тебе пример аргументированных утверждений, т.к. без них кроме флейма здесь ничего не будет.
Правда, есть одно "но". Если мы рассматриваем админа, как потенциального атакующего (а мне неизвестны годные модели угроз, где это не рассматривается), то получаем реальный риск атаки на подбор паролей пользователей из хэшей в обход всех предложенных тобой механизмов защиты. А следовательно, атакующему возможно будет проще подкупить персонал, чем заниматься удаленными атаками. Как будешь закрывать эту угрозу?
Здравствуйте, Nik_1, Вы писали:
N_>Мы тут вроде блондинку обсуждаем, поставившую простой пароль, а не продвинутого пользователя, использующего keepassx Что ты сам там выше по треду говорил про типичного пользователя? Иль когда тебе выгодно, он сразу становится "нетипичным" и весьма продвинутым Толсто...
Мы здесь обсуждаем не блондинку, а сферического пользователя, допущения о котором мы можем делать основываясь исключительно на статистической информации, да и то осторожно. Повторю еще раз то, что сказал выше: это зависит от конкретной системы — на чьей стороне лежат последствия того, как пользователь будет хранить свой пароль. В случае банков и всех обсуждаемых контрмер, внедренных в них, эти последствия угрожают пользователю и в его зоне ответственности лежит обеспечение безопасности хранения его пароля. Не обеспечит — потеряет деньги, банк его об этом предупреждал. В таком случае, даже блондинка вполне может снизойти до того, чтобы подумать об относительно безопасном хранении своих паролей в эти системы.
Бывают и системы, в которых ответственность распределена прямо противоположно, как я и говорил выше.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, Nik_1, Вы писали:
KV>>>Я это говорил к тому, что легко давать советы, не находясь внутри всего этого, не зная всей "кухни" и даже десятой части тех критериев, на основе которых принимается то или иное решение в рамках выработки контрмер. N_>>Т.е. проще говоря приминил стандартный прием демагога "сначало добейся".
KV>Если бы я его применил, то кроме той фразы больше бы ничего не написал. Почему ты убрал остальной текст из цитаты?
Так остальная часть сообщения была таким же троллингом типа "кардинальная раздница между 400к и 1000к"
Re[15]: Разработчикам систем парольной аутентификации
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Мы здесь обсуждаем не блондинку, а сферического пользователя, допущения о котором мы можем делать основываясь исключительно на статистической информации, да и то осторожно. Повторю еще раз то, что сказал выше: это зависит от конкретной системы — на чьей стороне лежат последствия того, как пользователь будет хранить свой пароль. В случае банков и всех обсуждаемых контрмер, внедренных в них, эти последствия угрожают пользователю и в его зоне ответственности лежит обеспечение безопасности хранения его пароля. Не обеспечит — потеряет деньги, банк его об этом предупреждал. В таком случае, даже блондинка вполне может снизойти до того, чтобы подумать об относительно безопасном хранении своих паролей в эти системы.
Так в случаи банков вина в компроментации паролей в большенстве случаев какраз происходит по вине банков. Только вот расплачивают пользователи из-за хитрожопо составленных договоров, что всегда и во всем виноват и отвечает только пользователь, даже если слажал банк.
Re[13]: Разработчикам систем парольной аутентификации
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, Nik_1, Вы писали:
N_>>Здравствуйте, kochetkov.vladimir, Вы писали: KV>>>скажи, а вот про миллион, ты сделал вывод на основании каких-то аргументов или так, с потолка взял? Например, в словаре паролей от Грея (http://letitbit.net/download/1525508/33428.316e864f00e53485996577047a85/dic-from-Grey.txt.html KV>>>) на 429439 слов, этот пароль находится на 189261 строке
N_>>Ну и к чему ты это написал?? По порядку величины я не ошибся, уровень сложности вполне нормально оценил. Чем принципиально при брутфорсе 400к отличается от 1000к
KV>Вообще-то порядок у них разный, если что.
Поряд — это вообщето в 10 раз, так? для сведения или ты будешь утверждать что 1000/400 >= 10
Re[8]: Разработчикам систем парольной аутентификации
Здравствуйте, Banned by IT, Вы писали:
BBI>Один из самых больших рисков это енфорсинг частой смены пароля и то, что гордо называют "password complexity requirements" BBI>В результате вместо нормальных паролей юзер ставит слово, начинающееся с большой буквы + цифра в конце, которую просто инкрементят когда система в очередной раз заставляет сменить пароль. BBI>В итоге хотели как лучше а выходит как всегда.
И ряде систем — ущерб от реализации этой угрозы полностью ложится на пользователя, о чем его честно предупреждали заранее. Это приемлемая с т.з. рисков ситуация для владельца системы. В другом ряде систем, само нанесение пользователям какого-либо ущерба, как клиентам системы неприемлемо и там уже расклад совсем другой.
Нет смысла, обсуждая сферическую систему, однозначно заявлять о вредности тех или иных контрмер. Это просто глупо.
Здравствуйте, Nik_1, Вы писали:
N_>Здравствуйте, kochetkov.vladimir, Вы писали: KV>>1. ограничения времени, доступного атакующему, владеющему какой-либо информацией, которая может способствовать воссозданию или подбору пароля. N_>Для этого есть более действенные способы : временные лимиты на попытки при подборе пароля.
Что именно будет происходить при превышении этого лимита? И этот лимит не поможет, если в качестве информации, способствующей восстановлению пароля атакующим, будет его хеш. Мы же вроде это уже выяснили?
KV>>2. ограничения времени, в течении которого атакующий может использовать скомпрометированный пароль. N_>Если пароль скопроментирован, то чтоб все деньги свиснуть надо менее 90 дней, так что опять мимо
Это если цель лишь свистнуть деньги, имеющиеся на счету на момент свиста. Но пассивный мониторинг финансовых транзакций, скажем, с целью сбора компромата — тоже вполне себе цель. Или доступ к детализации мобильника с той же целью. Или к данным длительного медицинского обследования. И т.д.
Так что не мимо, а просто кто-то не очень хорошо себе представляет то количество актуальных угроз, которые иногда приходится принимать во внимание при принятии решений о безопасности.
N_>>> и делать его вида Luz1XSQc0s? KV>>это требование вводится для того, чтобы увеличить время, необходимое атакующему для компрометации пароля и сделать его заведомо большим, чем доступное ему, с учетом ограничений, упомянутых выше. N_>Затыкание одно дыры путем создания другой, офигеть хорошее решение. Когда дыру можно было заткнуть другими методами, не создающими дополнительной уязвимости.
Перечисли эти методы, пожалуйста.
N_>Не удивлюсь, если привиденный тобой стандарт писали такие же "специалисты", а ты теперь на него как на мега авторитетный и неоспоримый источник ссылаешься
Здравствуйте, kochetkov.vladimir, Вы писали: KV>Правда, есть одно "но". Если мы рассматриваем админа, как потенциального атакующего (а мне неизвестны годные модели угроз, где это не рассматривается), то получаем реальный риск атаки на подбор паролей пользователей из хэшей в обход всех предложенных тобой механизмов защиты. А следовательно, атакующему возможно будет проще подкупить персонал, чем заниматься удаленными атаками. Как будешь закрывать эту угрозу?
Ну так такой вид атаки будет какраз по вине банка, а не пользователь ССЗБ От наличия злоумышленников среди сотрудников банка пользователю не защититься, тут надо лучше за своими людьми конторе следить
Re[6]: Разработчикам систем парольной аутентификации
Здравствуйте, Nik_1, Вы писали:
N_>Т.е. вы посматриваете вручную пароли пользователей, и тех у кого простые заставляете переодически менять? ну вы жжоте
Я полагаю, что mrTwister имел ввиду, что пользователь остается без периодической смены паролей в переносном смысле, т.к. замена одной цифры в пароле на следующую действительно мало что дает. Отвечал ему, исходя из этого предположения.
Здравствуйте, Banned by IT, Вы писали:
BBI>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>И если пользователь изменяет лишь один символ, хотя его предупреждают о том, что пароль должен быть не похож на предыдущие, то он ССЗБ и банк ответственности за его действия в части, касающейся нарушения конфиденциальности его пароля, нести уже не должен. BBI>А пользователь изменяет лишь один символ потому как он задолбался каждый раз выдумывать новый пароль, который будет нормально запоминаться. Его больше парят рабочие вопросы а тут вдруг к нему пристали со своими дурацкими паролями
См. выше про распределение объектов ущерба в тех или иных системах.
Здравствуйте, Nik_1, Вы писали:
N_>Так в случаи банков вина в компроментации паролей в большенстве случаев какраз происходит по вине банков.
Честно говоря, я устал спорить с необоснованными заявлениями. Приведи статистические данные, подтверждающие выделенное утверждение.
N_>Только вот расплачивают пользователи из-за хитрожопо составленных договоров, что всегда и во всем виноват и отвечает только пользователь, даже если слажал банк.
У меня к договорам с банками тоже есть свои претензии, но как это относится к исходному топику?
Здравствуйте, Nik_1, Вы писали:
KV>>Если бы я его применил, то кроме той фразы больше бы ничего не написал. Почему ты убрал остальной текст из цитаты? N_>Так остальная часть сообщения была таким же троллингом типа "кардинальная раздница между 400к и 1000к"
Здравствуйте, Nik_1, Вы писали:
N_>Ну так такой вид атаки будет какраз по вине банка, а не пользователь ССЗБ
И? Это повод не вводить требования к паролям и его периодической замене и к админам сервиса?
N_>От наличия злоумышленников среди сотрудников банка пользователю не защититься,
А пользователю и не надо защищаться от этого. Ему надо лишь иметь возможность доказать, что он сделал все, что требовал от него банк в плане защиты своих активов.
N_>тут надо лучше за своими людьми конторе следить
Я выше уже написал, как я отношусь к подобным советам, боюсь ничего нового на эту тему ты от меня здесь уже не услышишь.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, Nik_1, Вы писали:
N_>>Здравствуйте, kochetkov.vladimir, Вы писали: KV>>>1. ограничения времени, доступного атакующему, владеющему какой-либо информацией, которая может способствовать воссозданию или подбору пароля. N_>>Для этого есть более действенные способы : временные лимиты на попытки при подборе пароля.
KV>Что именно будет происходить при превышении этого лимита? И этот лимит не поможет, если в качестве информации, способствующей восстановлению пароля атакующим, будет его хеш. Мы же вроде это уже выяснили?
Да, мы выяснили что в этом случаи банк должен разбираться со своими сотрудниками, свиснувшими базу хешей, а не вешать свою вину и проблемы на пользователей.
KV>>>2. ограничения времени, в течении которого атакующий может использовать скомпрометированный пароль. N_>>Если пароль скопроментирован, то чтоб все деньги свиснуть надо менее 90 дней, так что опять мимо
KV>Это если цель лишь свистнуть деньги, имеющиеся на счету на момент свиста. Но пассивный мониторинг финансовых транзакций, скажем, с целью сбора компромата — тоже вполне себе цель. Или доступ к детализации мобильника с той же целью. Или к данным длительного медицинского обследования. И т.д.
KV>Так что не мимо, а просто кто-то не очень хорошо себе представляет то количество актуальных угроз, которые иногда приходится принимать во внимание при принятии решений о безопасности.
Если за поролем скрываются важные для пользователя данные, то он не станет ставить пароль 123.
N_>>>> и делать его вида Luz1XSQc0s? KV>>>это требование вводится для того, чтобы увеличить время, необходимое атакующему для компрометации пароля и сделать его заведомо большим, чем доступное ему, с учетом ограничений, упомянутых выше. N_>>Затыкание одно дыры путем создания другой, офигеть хорошее решение. Когда дыру можно было заткнуть другими методами, не создающими дополнительной уязвимости.
KV>Перечисли эти методы, пожалуйста.
прочитай выше по треду, я уже не раз писал про ограничение на подбор.
N_>>Не удивлюсь, если привиденный тобой стандарт писали такие же "специалисты", а ты теперь на него как на мега авторитетный и неоспоримый источник ссылаешься
KV>Такие же специалисты, как кто?
Как говорится не будем показывать пальцем, хотя это и был слонёнок
Re[7]: Разработчикам систем парольной аутентификации
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, Nik_1, Вы писали:
N_>>Т.е. вы посматриваете вручную пароли пользователей, и тех у кого простые заставляете переодически менять? ну вы жжоте
KV>Я полагаю, что mrTwister имел ввиду, что пользователь остается без периодической смены паролей в переносном смысле, т.к. замена одной цифры в пароле на следующую действительно мало что дает. Отвечал ему, исходя из этого предположения.
ну так ты написал :
Не был бы им, не остался бы без принудительной смены пароля.
Т.е. из написанного получается, что пароль заставляете менять только пользователей-ССЗБ, а нормальных не заставляете.
Re[17]: Разработчикам систем парольной аутентификации
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, Nik_1, Вы писали:
N_>>Так в случаи банков вина в компроментации паролей в большенстве случаев какраз происходит по вине банков.
KV>Честно говоря, я устал спорить с необоснованными заявлениями. Приведи статистические данные, подтверждающие выделенное утверждение.
Большинство компроментаций пароля к картам происходит скраммерами. Или по твоему пользователь виноват что банк не следит за своими банкоматами и позволяет скраммерам ставить на них считывающие устройства?
N_>>Только вот расплачивают пользователи из-за хитрожопо составленных договоров, что всегда и во всем виноват и отвечает только пользователь, даже если слажал банк.
KV>У меня к договорам с банками тоже есть свои претензии, но как это относится к исходному топику?
Вот так и относится, что банки свою вину( неумение следить за своими банкоматами и обеспечить безопасность пластиковых карт) перекладывают на пользователей и он расплачивается за их ошибки.
Re[12]: Разработчикам систем парольной аутентификации
Здравствуйте, Nik_1, Вы писали:
KV>>Что именно будет происходить при превышении этого лимита? И этот лимит не поможет, если в качестве информации, способствующей восстановлению пароля атакующим, будет его хеш. Мы же вроде это уже выяснили? N_>Да, мы выяснили что в этом случаи банк должен разбираться со своими сотрудниками, свиснувшими базу хешей, а не вешать свою вину и проблемы на пользователей.
Вину в данном случае на пользователей никто не вешает, а проблемы здесь в первую очередь не у банка, а у пользователей, чьи пароли были скомпрометированы.
KV>>Так что не мимо, а просто кто-то не очень хорошо себе представляет то количество актуальных угроз, которые иногда приходится принимать во внимание при принятии решений о безопасности. N_>Если за поролем скрываются важные для пользователя данные, то он не станет ставить пароль 123.
Ты по-прежнему говоришь про блондинку? Он может поставить любой пароль, который ему даст поставить система, нет никаких объективных аргументов в пользу того, чтобы считать, что пользователь, осознавая важность своих данных, непременно использует сложный пароль.
KV>>Перечисли эти методы, пожалуйста. N_>прочитай выше по треду, я уже не раз писал про ограничение на подбор.
А я уже не раз попросил тебя более подробно расписать, как именно он должен быть реализован.
Здравствуйте, Nik_1, Вы писали:
KV>>Такие же специалисты, как кто? N_>Как говорится не будем показывать пальцем, хотя это и был слонёнок
хочу, чтобы ты понимал, что мы не будем показывать пальцем, не потому что "так говорится", а потому что есть п.5 правил общения на форумах RSDN http://rsdn.ru/Info/rules.xml
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, Nik_1, Вы писали:
KV>>>Вообще-то порядок у них разный, если что. N_>>Поряд — это вообщето в 10 раз, так? для сведения или ты будешь утверждать что 1000/400 >= 10
KV>Для сведения: порядок — это количество разрядов в числе.
Тебя послушать, так 999999 и 1000000 тоже на порядок разлечуются
Порядок, это какраз в 10 раз, а в твоем случаи 1000/400=2.5 называется "в разы"
Re[8]: Разработчикам систем парольной аутентификации
Здравствуйте, Nik_1, Вы писали:
N_>Втом то и дело, что это лишь перекладывание с больной головы на здоровую, а не повышение защищенности системы
Нет, это не перекладывание, а исключение фактора, влияющего на защищенность системы, за счет введения мер, понижающих юзабилити сервиса с т.з. его пользователей.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, Nik_1, Вы писали:
N_>>Ну так такой вид атаки будет какраз по вине банка, а не пользователь ССЗБ
KV>И? Это повод не вводить требования к паролям и его периодической замене и к админам сервиса?
Это повод не перекладывать свои проблемы на пользователей, создавая им дополнительный гиморой.
N_>>От наличия злоумышленников среди сотрудников банка пользователю не защититься,
KV>А пользователю и не надо защищаться от этого. Ему надо лишь иметь возможность доказать, что он сделал все, что требовал от него банк в плане защиты своих активов.
А для этого должна быть призумция невиновности : если банк считает что это пользователь скомпроментировал свой пароль — он должен это доказать, а не перекладывать с больной головы на здоровую.
Re[13]: Разработчикам систем парольной аутентификации
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, Nik_1, Вы писали:
KV>>>Что именно будет происходить при превышении этого лимита? И этот лимит не поможет, если в качестве информации, способствующей восстановлению пароля атакующим, будет его хеш. Мы же вроде это уже выяснили? N_>>Да, мы выяснили что в этом случаи банк должен разбираться со своими сотрудниками, свиснувшими базу хешей, а не вешать свою вину и проблемы на пользователей.
KV>Вину в данном случае на пользователей никто не вешает, а проблемы здесь в первую очередь не у банка, а у пользователей, чьи пароли были скомпрометированы.
KV>>>Так что не мимо, а просто кто-то не очень хорошо себе представляет то количество актуальных угроз, которые иногда приходится принимать во внимание при принятии решений о безопасности. N_>>Если за поролем скрываются важные для пользователя данные, то он не станет ставить пароль 123.
KV>Ты по-прежнему говоришь про блондинку? Он может поставить любой пароль, который ему даст поставить система, нет никаких объективных аргументов в пользу того, чтобы считать, что пользователь, осознавая важность своих данных, непременно использует сложный пароль.
KV>>>Перечисли эти методы, пожалуйста. N_>>прочитай выше по треду, я уже не раз писал про ограничение на подбор.
KV>А я уже не раз попросил тебя более подробно расписать, как именно он должен быть реализован.
прогрессивным увелечением времени на повторную попытку, например : 10с, 20с,30с, 1м, 5м, 15м, ... Вслучаи, если речь идет о доступе к деньгам то допустимо будет вообще на день блокировать при 5 неправильных попытках ввода.
Re[8]: Разработчикам систем парольной аутентификации
Здравствуйте, Nik_1, Вы писали:
N_>ну так ты написал : N_>
N_>Не был бы им, не остался бы без принудительной смены пароля.
N_>Т.е. из написанного получается, что пароль заставляете менять только пользователей-ССЗБ, а нормальных не заставляете.
Не получается. Здесь, в тон mrTwister'у доносится мысль о том, что если бы пользователь менял не один символ в пароле, а весь пароль целиком, то принудительная смена пароля имела бы для него смысл. Если же он этого не делает, меняя по одному символу, то фактически остается без периодической смены пароля, хотя и проходит через эту процедуру.
Здравствуйте, Nik_1, Вы писали:
KV>>Честно говоря, я устал спорить с необоснованными заявлениями. Приведи статистические данные, подтверждающие выделенное утверждение. N_>Большинство компроментаций пароля к картам происходит скраммерами. Или по твоему пользователь виноват что банк не следит за своими банкоматами и позволяет скраммерам ставить на них считывающие устройства?
К пин-кодам карт не выставляются требования, которые мы здесь обсуждаем. В чем смысл их упоминания здесь?
N_>>>Только вот расплачивают пользователи из-за хитрожопо составленных договоров, что всегда и во всем виноват и отвечает только пользователь, даже если слажал банк.
KV>>У меня к договорам с банками тоже есть свои претензии, но как это относится к исходному топику? N_>Вот так и относится, что банки свою вину( неумение следить за своими банкоматами и обеспечить безопасность пластиковых карт) перекладывают на пользователей и он расплачивается за их ошибки.
Загляни все же к чему предъявляются требования PCI DSS. Непосредственно пластиковые карты тут не причем. Или ты где-то видел банк, который заставляет использовать полноалфавитные пин-коды и три раза в месяц менять их?
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, Nik_1, Вы писали:
N_>>Втом то и дело, что это лишь перекладывание с больной головы на здоровую, а не повышение защищенности системы
KV>Нет, это не перекладывание, а исключение фактора, влияющего на защищенность системы, за счет введения мер, понижающих юзабилити сервиса с т.з. его пользователей.
только вот одна загвозка : данная мера снижает защещенность, а не повышает её
Re[9]: Разработчикам систем парольной аутентификации
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, Nik_1, Вы писали:
N_>>ну так ты написал : N_>>
N_>>Не был бы им, не остался бы без принудительной смены пароля.
N_>>Т.е. из написанного получается, что пароль заставляете менять только пользователей-ССЗБ, а нормальных не заставляете.
KV>Не получается. Здесь, в тон mrTwister'у доносится мысль о том, что если бы пользователь менял не один символ в пароле, а весь пароль целиком, то принудительная смена пароля имела бы для него смысл.
Ну значит так написал, что я прочитал это подругому, совсем не то что имелось ввиду KV>Если же он этого не делает, меняя по одному символу, то фактически остается без периодической смены пароля, хотя и проходит через эту процедуру.
Так втом то и проблема, что это никтобольшинство не будут дело. Только извращенец станет каждый месяц зазубривать новый хитровывернутый пароль, абсолютное же большинство будет либо записывать его, либо менять по одной букве. Я отношусь ко вторым
Re[16]: Разработчикам систем парольной аутентификации
Здравствуйте, Nik_1, Вы писали:
KV>>И? Это повод не вводить требования к паролям и его периодической замене и к админам сервиса? N_>Это повод не перекладывать свои проблемы на пользователей, создавая им дополнительный гиморой.
Так ты распишешь гениальную систему защиты от брут-форса, которая по твоему мнению делает ненужной все эти парольные политики или нет?
N_>>>От наличия злоумышленников среди сотрудников банка пользователю не защититься,
KV>>А пользователю и не надо защищаться от этого. Ему надо лишь иметь возможность доказать, что он сделал все, что требовал от него банк в плане защиты своих активов. N_>А для этого должна быть призумция невиновности : если банк считает что это пользователь скомпроментировал свой пароль — он должен это доказать, а не перекладывать с больной головы на здоровую.
Презумпция невиновности в нашей стране существует только по части уголовных преступлений. Претензии к банкам решаются арбитражем, никакой презумпции там нет и банк, в данном случае, ничего доказывать не должен.
Здравствуйте, Nik_1, Вы писали:
N_>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>Здравствуйте, Nik_1, Вы писали:
N_>>>Втом то и дело, что это лишь перекладывание с больной головы на здоровую, а не повышение защищенности системы
KV>>Нет, это не перекладывание, а исключение фактора, влияющего на защищенность системы, за счет введения мер, понижающих юзабилити сервиса с т.з. его пользователей. N_>только вот одна загвозка : данная мера снижает защещенность, а не повышает её
Здравствуйте, Nik_1, Вы писали:
N_>Так втом то и проблема, что это никтобольшинство не будут дело. Только извращенец станет каждый месяц зазубривать новый хитровывернутый пароль, абсолютное же большинство будет либо записывать его, либо менять по одной букве. Я отношусь ко вторым
Там выше написано, кем с т.з. владельца системы (некоторого класса, не всех систем, конечно же) являются такие пользователи.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, Nik_1, Вы писали:
KV>>>Для сведения: порядок — это количество разрядов в числе. N_>>Тебя послушать, так 999999 и 1000000 тоже на порядок различаются
KV>Первое — сотни тысяч, второе — миллионы. Порядок разный.
Тогда с тобой все ястно, больше вопросов нет
Re[20]: Разработчикам систем парольной аутентификации
Здравствуйте, Nik_1, Вы писали:
KV>>К пин-кодам карт не выставляются требования, которые мы здесь обсуждаем. В чем смысл их упоминания здесь? N_>А про какие пароли у банков мы говорим? Я чет сходу не припомню других.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, Nik_1, Вы писали:
N_>>прогрессивным увелечением времени на повторную попытку, например : 10с, 20с,30с, 1м, 5м, 15м, ... Вслучаи, если речь идет о доступе к деньгам то допустимо будет вообще на день блокировать при 5 неправильных попытках ввода.
KV>Отлично. Я, являсь атакующим, генерирую десятки-сотни неправильных попыток в секунду в отношении всех пользователей интернет-банка, используя для этого распределенный ботнет, чем всерьез и надолго парализую возможность нормальной работы настоящих клиентов. Что дальше?
А это уже называется ДДОС атака. Собсно опять задача банка бороться с этим. Кстати, а откуда у злоумышленника взялась база логинов клиентов, не банк ли опять недосмотрел за своими админами?
Re[18]: Разработчикам систем парольной аутентификации
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, Nik_1, Вы писали:
KV>>>К пин-кодам карт не выставляются требования, которые мы здесь обсуждаем. В чем смысл их упоминания здесь? N_>>А про какие пароли у банков мы говорим? Я чет сходу не припомню других.
KV>Например, которые нужно вводить тут: https://click.alfabank.ru или тут: https://connect.raiffeisen.ru/rba/Login.do
Вроде подобные системы используют не пароль, а ssl сертификат, который в отделении банка пользователю генерят и выдают на флешке.
Re[16]: Разработчикам систем парольной аутентификации
Здравствуйте, Nik_1, Вы писали:
N_>А это уже называется ДДОС атака. Собсно опять задача банка бороться с этим.
Прикольно. Ты предлагаешь банку сначала создать DDOS-условия в своей системе, а потом отважно бороться с ними? Нет, твое решение создает реальный, а главное более высокий риск и именно тебе, как его автору сейчас необходимо что-то предложить, чтобы уйти от этого риска. Я знаю, как уйти от него в твоем решении. Но очень хочу, чтобы ты сам к нему пришел.
N_>Кстати, а откуда у злоумышленника взялась база логинов клиентов, не банк ли опять недосмотрел за своими админами?
Прямой перебор. Это гораздо проще, чем подбор пароля, т.к. энтропия имен пользователей — минимальная, практически при любой схеме их формирования. Опять-таки, даже если атака производится на одного конкретного клиента, чей логин известен атакующему по независящим от банка причинам — это уже большая проблема, ибо имиджевые и юридические риски, если что.
Здравствуйте, Nik_1, Вы писали:
KV>>Например, которые нужно вводить тут: https://click.alfabank.ru или тут: https://connect.raiffeisen.ru/rba/Login.do N_>Вроде подобные системы используют не пароль, а ssl сертификат, который в отделении банка пользователю генерят и выдают на флешке.
Обе приведенные системы используют парольную аутентификацию. Это я тебе, как их клиент говорю. Альфа-банк при этом использует еще и мультифакторную аутентификацию на основе не только постоянного, но и одноразовых паролей, присылаемых по SMS на каждую вновь создаваемую сессию.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, Nik_1, Вы писали:
N_>>А это уже называется ДДОС атака. Собсно опять задача банка бороться с этим.
KV>Прикольно. Ты предлагаешь банку сначала создать DDOS-условия в своей системе, а потом отважно бороться с ними?
Ну вот чето карты никто не досит, хотя там всего 3 попытки в сутки KV>Нет, твое решение создает реальный, а главное более высокий риск и именно тебе, как его автору сейчас необходимо что-то предложить, чтобы уйти от этого риска. Я знаю, как уйти от него в твоем решении. Но очень хочу, чтобы ты сам к нему пришел.
И какой же риск оно создает?
N_>>Кстати, а откуда у злоумышленника взялась база логинов клиентов, не банк ли опять недосмотрел за своими админами?
KV>Прямой перебор. Это гораздо проще, чем подбор пароля, т.к. энтропия имен пользователей — минимальная, практически при любой схеме их формирования.
Ну тут все какраз проще, лимит на попытки будет не только для логинов, но и для айпишников. Так что при переборе еще и логинов много не наперебираются. KV>Опять-таки, даже если атака производится на одного конкретного клиента, чей логин известен атакующему по независящим от банка причинам — это уже большая проблема, ибо имиджевые и юридические риски, если что.
Вслучаи, если атакуют конкретного клиента, то это уже другими средствами решается, а не созданием геммороя подефолту всем пользователям.
Re[22]: Разработчикам систем парольной аутентификации
Здравствуйте, Nik_1, Вы писали:
KV>>Например, которые нужно вводить тут: https://click.alfabank.ru или тут: https://connect.raiffeisen.ru/rba/Login.do N_>Вроде подобные системы используют не пароль, а ssl сертификат, который в отделении банка пользователю генерят и выдают на флешке.
Здравствуйте, kochetkov.vladimir, Вы писали:
k> Ну, например, у нас, этого в общем-то достаточно, чтобы приложение не было принято в продакшн Криптографическая нестойкость GUID — их единственный недостаток
А где они ещё остались криптогоафически нестойкие?
Здравствуйте, Nik_1, Вы писали:
KV>>Прикольно. Ты предлагаешь банку сначала создать DDOS-условия в своей системе, а потом отважно бороться с ними? N_>Ну вот чето карты никто не досит, хотя там всего 3 попытки в сутки
Наверное, это потому что для того, чтобы их досить, нужно физически обладать этой картой? Аналогом таких условий для аутентификации в интернет-банке являются всевозможные токены и смарт-карты. И это более неудобно, чем парольная аутентификация.
KV>>Нет, твое решение создает реальный, а главное более высокий риск и именно тебе, как его автору сейчас необходимо что-то предложить, чтобы уйти от этого риска. Я знаю, как уйти от него в твоем решении. Но очень хочу, чтобы ты сам к нему пришел. N_>И какой же риск оно создает?
Отказ в обслуживании — одна из угроз, как по классической модели CIA, так и по STRIDE и ей подобным. Риск, который создает твое решение по CVSS оценивается в 8.5 баллов, из 10 возможных, что дофига по любым критериям и формируется следующими факторами: (AV:N/AC:L/Au:N/C:N/I:N/A:C/E:H/RL:U/RC:ND/CDP:LM/TD:H/CR:ND/IR:ND/AR:ND). Что значат эти буквы можно посмотреть здесь: http://www.first.org/cvss/cvss-guide.html
N_>>>Кстати, а откуда у злоумышленника взялась база логинов клиентов, не банк ли опять недосмотрел за своими админами?
KV>>Прямой перебор. Это гораздо проще, чем подбор пароля, т.к. энтропия имен пользователей — минимальная, практически при любой схеме их формирования. N_>Ну тут все какраз проще, лимит на попытки будет не только для логинов, но и для айпишников. Так что при переборе еще и логинов много не наперебираются.
айпишники — еще хуже идея, т.к. за одним IP могут скрываться тысячи клиентов банка. Два примера: 50 миллионов абонентов сотовой компании, использующих мобильный интернет — это около тысячи IP-адресов по всей стране. Около трех десятков тысяч сотрудников нашей компании, являющихся клиентами Альфа-банка — это около 20 IP-адресов по всей стране, если речь идет о доступе в интернет-банк из офиса.
А ведь достаточно, чтобы компьютер лишь одного из них стал частью ботнета, участвующего в брутфорсе, чтобы доступ к интернет-банку потеряли все.
KV>>Опять-таки, даже если атака производится на одного конкретного клиента, чей логин известен атакующему по независящим от банка причинам — это уже большая проблема, ибо имиджевые и юридические риски, если что. N_>Вслучаи, если атакуют конкретного клиента, то это уже другими средствами решается, а не созданием геммороя подефолту всем пользователям.
А что, есть объективные причины считать, что этим "конкретным клиентом" не может стать любой из пользователей?
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, Nik_1, Вы писали:
N_>>С тобой можно будет продолжить дескутировать лишь после того, как разберешся с базовыми понятиями из школьной математики. Такими как "отличается в разы" и "отличается на порядок".
KV>По существу — есть что возразить?
Что можно было по существу писать — нужно чтоб ты был способен читать написанное, разобрался в базовой терминологии, а не тролил в стиле 999 от 1000 отличается на порядок.
Re[22]: Разработчикам систем парольной аутентификации
Здравствуйте, Nik_1, Вы писали:
KV>>По существу — есть что возразить? N_>Что можно было по существу писать — нужно чтоб ты был способен читать написанное, разобрался в базовой терминологии, а не тролил в стиле 999 от 1000 отличается на порядок.
Здравствуйте, Кочетков Владимир.
Статья хорошая, прочел ее всю, но не всю ветку обсуждений, она так разрослась из-за п.6 вредных советов и, возможно, из-за отсутствия определения пароля, т.е. чем пароль отличается от любого другого ключа.
Отличия пароля от любого другого ключа заключается в том, что он хранится только в памяти бортового компьтера пользователя (в мозге значит).
Отсюда выводы: пароль должен легко запоминаться и извлекаться из памяти пользователем, легко набираться на клаве, не быть легкоугадываемым и , вообще, наименее подверженным brute force.
В этой ветке уже написали здесь
Здравствуйте, Nik_1, Вы писали:
K>>тут же вроде имеется в виду ограничение на максимальную длину N_>Темболее, ограничения сверху я еще реже встречал, чем ограничения снизу
Полно. К примеру, Office365, запущенный в эксплуатацию совсем недавно. Имеем весь набор ограничений: от 8 до 16 символов, минимум 3 класса из (цифра, строчная, заглавная, остальное).
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
или ты будешь утверждать что 1000/400 >= 10 
Ты ж сам пишешь что хорошо знает человека, и тогда вполне вероятно временами бывает унего дома. 
