Re[12]: Разработчикам систем парольной аутентификации
От: kochetkov.vladimir Россия https://kochetkov.github.io
Дата: 21.08.11 16:51
Оценка: +1 :)
Здравствуйте, Nik_1, Вы писали:

KV>>Я это говорил к тому, что легко давать советы, не находясь внутри всего этого, не зная всей "кухни" и даже десятой части тех критериев, на основе которых принимается то или иное решение в рамках выработки контрмер.

N_>Т.е. проще говоря приминил стандартный прием демагога "сначало добейся".

Если бы я его применил, то кроме той фразы больше бы ничего не написал. Тут дело не в добейся, а в том, что профессионал в одной области, рассказывающий профессионалу в другой области, как ему работать и чем заниматься — выглядит, по меньшей мере, странно.

[Интервью] .NET Security — это просто
Автор: kochetkov.vladimir
Дата: 07.11.17
Re[7]: Разработчикам систем парольной аутентификации
От: Banned by IT  
Дата: 21.08.11 16:56
Оценка:
Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Зачастую риск (и не только информационной безопасности, но и в принципе, в терминах риск-менеджмента) предполагает наличие одного или даже нескольких факторов, контрмеры к которым невозможны на том же уровне, на котором существует этот риск. Является ли это поводом для принятия такого риска (т.е. отказу от каких-либо контрмер вообще) или нет — зависит от конкретной системы, ее модели угроз и т.п. Универсального решения здесь быть не может.


Один из самых больших рисков это енфорсинг частой смены пароля и то, что гордо называют "password complexity requirements"
В результате вместо нормальных паролей юзер ставит слово, начинающееся с большой буквы + цифра в конце, которую просто инкрементят когда система в очередной раз заставляет сменить пароль.
В итоге хотели как лучше а выходит как всегда.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[4]: Разработчикам систем парольной аутентификации
От: Banned by IT  
Дата: 21.08.11 16:56
Оценка:
Здравствуйте, Nik_1, Вы писали:


K>>тут же вроде имеется в виду ограничение на максимальную длину

N_>Темболее, ограничения сверху я еще реже встречал, чем ограничения снизу
Было такое.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[2]: Разработчикам систем парольной аутентификации
От: Banned by IT  
Дата: 21.08.11 16:56
Оценка: +1
Здравствуйте, mrTwister, Вы писали:

T>А вот интересно, много ли есть людей, которие при принудительной смене пароля новый получают не из старого путем замены одного символа (password1, password2 и т.д.)? Защищенность очень сильно повысились, гемор пользователям добавили не зря!

Исчезающе мало ИМХО.
Такая система лишь провоцирует на создание простого пароля с инкрементом.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[3]: Разработчикам систем парольной аутентификации
От: Banned by IT  
Дата: 21.08.11 16:56
Оценка:
Здравствуйте, kochetkov.vladimir, Вы писали:

KV>И если пользователь изменяет лишь один символ, хотя его предупреждают о том, что пароль должен быть не похож на предыдущие, то он ССЗБ и банк ответственности за его действия в части, касающейся нарушения конфиденциальности его пароля, нести уже не должен.

А пользователь изменяет лишь один символ потому как он задолбался каждый раз выдумывать новый пароль, который будет нормально запоминаться. Его больше парят рабочие вопросы а тут вдруг к нему пристали со своими дурацкими паролями
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[5]: Разработчикам систем парольной аутентификации
От: Banned by IT  
Дата: 21.08.11 16:56
Оценка: +4
Здравствуйте, 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, значит пора закрыть эту страницу.
Всем пока
Re[5]: Разработчикам систем парольной аутентификации
От: Banned by IT  
Дата: 21.08.11 16:59
Оценка:
Здравствуйте, Eagle-XK, Вы писали:

EX>А мастер-пароли от баз я не забываю.

А их тоже принудительно надо менять каждые 90 дней?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[9]: Разработчикам систем парольной аутентификации
От: Nik_1 Россия  
Дата: 21.08.11 17:00
Оценка: -1
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>1. ограничения времени, доступного атакующему, владеющему какой-либо информацией, которая может способствовать воссозданию или подбору пароля.
Для этого есть более действенные способы : временные лимиты на попытки при подборе пароля.
KV>2. ограничения времени, в течении которого атакующий может использовать скомпрометированный пароль.
Если пароль скопроментирован, то чтоб все деньги свиснуть надо менее 90 дней, так что опять мимо

N_>> и делать его вида Luz1XSQc0s?

KV>это требование вводится для того, чтобы увеличить время, необходимое атакующему для компрометации пароля и сделать его заведомо большим, чем доступное ему, с учетом ограничений, упомянутых выше.
Затыкание одно дыры путем создания другой, офигеть хорошее решение. Когда дыру можно было заткнуть другими методами, не создающими дополнительной уязвимости.
Не удивлюсь, если привиденный тобой стандарт писали такие же "специалисты", а ты теперь на него как на мега авторитетный и неоспоримый источник ссылаешься
Re[5]: Разработчикам систем парольной аутентификации
От: Nik_1 Россия  
Дата: 21.08.11 17:02
Оценка:
Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Здравствуйте, mrTwister, Вы писали:


T>>То есть ССЗБ ка к был без принудительной смены пароля, так и с ней остался.


KV>Ну, поэтому он и ССЗБ. Не был бы им, не остался бы без принудительной смены пароля.


Т.е. вы посматриваете вручную пароли пользователей, и тех у кого простые заставляете переодически менять? ну вы жжоте
Re[12]: Разработчикам систем парольной аутентификации
От: kochetkov.vladimir Россия https://kochetkov.github.io
Дата: 21.08.11 17:04
Оценка:
Здравствуйте, Nik_1, Вы писали:

N_>Здравствуйте, kochetkov.vladimir, Вы писали:

KV>>скажи, а вот про миллион, ты сделал вывод на основании каких-то аргументов или так, с потолка взял? Например, в словаре паролей от Грея (http://letitbit.net/download/1525508/33428.316e864f00e53485996577047a85/dic-from-Grey.txt.html
KV>>) на 429439 слов, этот пароль находится на 189261 строке

N_>Ну и к чему ты это написал?? По порядку величины я не ошибся, уровень сложности вполне нормально оценил. Чем принципиально при брутфорсе 400к отличается от 1000к


Вообще-то порядок у них разный, если что. Но в целом ты прав, относительно применимости онлайн брутфорса в подобной ситуации. Написал я это для того, чтобы подать тебе пример аргументированных утверждений, т.к. без них кроме флейма здесь ничего не будет.

Правда, есть одно "но". Если мы рассматриваем админа, как потенциального атакующего (а мне неизвестны годные модели угроз, где это не рассматривается), то получаем реальный риск атаки на подбор паролей пользователей из хэшей в обход всех предложенных тобой механизмов защиты. А следовательно, атакующему возможно будет проще подкупить персонал, чем заниматься удаленными атаками. Как будешь закрывать эту угрозу?

[Интервью] .NET Security — это просто
Автор: kochetkov.vladimir
Дата: 07.11.17
Re[14]: Разработчикам систем парольной аутентификации
От: kochetkov.vladimir Россия https://kochetkov.github.io
Дата: 21.08.11 17:04
Оценка:
Здравствуйте, Nik_1, Вы писали:

N_>Мы тут вроде блондинку обсуждаем, поставившую простой пароль, а не продвинутого пользователя, использующего keepassx Что ты сам там выше по треду говорил про типичного пользователя? Иль когда тебе выгодно, он сразу становится "нетипичным" и весьма продвинутым Толсто...


Мы здесь обсуждаем не блондинку, а сферического пользователя, допущения о котором мы можем делать основываясь исключительно на статистической информации, да и то осторожно. Повторю еще раз то, что сказал выше: это зависит от конкретной системы — на чьей стороне лежат последствия того, как пользователь будет хранить свой пароль. В случае банков и всех обсуждаемых контрмер, внедренных в них, эти последствия угрожают пользователю и в его зоне ответственности лежит обеспечение безопасности хранения его пароля. Не обеспечит — потеряет деньги, банк его об этом предупреждал. В таком случае, даже блондинка вполне может снизойти до того, чтобы подумать об относительно безопасном хранении своих паролей в эти системы.

Бывают и системы, в которых ответственность распределена прямо противоположно, как я и говорил выше.

Так мы о каких из них?

[Интервью] .NET Security — это просто
Автор: kochetkov.vladimir
Дата: 07.11.17
Re[13]: Разработчикам систем парольной аутентификации
От: Nik_1 Россия  
Дата: 21.08.11 17:07
Оценка:
Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Здравствуйте, Nik_1, Вы писали:


KV>>>Я это говорил к тому, что легко давать советы, не находясь внутри всего этого, не зная всей "кухни" и даже десятой части тех критериев, на основе которых принимается то или иное решение в рамках выработки контрмер.

N_>>Т.е. проще говоря приминил стандартный прием демагога "сначало добейся".

KV>Если бы я его применил, то кроме той фразы больше бы ничего не написал. Почему ты убрал остальной текст из цитаты?


Так остальная часть сообщения была таким же троллингом типа "кардинальная раздница между 400к и 1000к"
Re[15]: Разработчикам систем парольной аутентификации
От: Nik_1 Россия  
Дата: 21.08.11 17:12
Оценка:
Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Мы здесь обсуждаем не блондинку, а сферического пользователя, допущения о котором мы можем делать основываясь исключительно на статистической информации, да и то осторожно. Повторю еще раз то, что сказал выше: это зависит от конкретной системы — на чьей стороне лежат последствия того, как пользователь будет хранить свой пароль. В случае банков и всех обсуждаемых контрмер, внедренных в них, эти последствия угрожают пользователю и в его зоне ответственности лежит обеспечение безопасности хранения его пароля. Не обеспечит — потеряет деньги, банк его об этом предупреждал. В таком случае, даже блондинка вполне может снизойти до того, чтобы подумать об относительно безопасном хранении своих паролей в эти системы.


Так в случаи банков вина в компроментации паролей в большенстве случаев какраз происходит по вине банков. Только вот расплачивают пользователи из-за хитрожопо составленных договоров, что всегда и во всем виноват и отвечает только пользователь, даже если слажал банк.
Re[13]: Разработчикам систем парольной аутентификации
От: Nik_1 Россия  
Дата: 21.08.11 17:14
Оценка:
Здравствуйте, 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]: Разработчикам систем парольной аутентификации
От: kochetkov.vladimir Россия https://kochetkov.github.io
Дата: 21.08.11 17:14
Оценка:
Здравствуйте, Banned by IT, Вы писали:

BBI>Один из самых больших рисков это енфорсинг частой смены пароля и то, что гордо называют "password complexity requirements"

BBI>В результате вместо нормальных паролей юзер ставит слово, начинающееся с большой буквы + цифра в конце, которую просто инкрементят когда система в очередной раз заставляет сменить пароль.
BBI>В итоге хотели как лучше а выходит как всегда.

И ряде систем — ущерб от реализации этой угрозы полностью ложится на пользователя, о чем его честно предупреждали заранее. Это приемлемая с т.з. рисков ситуация для владельца системы. В другом ряде систем, само нанесение пользователям какого-либо ущерба, как клиентам системы неприемлемо и там уже расклад совсем другой.

Нет смысла, обсуждая сферическую систему, однозначно заявлять о вредности тех или иных контрмер. Это просто глупо.

[Интервью] .NET Security — это просто
Автор: kochetkov.vladimir
Дата: 07.11.17
Re[10]: Разработчикам систем парольной аутентификации
От: kochetkov.vladimir Россия https://kochetkov.github.io
Дата: 21.08.11 17:14
Оценка:
Здравствуйте, Nik_1, Вы писали:

N_>Здравствуйте, kochetkov.vladimir, Вы писали:

KV>>1. ограничения времени, доступного атакующему, владеющему какой-либо информацией, которая может способствовать воссозданию или подбору пароля.
N_>Для этого есть более действенные способы : временные лимиты на попытки при подборе пароля.

Что именно будет происходить при превышении этого лимита? И этот лимит не поможет, если в качестве информации, способствующей восстановлению пароля атакующим, будет его хеш. Мы же вроде это уже выяснили?

KV>>2. ограничения времени, в течении которого атакующий может использовать скомпрометированный пароль.

N_>Если пароль скопроментирован, то чтоб все деньги свиснуть надо менее 90 дней, так что опять мимо

Это если цель лишь свистнуть деньги, имеющиеся на счету на момент свиста. Но пассивный мониторинг финансовых транзакций, скажем, с целью сбора компромата — тоже вполне себе цель. Или доступ к детализации мобильника с той же целью. Или к данным длительного медицинского обследования. И т.д.

Так что не мимо, а просто кто-то не очень хорошо себе представляет то количество актуальных угроз, которые иногда приходится принимать во внимание при принятии решений о безопасности.

N_>>> и делать его вида Luz1XSQc0s?

KV>>это требование вводится для того, чтобы увеличить время, необходимое атакующему для компрометации пароля и сделать его заведомо большим, чем доступное ему, с учетом ограничений, упомянутых выше.
N_>Затыкание одно дыры путем создания другой, офигеть хорошее решение. Когда дыру можно было заткнуть другими методами, не создающими дополнительной уязвимости.

Перечисли эти методы, пожалуйста.

N_>Не удивлюсь, если привиденный тобой стандарт писали такие же "специалисты", а ты теперь на него как на мега авторитетный и неоспоримый источник ссылаешься


Такие же специалисты, как кто?

[Интервью] .NET Security — это просто
Автор: kochetkov.vladimir
Дата: 07.11.17
Re[13]: Разработчикам систем парольной аутентификации
От: Nik_1 Россия  
Дата: 21.08.11 17:21
Оценка:
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Правда, есть одно "но". Если мы рассматриваем админа, как потенциального атакующего (а мне неизвестны годные модели угроз, где это не рассматривается), то получаем реальный риск атаки на подбор паролей пользователей из хэшей в обход всех предложенных тобой механизмов защиты. А следовательно, атакующему возможно будет проще подкупить персонал, чем заниматься удаленными атаками. Как будешь закрывать эту угрозу?
Ну так такой вид атаки будет какраз по вине банка, а не пользователь ССЗБ От наличия злоумышленников среди сотрудников банка пользователю не защититься, тут надо лучше за своими людьми конторе следить
Re[6]: Разработчикам систем парольной аутентификации
От: kochetkov.vladimir Россия https://kochetkov.github.io
Дата: 21.08.11 17:27
Оценка:
Здравствуйте, Nik_1, Вы писали:

N_>Т.е. вы посматриваете вручную пароли пользователей, и тех у кого простые заставляете переодически менять? ну вы жжоте


Я полагаю, что mrTwister имел ввиду, что пользователь остается без периодической смены паролей в переносном смысле, т.к. замена одной цифры в пароле на следующую действительно мало что дает. Отвечал ему, исходя из этого предположения.

А ты с какой целью интересуешься?

[Интервью] .NET Security — это просто
Автор: kochetkov.vladimir
Дата: 07.11.17
Re[4]: Разработчикам систем парольной аутентификации
От: kochetkov.vladimir Россия https://kochetkov.github.io
Дата: 21.08.11 17:27
Оценка:
Здравствуйте, Banned by IT, Вы писали:

BBI>Здравствуйте, kochetkov.vladimir, Вы писали:


KV>>И если пользователь изменяет лишь один символ, хотя его предупреждают о том, что пароль должен быть не похож на предыдущие, то он ССЗБ и банк ответственности за его действия в части, касающейся нарушения конфиденциальности его пароля, нести уже не должен.

BBI>А пользователь изменяет лишь один символ потому как он задолбался каждый раз выдумывать новый пароль, который будет нормально запоминаться. Его больше парят рабочие вопросы а тут вдруг к нему пристали со своими дурацкими паролями

См. выше про распределение объектов ущерба в тех или иных системах.

[Интервью] .NET Security — это просто
Автор: kochetkov.vladimir
Дата: 07.11.17
Re[16]: Разработчикам систем парольной аутентификации
От: kochetkov.vladimir Россия https://kochetkov.github.io
Дата: 21.08.11 17:27
Оценка:
Здравствуйте, Nik_1, Вы писали:

N_>Так в случаи банков вина в компроментации паролей в большенстве случаев какраз происходит по вине банков.


Честно говоря, я устал спорить с необоснованными заявлениями. Приведи статистические данные, подтверждающие выделенное утверждение.

N_>Только вот расплачивают пользователи из-за хитрожопо составленных договоров, что всегда и во всем виноват и отвечает только пользователь, даже если слажал банк.


У меня к договорам с банками тоже есть свои претензии, но как это относится к исходному топику?

[Интервью] .NET Security — это просто
Автор: kochetkov.vladimir
Дата: 07.11.17
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.