Разработчикам систем парольной аутентификации
От: kochetkov.vladimir Россия https://kochetkov.github.io
Дата: 03.09.10 15:11
Оценка: 124 (9) +2 :))) :))) :))
#Имя: FAQ.philosophy.security.harmful.advice
Уважаемые сабжы!

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

Собственно, просьбы:

1. Безусловно отличной идеей является хранение паролей пользователей на сервере в открытом виде. Ведь это так здорово: в ответе на запрос о восстановлении доступа, прислать пользователю его старый пароль, не заставляя его использовать временный и не обременяя его задачей придумывания нового постоянного. Да и целую форму с обработчиком сэкономите

2. Если вы все же решились на столь смелый поступок и таки планируете хранить в базе хэши паролей — забудьте о стандартных функциях хэширования! Вы вообще — программист или где? А известная только вам функция хэширования только добавит защищенности к вашей системе.

3. Если никакой придурок не озадачил вас в ТЗ необходимостью реализации периодической принудительной смены пароля, то возможность его изменения надо запретить вовсе. Ибо нефиг давать пользователям волю и менять пароли по десять раз на дню, расходуя при этом драгоценные ресурсы ваших серверов. И опять-таки: на целой одной форме и ее обработчике можно сэкономить.

4. Если же такой придурок таки-нашелся, не отчаивайтесь! Вы можете существенно облегчить жизнь пользователям, если разрешите им менять свой пароль на точно такой же, или использованный в прошлый раз. Мелочь, а того придурка на место поставите.

5. И вообще, запомните: идиота, выставляющего какие-либо требования к парольной защите вы просто обязаны наобмануть по полной программе! Ведь именно из-за него у вас вообще возникла необходимость в этой самой парольной защите

6. Разумеется, ваши сервера не халявная рапидшара и нехрен позволять пользователям засорять место на жестких дисках своими ублюдскими 20-символьными паролями. 8 символов хватит всем! Это в конце 90-ых всем доступно объяснил Microsoft, если кто не помнит.

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

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

9. Да-да, обязательно отражайте в логах все вводимые пароли. Потом, если внезапно рухнет база, ее можно будет легко по ним восстановить.

10. Ни в коем разе не используйте идентификаторы сессий! Вы сами-то хоть подумали, сколько кода вам придется для этого написать? Да и аутентифицироваться заново на каждую операцию безопаснее. А серверы — выдержат, мы же в п.3 их мощность сэкономили.

11. Доумившись до идентификаторов сессий (вам заняться больше нечем?) не изобретайте велосипед, вам и так есть где развернуть свою фантазию при реализации функции хэширования. Используйте в качестве идентификаторов GUID, или (вот это вообще будет бомба!) случайное двухзначное число, равное количеству секунд в момент входа в систему

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

13. Обязательно блокируйте запись пользователя после 5-10 неудачных попыток входа. Ведь потом будет так весело наблюдать за впахивающим саппортом, отбивающимся от запросов на разблокировку всей пользовательской базы разом.

14. Капча — зло. Пользователя нельзя обижать подозрениями в том, что он робот и заставлять вводить скукоженные символы. Если уж пришлось, то скукоживайте их без фанатизма, чтобы пользователь мог не напрягаясь испытать радость от того, что он не робот. Да и вообще — используйте легкоугадываемый алгоритм выбора символов для капчи. Тогда постоянные пользователи смогут вводить ее даже не глядя на экран.

15. И никогда, ни под каким предлогом, не передавайте аутентификационные данные по защищенному каналу: затрахаетесь потом это отлаживать

P.S: Уважаемые разработчики, убедительно прошу вас рассмотреть мои просьбы и, по-возможности, следовать им. А то работы у меня совсем не останется
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

22.12.10 01:06: Перенесено модератором из 'Философия программирования' — kochetkov.vladimir

Трек докладов для разработчиков на Positive Hack Days VII
Автор: kochetkov.vladimir
Дата: 15.05 16:12
security password
Re: Разработчикам систем парольной аутентификации
От: adontz Грузия http://adontz.wordpress.com/
Дата: 03.09.10 15:16
Оценка: +2
Здравствуйте, kochetkov.vladimir, Вы писали:

KV>11. Доумившись до идентификаторов сессий (вам заняться больше нечем?) не изобретайте велосипед, вам и так есть где развернуть свою фантазию при реализации функции хэширования. Используйте в качестве идентификаторов GUID, или (вот это вообще будет бомба!) случайное двухзначное число, равное количеству секунд в момент входа в систему


Можно комментарий?
A journey of a thousand miles must begin with a single step © Lau Tsu
Re: Разработчикам систем парольной аутентификации
От: Mazay Россия  
Дата: 03.09.10 15:28
Оценка:
Здравствуйте, kochetkov.vladimir, Вы писали:

KV>13. Обязательно блокируйте запись пользователя после 5-10 неудачных попыток входа. Ведь потом будет так весело наблюдать за впахивающим саппортом, отбивающимся от запросов на разблокировку всей пользовательской базы разом.

Так и делаем. В соответствие с OWASP Secure Coding Practices
Автор: kochetkov.vladimir
Дата: 02.09.10
:

Enforce account disabling after an established number of invalid logon attempts (e.g., five attempts is
common).

Правда там ниже:

The account must be disabled for a period of time sufficient to discourage brute force
guessing of credentials.


А если серьезно, то это вопросы не к разрабам, а к заказчикам. Разрабы всегда рады делать надежный, защищенный и удобный софт, только далеко не все заказчики готовы за это платить.
Главное гармония ...
Re[2]: Разработчикам систем парольной аутентификации
От: Mazay Россия  
Дата: 03.09.10 15:33
Оценка:
Здравствуйте, adontz, Вы писали:

KV>>11. Доумившись до идентификаторов сессий (вам заняться больше нечем?) не изобретайте велосипед, вам и так есть где развернуть свою фантазию при реализации функции хэширования. Используйте в качестве идентификаторов GUID, или (вот это вообще будет бомба!) случайное двухзначное число, равное количеству секунд в момент входа в систему


A>Можно комментарий?


Вероятно хацкер может предсказать следующий и вклиниться в чужую сессию. Хотя я не понимаю какому злобному Буратино такое вообще может прийти в голову — ведь гораздо проще использовать криптографический RNG.
Главное гармония ...
Re[2]: Разработчикам систем парольной аутентификации
От: kochetkov.vladimir Россия https://kochetkov.github.io
Дата: 03.09.10 15:46
Оценка:
Здравствуйте, adontz, Вы писали:

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


KV>>11. Доумившись до идентификаторов сессий (вам заняться больше нечем?) не изобретайте велосипед, вам и так есть где развернуть свою фантазию при реализации функции хэширования. Используйте в качестве идентификаторов GUID, или (вот это вообще будет бомба!) случайное двухзначное число, равное количеству секунд в момент входа в систему


A>Можно комментарий?


http://www.gotdotnet.ru/blogs/denish/1965/

в двух словах: зная текущее значение GUID, выданного в качестве идентификатора сессии можно (за разумное количество попыток) предугадать последующие и, тем самым, перехватить чужую сессию.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Трек докладов для разработчиков на Positive Hack Days VII
Автор: kochetkov.vladimir
Дата: 15.05 16:12
Re[3]: Разработчикам систем парольной аутентификации
От: adontz Грузия http://adontz.wordpress.com/
Дата: 03.09.10 15:51
Оценка:
Здравствуйте, Mazay, Вы писали:

KV>>>11. Доумившись до идентификаторов сессий (вам заняться больше нечем?) не изобретайте велосипед, вам и так есть где развернуть свою фантазию при реализации функции хэширования. Используйте в качестве идентификаторов GUID, или (вот это вообще будет бомба!) случайное двухзначное число, равное количеству секунд в момент входа в систему

A>>Можно комментарий?
M>Вероятно хацкер может предсказать следующий и вклиниться в чужую сессию. Хотя я не понимаю какому злобному Буратино такое вообще может прийти в голову — ведь гораздо проще использовать криптографический RNG.

Да не, я вот читал сей незабываемый труд
http://www.gotdotnet.ru/blogs/denish/1965/

Но с другой стороны если могут угадать идентификатор одной сессии по другой, то могут и попросту использовать идентификатор сессии как есть. В таком случае привязываются к IP. То есть я не очень понимаю почему угадывание идентификатора сессии по известному идентификатору принципиально страшнее использования известного идентификатора как есть.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[2]: Разработчикам систем парольной аутентификации
От: kochetkov.vladimir Россия https://kochetkov.github.io
Дата: 03.09.10 15:54
Оценка:
Здравствуйте, Mazay, Вы писали:

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


KV>>13. Обязательно блокируйте запись пользователя после 5-10 неудачных попыток входа. Ведь потом будет так весело наблюдать за впахивающим саппортом, отбивающимся от запросов на разблокировку всей пользовательской базы разом.

M>Так и делаем. В соответствие с OWASP Secure Coding Practices
Автор: kochetkov.vladimir
Дата: 02.09.10
:

M>

M>Enforce account disabling after an established number of invalid logon attempts (e.g., five attempts is
M>common).

M>Правда там ниже:
M>

M>The account must be disabled for a period of time sufficient to discourage brute force
M>guessing of credentials.


Ну, они там немножко не правы. Ведь кто-нибудь может вводить заведомо неправильные пароли, используя чужой логин. Или не кто-то, а скрипт. Или не логин, а логины. Получится DoS

M>А если серьезно, то это вопросы не к разрабам, а к заказчикам. Разрабы всегда рады делать надежный, защищенный и удобный софт, только далеко не все заказчики готовы за это платить.


Сомневаясь насчет выделенного, все же соглашусь
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Трек докладов для разработчиков на Positive Hack Days VII
Автор: kochetkov.vladimir
Дата: 15.05 16:12
Re[4]: Разработчикам систем парольной аутентификации
От: kochetkov.vladimir Россия https://kochetkov.github.io
Дата: 03.09.10 16:34
Оценка:
Здравствуйте, adontz, Вы писали:

A>Но с другой стороны если могут угадать идентификатор одной сессии по другой, то могут и попросту использовать идентификатор сессии как есть.


Для доступа в чужую сесиию?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Трек докладов для разработчиков на Positive Hack Days VII
Автор: kochetkov.vladimir
Дата: 15.05 16:12
Re: Разработчикам систем парольной аутентификации
От: Anton Batenev Россия https://github.com/abbat
Дата: 03.09.10 17:01
Оценка: +1
Здравствуйте, kochetkov.vladimir, Вы писали:

k> P.S: Уважаемые разработчики, убедительно прошу вас рассмотреть мои просьбы и, по-возможности, следовать им. А то работы у меня совсем не останется


OpenID?
avalon 1.0rc3 rev 361, zlib 1.2.3
Re[5]: Разработчикам систем парольной аутентификации
От: adontz Грузия http://adontz.wordpress.com/
Дата: 03.09.10 17:01
Оценка:
Здравствуйте, kochetkov.vladimir, Вы писали:

A>>Но с другой стороны если могут угадать идентификатор одной сессии по другой, то могут и попросту использовать идентификатор сессии как есть.

KV>Для доступа в чужую сесиию?

Ну если идентификатор чужой?
A journey of a thousand miles must begin with a single step © Lau Tsu
Re: Разработчикам систем парольной аутентификации
От: Wolverrum Украина  
Дата: 03.09.10 17:09
Оценка:
Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Уважаемые сабжы!


Злобненько. Хоть и справедливо
Re[3]: Разработчикам систем парольной аутентификации
От: Cyberax Марс  
Дата: 03.09.10 17:11
Оценка: +1
Здравствуйте, kochetkov.vladimir, Вы писали:

KV>в двух словах: зная текущее значение GUID, выданного в качестве идентификатора сессии можно (за разумное количество попыток) предугадать последующие и, тем самым, перехватить чужую сессию.

Зависит от типа GUID'а. Скажем, в Java он делается из криптографически-сильного генератора случайных чисел.
Sapienti sat!
Re[6]: Разработчикам систем парольной аутентификации
От: kochetkov.vladimir Россия https://kochetkov.github.io
Дата: 03.09.10 18:22
Оценка:
Здравствуйте, adontz, Вы писали:

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


A>>>Но с другой стороны если могут угадать идентификатор одной сессии по другой, то могут и попросту использовать идентификатор сессии как есть.

KV>>Для доступа в чужую сесиию?

A>Ну если идентификатор чужой?


Если идентификатор чужой, то как он оказался у тебя?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Трек докладов для разработчиков на Positive Hack Days VII
Автор: kochetkov.vladimir
Дата: 15.05 16:12
Re[2]: Разработчикам систем парольной аутентификации
От: kochetkov.vladimir Россия https://kochetkov.github.io
Дата: 03.09.10 18:22
Оценка:
Здравствуйте, Anton Batenev, Вы писали:

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


k>> P.S: Уважаемые разработчики, убедительно прошу вас рассмотреть мои просьбы и, по-возможности, следовать им. А то работы у меня совсем не останется


AB>OpenID?


Далеко не всегда применимо и есть свои тараканы. Но направление — верное, да.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Трек докладов для разработчиков на Positive Hack Days VII
Автор: kochetkov.vladimir
Дата: 15.05 16:12
Re[4]: Разработчикам систем парольной аутентификации
От: kochetkov.vladimir Россия https://kochetkov.github.io
Дата: 03.09.10 18:22
Оценка:
Здравствуйте, Cyberax, Вы писали:

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


KV>>в двух словах: зная текущее значение GUID, выданного в качестве идентификатора сессии можно (за разумное количество попыток) предугадать последующие и, тем самым, перехватить чужую сессию.

C>Зависит от типа GUID'а.

Это плохо, т.к. делает безопасность твоей системы явно зависимой от реализации конкретного алгоритма в сторонней библиотеке.

C>Скажем, в Java он делается из криптографически-сильного генератора случайных чисел.


Я не силен в java... это оговорено в стандарте?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Трек докладов для разработчиков на Positive Hack Days VII
Автор: kochetkov.vladimir
Дата: 15.05 16:12
Re[5]: Разработчикам систем парольной аутентификации
От: Курилка Россия http://kirya.narod.ru/
Дата: 03.09.10 18:49
Оценка:
Здравствуйте, kochetkov.vladimir, Вы писали:

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


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


KV>>>в двух словах: зная текущее значение GUID, выданного в качестве идентификатора сессии можно (за разумное количество попыток) предугадать последующие и, тем самым, перехватить чужую сессию.

C>>Зависит от типа GUID'а.

KV>Это плохо, т.к. делает безопасность твоей системы явно зависимой от реализации конкретного алгоритма в сторонней библиотеке.


C>>Скажем, в Java он делается из криптографически-сильного генератора случайных чисел.


KV>Я не силен в java... это оговорено в стандарте?


JDK поддерживает версии 3 и 4 UUID
Re[6]: Разработчикам систем парольной аутентификации
От: kochetkov.vladimir Россия https://kochetkov.github.io
Дата: 03.09.10 19:04
Оценка:
Здравствуйте, Курилка, Вы писали:

KV>>Я не силен в java... это оговорено в стандарте?


К>JDK поддерживает версии 3 и 4 UUID


Ну, для использования в качестве идентификатора сессии подходит только 4 (http://tools.ietf.org/html/rfc4122#section-4.4). Но я спрашивал не об этом. Гарантировано ли чем-либо, что в сторонних реализациях JDK будет также поддерживаться 4-ая версия? Т.е. что вызов randomUUID() будет возвращать именно рандомный (с использованием криптографически-устойчивых СЧ) UUID?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Трек докладов для разработчиков на Positive Hack Days VII
Автор: kochetkov.vladimir
Дата: 15.05 16:12
Re: Разработчикам систем парольной аутентификации
От: andy1618 Россия  
Дата: 03.09.10 19:29
Оценка: 11 (1) +2 :))
Здравствуйте, kochetkov.vladimir, Вы писали:

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


Тут некоторые товарищи дальше пошли — примерно раз в 2-3 месяца рассылают всем клиентам письма по типу следующего:
==

Здравствуйте, ...!

С большим удовольствием сообщаем,
что в основной ассортимент футболок добавлены 6 новых цветов!

...

Доступ в личный кабинет:
Имя пользователя: ...
Пароль: ...

==
Re[7]: Разработчикам систем парольной аутентификации
От: Курилка Россия http://kirya.narod.ru/
Дата: 03.09.10 20:13
Оценка: 22 (1)
Здравствуйте, kochetkov.vladimir, Вы писали:

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


KV>>>Я не силен в java... это оговорено в стандарте?


К>>JDK поддерживает версии 3 и 4 UUID


KV>Ну, для использования в качестве идентификатора сессии подходит только 4 (http://tools.ietf.org/html/rfc4122#section-4.4). Но я спрашивал не об этом. Гарантировано ли чем-либо, что в сторонних реализациях JDK будет также поддерживаться 4-ая версия? Т.е. что вызов randomUUID() будет возвращать именно рандомный (с использованием криптографически-устойчивых СЧ) UUID?


JSR как-то очень "расплывчато" говорит об этом :

This feature is to add UUID functionality to the J2SE platform by the addition of a UUID class for ma-
nipulating Leach-Salz variants.
The uuid (Universal Unique Identifier) is an XOPEN standard
for creating a globally unique id.
...


В TCK сомневаюсь, что включена проверка "рандомности" (ну и не очень представляю как её можно относительно дёшево сделать).
По идее, конечно есть ISO/IEC 11578:1996 и ISO/IEC 9834-8:2005, но в джавных спеках, кажется, нет гвоздями прибитой связи randomUUID с версией 4 (хотя есть в javadoc)
Re[5]: Разработчикам систем парольной аутентификации
От: Cyberax Марс  
Дата: 03.09.10 20:22
Оценка:
Здравствуйте, kochetkov.vladimir, Вы писали:

KV>>>в двух словах: зная текущее значение GUID, выданного в качестве идентификатора сессии можно (за разумное количество попыток) предугадать последующие и, тем самым, перехватить чужую сессию.

C>>Зависит от типа GUID'а.
KV>Это плохо, т.к. делает безопасность твоей системы явно зависимой от реализации конкретного алгоритма в сторонней библиотеке.
Если в описании библиотеки написано, что генерация из secure random — не вижу проблем.

C>>Скажем, в Java он делается из криптографически-сильного генератора случайных чисел.

KV>Я не силен в java... это оговорено в стандарте?
На что? GUID должен как-то генерироваться из MAC-адреса и ещё чего-то там, только все на это нафиг забили.
Sapienti sat!
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.