За время моей работы на текущей должности, у меня накопилось к вам несколько просьб, которые я рискнул опубликовать прямо здесь. Не сочтите за труд ознакомиться с ними. Я буду искренне счастлив обсудить их с вами, если это необходимо. Заранее спасибо, искренне ваш, бла-бла-бла и все такое.
Собственно, просьбы:
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
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>11. Доумившись до идентификаторов сессий (вам заняться больше нечем?) не изобретайте велосипед, вам и так есть где развернуть свою фантазию при реализации функции хэширования. Используйте в качестве идентификаторов GUID, или (вот это вообще будет бомба!) случайное двухзначное число, равное количеству секунд в момент входа в систему
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>13. Обязательно блокируйте запись пользователя после 5-10 неудачных попыток входа. Ведь потом будет так весело наблюдать за впахивающим саппортом, отбивающимся от запросов на разблокировку всей пользовательской базы разом.
Так и делаем. В соответствие с OWASP Secure Coding Practices
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]: Разработчикам систем парольной аутентификации
Здравствуйте, adontz, Вы писали:
KV>>11. Доумившись до идентификаторов сессий (вам заняться больше нечем?) не изобретайте велосипед, вам и так есть где развернуть свою фантазию при реализации функции хэширования. Используйте в качестве идентификаторов GUID, или (вот это вообще будет бомба!) случайное двухзначное число, равное количеству секунд в момент входа в систему
A>Можно комментарий?
Вероятно хацкер может предсказать следующий и вклиниться в чужую сессию. Хотя я не понимаю какому злобному Буратино такое вообще может прийти в голову — ведь гораздо проще использовать криптографический RNG.
Главное гармония ...
Re[2]: Разработчикам систем парольной аутентификации
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>11. Доумившись до идентификаторов сессий (вам заняться больше нечем?) не изобретайте велосипед, вам и так есть где развернуть свою фантазию при реализации функции хэширования. Используйте в качестве идентификаторов GUID, или (вот это вообще будет бомба!) случайное двухзначное число, равное количеству секунд в момент входа в систему
A>Можно комментарий?
в двух словах: зная текущее значение GUID, выданного в качестве идентификатора сессии можно (за разумное количество попыток) предугадать последующие и, тем самым, перехватить чужую сессию.
Здравствуйте, Mazay, Вы писали:
KV>>>11. Доумившись до идентификаторов сессий (вам заняться больше нечем?) не изобретайте велосипед, вам и так есть где развернуть свою фантазию при реализации функции хэширования. Используйте в качестве идентификаторов GUID, или (вот это вообще будет бомба!) случайное двухзначное число, равное количеству секунд в момент входа в систему A>>Можно комментарий? M>Вероятно хацкер может предсказать следующий и вклиниться в чужую сессию. Хотя я не понимаю какому злобному Буратино такое вообще может прийти в голову — ведь гораздо проще использовать криптографический RNG.
Но с другой стороны если могут угадать идентификатор одной сессии по другой, то могут и попросту использовать идентификатор сессии как есть. В таком случае привязываются к IP. То есть я не очень понимаю почему угадывание идентификатора сессии по известному идентификатору принципиально страшнее использования известного идентификатора как есть.
Здравствуйте, Mazay, Вы писали:
M>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>13. Обязательно блокируйте запись пользователя после 5-10 неудачных попыток входа. Ведь потом будет так весело наблюдать за впахивающим саппортом, отбивающимся от запросов на разблокировку всей пользовательской базы разом. M>Так и делаем. В соответствие с OWASP Secure Coding Practices
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>А если серьезно, то это вопросы не к разрабам, а к заказчикам. Разрабы всегда рады делать надежный, защищенный и удобный софт, только далеко не все заказчики готовы за это платить.
Здравствуйте, adontz, Вы писали:
A>Но с другой стороны если могут угадать идентификатор одной сессии по другой, то могут и попросту использовать идентификатор сессии как есть.
Здравствуйте, kochetkov.vladimir, Вы писали:
k> P.S: Уважаемые разработчики, убедительно прошу вас рассмотреть мои просьбы и, по-возможности, следовать им. А то работы у меня совсем не останется
Здравствуйте, kochetkov.vladimir, Вы писали:
A>>Но с другой стороны если могут угадать идентификатор одной сессии по другой, то могут и попросту использовать идентификатор сессии как есть. KV>Для доступа в чужую сесиию?
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>в двух словах: зная текущее значение GUID, выданного в качестве идентификатора сессии можно (за разумное количество попыток) предугадать последующие и, тем самым, перехватить чужую сессию.
Зависит от типа GUID'а. Скажем, в Java он делается из криптографически-сильного генератора случайных чисел.
Sapienti sat!
Re[6]: Разработчикам систем парольной аутентификации
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, kochetkov.vladimir, Вы писали:
A>>>Но с другой стороны если могут угадать идентификатор одной сессии по другой, то могут и попросту использовать идентификатор сессии как есть. KV>>Для доступа в чужую сесиию?
A>Ну если идентификатор чужой?
Если идентификатор чужой, то как он оказался у тебя?
Здравствуйте, Anton Batenev, Вы писали:
AB>Здравствуйте, kochetkov.vladimir, Вы писали:
k>> P.S: Уважаемые разработчики, убедительно прошу вас рассмотреть мои просьбы и, по-возможности, следовать им. А то работы у меня совсем не останется
AB>OpenID?
Далеко не всегда применимо и есть свои тараканы. Но направление — верное, да.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>в двух словах: зная текущее значение GUID, выданного в качестве идентификатора сессии можно (за разумное количество попыток) предугадать последующие и, тем самым, перехватить чужую сессию. C>Зависит от типа GUID'а.
Это плохо, т.к. делает безопасность твоей системы явно зависимой от реализации конкретного алгоритма в сторонней библиотеке.
C>Скажем, в Java он делается из криптографически-сильного генератора случайных чисел.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, Cyberax, Вы писали:
C>>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>>в двух словах: зная текущее значение GUID, выданного в качестве идентификатора сессии можно (за разумное количество попыток) предугадать последующие и, тем самым, перехватить чужую сессию. C>>Зависит от типа GUID'а.
KV>Это плохо, т.к. делает безопасность твоей системы явно зависимой от реализации конкретного алгоритма в сторонней библиотеке.
C>>Скажем, в Java он делается из криптографически-сильного генератора случайных чисел.
KV>Я не силен в java... это оговорено в стандарте?
JDK поддерживает версии 3 и 4 UUID
Re[6]: Разработчикам систем парольной аутентификации
Здравствуйте, Курилка, Вы писали:
KV>>Я не силен в java... это оговорено в стандарте?
К>JDK поддерживает версии 3 и 4 UUID
Ну, для использования в качестве идентификатора сессии подходит только 4 (http://tools.ietf.org/html/rfc4122#section-4.4). Но я спрашивал не об этом. Гарантировано ли чем-либо, что в сторонних реализациях JDK будет также поддерживаться 4-ая версия? Т.е. что вызов randomUUID() будет возвращать именно рандомный (с использованием криптографически-устойчивых СЧ) UUID?
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>1. Безусловно отличной идеей является хранение паролей пользователей на сервере в открытом виде. Ведь это так здорово: в ответе на запрос о восстановлении доступа, прислать пользователю его старый пароль, не заставляя его использовать временный и не обременяя его задачей придумывания нового постоянного. Да и целую форму с обработчиком сэкономите
Тут некоторые товарищи дальше пошли — примерно раз в 2-3 месяца рассылают всем клиентам письма по типу следующего:
==
Здравствуйте, ...!
С большим удовольствием сообщаем,
что в основной ассортимент футболок добавлены 6 новых цветов!
...
Доступ в личный кабинет: Имя пользователя: ...
Пароль: ...
==
Re[7]: Разработчикам систем парольной аутентификации
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, Курилка, Вы писали:
KV>>>Я не силен в java... это оговорено в стандарте?
К>>JDK поддерживает версии 3 и 4 UUID
KV>Ну, для использования в качестве идентификатора сессии подходит только 4 (http://tools.ietf.org/html/rfc4122#section-4.4). Но я спрашивал не об этом. Гарантировано ли чем-либо, что в сторонних реализациях JDK будет также поддерживаться 4-ая версия? Т.е. что вызов randomUUID() будет возвращать именно рандомный (с использованием криптографически-устойчивых СЧ) UUID?
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]: Разработчикам систем парольной аутентификации
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>>в двух словах: зная текущее значение GUID, выданного в качестве идентификатора сессии можно (за разумное количество попыток) предугадать последующие и, тем самым, перехватить чужую сессию. C>>Зависит от типа GUID'а. KV>Это плохо, т.к. делает безопасность твоей системы явно зависимой от реализации конкретного алгоритма в сторонней библиотеке.
Если в описании библиотеки написано, что генерация из secure random — не вижу проблем.
C>>Скажем, в Java он делается из криптографически-сильного генератора случайных чисел. KV>Я не силен в java... это оговорено в стандарте?
На что? GUID должен как-то генерироваться из MAC-адреса и ещё чего-то там, только все на это нафиг забили.
