| 1 2 3 4 5 6 |
| Разработчикам систем парольной аутентификации | |
 | От: | kochetkov.vladimir rsdn | |
| Дата: | 03.09.10 14:11 | ||
| Оценка: | 124 (9) +2   | ||
| Уважаемые сабжы! За время моей работы на текущей должности, у меня накопилось к вам несколько просьб, которые я рискнул опубликовать прямо здесь. Не сочтите за труд ознакомиться с ними. Я буду искренне счастлив обсудить их с вами, если это необходимо. Заранее спасибо, искренне ваш, бла-бла-бла и все такое. Собственно, просьбы: 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 |
| Теги: | security password |
| Re: Разработчикам систем парольной аутентификации | |
 | От: | adontz | |
| Дата: | 03.09.10 14: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 14:28 |
| Здравствуйте, kochetkov.vladimir, Вы писали: KV>13. Обязательно блокируйте запись пользователя после 5-10 неудачных попыток входа. Ведь потом будет так весело наблюдать за впахивающим саппортом, отбивающимся от запросов на разблокировку всей пользовательской базы разом. Так и делаем. В соответствие с OWASP Secure Coding Practices Автор: kochetkov.vladimir :Дата: 02.09.10 Правда там ниже:
А если серьезно, то это вопросы не к разрабам, а к заказчикам. Разрабы всегда рады делать надежный, защищенный и удобный софт, только далеко не все заказчики готовы за это платить. Главное гармония ... |
| Re[2]: Разработчикам систем парольной аутентификации | |
| От: | Mazay | |
| Дата: | 03.09.10 14:33 |
| Здравствуйте, adontz, Вы писали: KV>>11. Доумившись до идентификаторов сессий (вам заняться больше нечем?) не изобретайте велосипед, вам и так есть где развернуть свою фантазию при реализации функции хэширования. Используйте в качестве идентификаторов GUID, или (вот это вообще будет бомба!) случайное двухзначное число, равное количеству секунд в момент входа в систему A>Можно комментарий? Вероятно хацкер может предсказать следующий и вклиниться в чужую сессию. Хотя я не понимаю какому злобному Буратино такое вообще может прийти в голову — ведь гораздо проще использовать криптографический RNG. Главное гармония ... |
| Re[2]: Разработчикам систем парольной аутентификации | |
| От: | kochetkov.vladimir rsdn | |
| Дата: | 03.09.10 14: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>> |
| Re[3]: Разработчикам систем парольной аутентификации | |
| От: | adontz | |
| Дата: | 03.09.10 14: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 rsdn | |
| Дата: | 03.09.10 14:54 |
| Здравствуйте, Mazay, Вы писали: M>Здравствуйте, kochetkov.vladimir, Вы писали: KV>>13. Обязательно блокируйте запись пользователя после 5-10 неудачных попыток входа. Ведь потом будет так весело наблюдать за впахивающим саппортом, отбивающимся от запросов на разблокировку всей пользовательской базы разом. M>Так и делаем. В соответствие с OWASP Secure Coding Practices Автор: kochetkov.vladimir :Дата: 02.09.10 M> M>Правда там ниже: M>
Ну, они там немножко не правы. Ведь кто-нибудь может вводить заведомо неправильные пароли, используя чужой логин. Или не кто-то, а скрипт. Или не логин, а логины. Получится DoS M>А если серьезно, то это вопросы не к разрабам, а к заказчикам. Разрабы всегда рады делать надежный, защищенный и удобный софт, только далеко не все заказчики готовы за это платить. Сомневаясь насчет выделенного, все же соглашусь  ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>> |
| Re[4]: Разработчикам систем парольной аутентификации | |
| От: | kochetkov.vladimir rsdn | |
| Дата: | 03.09.10 15:34 |
| Здравствуйте, adontz, Вы писали: A>Но с другой стороны если могут угадать идентификатор одной сессии по другой, то могут и попросту использовать идентификатор сессии как есть. Для доступа в чужую сесиию?  ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>> |
| Re: Разработчикам систем парольной аутентификации | |
 | От: | Anton Batenev | |
| Дата: | 03.09.10 16:01 | ||
| Оценка: | +1 | ||
| Здравствуйте, kochetkov.vladimir, Вы писали: k> P.S: Уважаемые разработчики, убедительно прошу вас рассмотреть мои просьбы и, по-возможности, следовать им. А то работы у меня совсем не останется OpenID? |
| Re[5]: Разработчикам систем парольной аутентификации | |
| От: | adontz | |
| Дата: | 03.09.10 16:01 |
| Здравствуйте, kochetkov.vladimir, Вы писали: A>>Но с другой стороны если могут угадать идентификатор одной сессии по другой, то могут и попросту использовать идентификатор сессии как есть. KV>Для доступа в чужую сесиию? Ну если идентификатор чужой?  A journey of a thousand miles must begin with a single step © Lau Tsu |
| Re: Разработчикам систем парольной аутентификации | |
 | От: | Wolverrum | |
| Дата: | 03.09.10 16:09 |
| Здравствуйте, kochetkov.vladimir, Вы писали: KV>Уважаемые сабжы! Злобненько. Хоть и справедливо |
| Re[3]: Разработчикам систем парольной аутентификации | |
 | От: | Cyberax | |
| Дата: | 03.09.10 16:11 | ||
| Оценка: | +1 | ||
| Здравствуйте, kochetkov.vladimir, Вы писали: KV>в двух словах: зная текущее значение GUID, выданного в качестве идентификатора сессии можно (за разумное количество попыток) предугадать последующие и, тем самым, перехватить чужую сессию. Зависит от типа GUID'а. Скажем, в Java он делается из криптографически-сильного генератора случайных чисел. Sapienti sat! |
| Re[6]: Разработчикам систем парольной аутентификации | |
| От: | kochetkov.vladimir rsdn | |
| Дата: | 03.09.10 17:22 |
| Здравствуйте, adontz, Вы писали: A>Здравствуйте, kochetkov.vladimir, Вы писали: A>>>Но с другой стороны если могут угадать идентификатор одной сессии по другой, то могут и попросту использовать идентификатор сессии как есть. KV>>Для доступа в чужую сесиию? A>Ну если идентификатор чужой? Если идентификатор чужой, то как он оказался у тебя? ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>> |
| Re[2]: Разработчикам систем парольной аутентификации | |
| От: | kochetkov.vladimir rsdn | |
| Дата: | 03.09.10 17:22 |
| Здравствуйте, Anton Batenev, Вы писали: AB>Здравствуйте, kochetkov.vladimir, Вы писали: k>> P.S: Уважаемые разработчики, убедительно прошу вас рассмотреть мои просьбы и, по-возможности, следовать им. А то работы у меня совсем не останется AB>OpenID? Далеко не всегда применимо и есть свои тараканы. Но направление — верное, да. ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>> |
| Re[4]: Разработчикам систем парольной аутентификации | |
| От: | kochetkov.vladimir rsdn | |
| Дата: | 03.09.10 17:22 |
| Здравствуйте, Cyberax, Вы писали: C>Здравствуйте, kochetkov.vladimir, Вы писали: KV>>в двух словах: зная текущее значение GUID, выданного в качестве идентификатора сессии можно (за разумное количество попыток) предугадать последующие и, тем самым, перехватить чужую сессию. C>Зависит от типа GUID'а. Это плохо, т.к. делает безопасность твоей системы явно зависимой от реализации конкретного алгоритма в сторонней библиотеке. C>Скажем, в Java он делается из криптографически-сильного генератора случайных чисел. Я не силен в java... это оговорено в стандарте? ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>> |
| Re[5]: Разработчикам систем парольной аутентификации | |
 | От: | Курилка | |
| Дата: | 03.09.10 17: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 rsdn | |
| Дата: | 03.09.10 18: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>> |
| Re: Разработчикам систем парольной аутентификации | |
 | От: | andy1618 | |
| Дата: | 03.09.10 18:29 | ||
| Оценка: | 11 (1) +2 | ||
| Здравствуйте, kochetkov.vladimir, Вы писали: KV>1. Безусловно отличной идеей является хранение паролей пользователей на сервере в открытом виде. Ведь это так здорово: в ответе на запрос о восстановлении доступа, прислать пользователю его старый пароль, не заставляя его использовать временный и не обременяя его задачей придумывания нового постоянного. Да и целую форму с обработчиком сэкономите Тут некоторые товарищи дальше пошли — примерно раз в 2-3 месяца рассылают всем клиентам письма по типу следующего: == == |
| Re[7]: Разработчикам систем парольной аутентификации | |
| От: | Курилка | |
| Дата: | 03.09.10 19: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 как-то очень "расплывчато" говорит об этом :
В TCK сомневаюсь, что включена проверка "рандомности" (ну и не очень представляю как её можно относительно дёшево сделать). По идее, конечно есть ISO/IEC 11578:1996 и ISO/IEC 9834-8:2005, но в джавных спеках, кажется, нет гвоздями прибитой связи randomUUID с версией 4 (хотя есть в javadoc) |
| Re[5]: Разработчикам систем парольной аутентификации | |
| От: | Cyberax | |
| Дата: | 03.09.10 19:22 |
| Здравствуйте, kochetkov.vladimir, Вы писали: KV>>>в двух словах: зная текущее значение GUID, выданного в качестве идентификатора сессии можно (за разумное количество попыток) предугадать последующие и, тем самым, перехватить чужую сессию. C>>Зависит от типа GUID'а. KV>Это плохо, т.к. делает безопасность твоей системы явно зависимой от реализации конкретного алгоритма в сторонней библиотеке. Если в описании библиотеки написано, что генерация из secure random — не вижу проблем. C>>Скажем, в Java он делается из криптографически-сильного генератора случайных чисел. KV>Я не силен в java... это оговорено в стандарте? На что? GUID должен как-то генерироваться из MAC-адреса и ещё чего-то там, только все на это нафиг забили. Sapienti sat! |
| 1 2 3 4 5 6 |