Уважаемые сабжы!
За время моей работы на текущей должности, у меня накопилось к вам несколько просьб, которые я рискнул опубликовать прямо здесь. Не сочтите за труд ознакомиться с ними. Я буду искренне счастлив обсудить их с вами, если это необходимо. Заранее спасибо, искренне ваш, бла-бла-бла и все такое.
Собственно, просьбы:
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