KV>Ну, например, у нас, этого в общем-то достаточно, чтобы приложение не было принято в продакшн
сие понятно, не в этом вопрос
KV>Криптографическая нестойкость GUID — их единственный недостаток (AFAIK), для использования в качестве ключей сессий. Но он легко устраняется, достаточно подсунуть в конструктор Guid'а в качестве seed'а годную псевдослучайную последовательность, сгенеренную например RNGCryptoServiceProvider'ом.
мы говорим только о винде?
но в целом то ясно, вообщем других недостатков нет. я просто хотел еще узнать, есть ли еще что нибудь.
Re[3]: Разработчикам систем парольной аутентификации
Здравствуйте, kochetkov.vladimir, Вы писали: KV>В чем должна заключаться такая защита? Чем она поможет пользователям в случае компрометации сервера, когда у атакующего на руках будут и хэши пароль и значение, используемое в качестве соли?
И каким образом требование хитровывернутых паролей типа '#lenOchka720' спасет от этого ??
Re[5]: Разработчикам систем парольной аутентификации
Здравствуйте, Michael Chelnokov, Вы писали:
MC>Здравствуйте, Nik_1, Вы писали:
N_>>Темболее, ограничения сверху я еще реже встречал, чем ограничения снизу
MC>Одноклассники, например. Может уже изменили, но раньше долго было ограничение.
на 8 символов?
КВ>Авторы: КВ> Кочетков Владимир
КВ>Аннотация: КВ>Советы разработчикам систем парольной аутентификации
Если никакой придурок не озадачил вас в ТЗ необходимостью реализации периодической принудительной смены пароля
А вот интересно, много ли есть людей, которие при принудительной смене пароля новый получают не из старого путем замены одного символа (password1, password2 и т.д.)? Защищенность очень сильно повысились, гемор пользователям добавили не зря!
лэт ми спик фром май харт
Re[4]: Разработчикам систем парольной аутентификации
Здравствуйте, Nik_1, Вы писали:
N_>Здравствуйте, kochetkov.vladimir, Вы писали: KV>>В чем должна заключаться такая защита? Чем она поможет пользователям в случае компрометации сервера, когда у атакующего на руках будут и хэши пароль и значение, используемое в качестве соли? N_>И каким образом требование хитровывернутых паролей типа '#lenOchka720' спасет от этого ??
Я предлагаю не верить мне на слово, а взять любой md5 крэкер и самостоятельно проверить, сколько времени займет получения пароля lenochka из 4855d3ec96264f93ef6eb61c09a3c14b и #lenOchka720 из f20025e85f38e95e091069ed327f454e, если учитывать, что для получения этих хешей использовалась соль kochetkov.vladimir, добавленная к концу каждого из паролей.
Здравствуйте, 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[7]: Разработчикам систем парольной аутентификации
Здравствуйте, Working Class Hero, Вы писали:
WCH>Здравствуйте, Nik_1, Вы писали:
N_>>С учетом того что не все хранят кешь вместо открытого пароля, то какой хитровывернутый пароль не придумай — всеравно свиснут.
WCH>ЛОЛ. Простите. Первый пункт статьи как раз говорит о том, что делать так не надо
Тут вообщето расматривается случай кражи хакером базы с сервера — а у таких лолов может быть все что угодно
Re[6]: Разработчикам систем парольной аутентификации
Здравствуйте, Nik_1, Вы писали:
KV>>Я предлагаю не верить мне на слово, а взять любой md5 крэкер и самостоятельно проверить, сколько времени займет получения пароля lenochka из 4855d3ec96264f93ef6eb61c09a3c14b и #lenOchka720 из f20025e85f38e95e091069ed327f454e, если учитывать, что для получения этих хешей использовалась соль kochetkov.vladimir, добавленная к концу каждого из паролей. N_>С учетом того что не все хранят кешь вместо открытого пароля, то какой хитровывернутый пароль не придумай — всеравно свиснут.
Зачастую риск (и не только информационной безопасности, но и в принципе, в терминах риск-менеджмента) предполагает наличие одного или даже нескольких факторов, контрмеры к которым невозможны на том же уровне, на котором существует этот риск. Является ли это поводом для принятия такого риска (т.е. отказу от каких-либо контрмер вообще) или нет — зависит от конкретной системы, ее модели угроз и т.п. Универсального решения здесь быть не может.
Здравствуйте, kochetkov.vladimir, Вы писали: KV>Есть системы, где подобные меры закрывают слишком мало рисков, чтобы их вводить (да вот, RSDN, например). Есть системы, где их владельцы несут перед пользователями некоторую ответственность, например банки. И банки обязаны вводить подобные меры, как из соображений здравого смысла, так и в соответствии с требованиями стандартнов (PCIDSS, к примеру, если речь идет о процессинге платежных карт). И если пользователь изменяет лишь один символ, хотя его предупреждают о том, что пароль должен быть не похож на предыдущие, то он ССЗБ
ССЗБ здесь какраз таки банк, потому что ни один нормальный человек каждый месяц зазубривать очередную хню типа Luz1XSQc0s небудет, а буджет их записывать KV>и банк ответственности за его действия в части, касающейся нарушения конфиденциальности его пароля, нести уже не должен.
Ага, у банка слямзили базу паролей с серверов, а он ответственность нести не должен лол!
Re[8]: Разработчикам систем парольной аутентификации
Здравствуйте, Nik_1, Вы писали:
WCH>>ЛОЛ. Простите. Первый пункт статьи как раз говорит о том, что делать так не надо N_>Тут вообщето расматривается случай кражи хакером базы с сервера — а у таких лолов может быть все что угодно
Для кражи базы достаточно лишь одной таблэтки sql-инъекции или LFI/RFI на стороне сервера, в общем случае.
Здравствуйте, 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[4]: Разработчикам систем парольной аутентификации
Здравствуйте, 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[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[8]: Разработчикам систем парольной аутентификации
Здравствуйте, Nik_1, Вы писали:
N_>Тока начинать надо фиксить дыры безопасности со слабого,
Это неверно. Начинать фиксить дыры нужно с угроз наиболее высокой степени риска.
N_>а не над пользователями измываться заставляя их каждый месяц зазубривать очередные '#lenOchka720'.
Приходи к нам в отрасль — покажешь, как надо
N_>А слабым звеном тут какраз являются сервера сервиса, а не пользователь.
Пользователь всегда является слабым звеном, хотя бы потому что он неконтролируем владельцем системы, а его поведение недетерминировано и не может быть сформулировано сколь-нибудь формально.
N_>Если нормально защищать свои сервера от взлома и брутфорса, то даже примитивный пароль "lenochka" фиг сломаешь.
Мне хотелось услышать хоть какие-то аргументы в пользу этого утверждения.
