Интернет для чайников
Юмор
DNS. Чтобы узнать, где колодец в деревне Гадюкино, ты сначала идешь к президенту, потом к губернатору и т. д.
Динамический IP. Каждое утро все меняются паспортами.
Сжатие. У тебя отрезают левую руку на входе, а на выходе — пришивают клонированную правую (и зеркально повернутую, разумеется). То же с ногами и вообще со всем, что имеет регулярную структуру.
Коррекция ошибок. К спине пришивают твою же фотографию. Если на выходе ты не похож — корректируют лицо.
Время жизни пакета. Все премещения по коридору — пока горит спичка. Не успел — умри героем.
Текст-ориентированный протокол. Вместо тебя отправляют твой словесный портрет.
MIME-код. Справка, что ты не верблюд.
Уровни протоколов. Чистое поле. Нужно перейти от одного края к другому. Строится огромная арка, внутри арки мостовая, посреди мостовой кладут ж/д полотно, к рельсам приваривают сваи и на них ставят огромную гранитную глыбу с туннелем внутри, в туннеле прокладывают трубу диаметром полметра, по которой ты и ползешь пока горит спичка к президенту (сжатый и с коррекцией ошибок).
За время моей работы на текущей должности у меня накопилось к вам несколько просьб, которые я рискнул опубликовать прямо здесь. Не сочтите за труд ознакомиться с ними. Я буду искренне счастлив обсудить их с вами, если это необходимо. Заранее спасибо, искренне ваш, бла-бла-бла и все такое.
Собственно, просьбы:
Безусловно отличной идеей является хранение паролей пользователей на сервере в открытом виде. Ведь это так здорово: в ответе на запрос о восстановлении доступа, прислать пользователю его старый пароль, не заставляя его использовать временный и не обременяя его задачей придумывания нового постоянного. Да и целую форму с обработчиком сэкономите!
Если вы все же решились на столь смелый поступок и таки планируете хранить в базе хэши паролей — забудьте о стандартных функциях хэширования! Вы вообще — программист или где? А известная только вам функция хэширования только добавит защищенности к вашей системе.
Если никакой придурок не озадачил вас в ТЗ необходимостью реализации периодической принудительной смены пароля, то возможность его изменения надо запретить вовсе. Ибо нефиг давать пользователям волю менять пароли по десять раз на дню, расходуя при этом драгоценные ресурсы ваших серверов. И опять-таки: на целой одной форме и ее обработчике можно сэкономить.
Если же такой придурок таки нашелся, не отчаивайтесь! Вы можете существенно облегчить жизнь пользователям, если разрешите им менять свой пароль на точно такой же, или использованный в прошлый раз. Мелочь, а того придурка на место поставите.
И вообще, запомните: идиота, выставляющего какие-либо требования к парольной защите вы просто обязаны обмануть по полной программе! Ведь именно из-за него у вас вообще возникла необходимость в этой самой парольной защите!
Разумеется, ваши сервера не халявная рапидшара и нечего позволять пользователям засорять место на жестких дисках своими ублюдскими 20-символьными паролями. 8 символов хватит всем! Это в конце 90-ых всем доступно объяснил Microsoft, если кто не помнит.
И вообще, в задницу все ограничения на сложность паролей! Ваши пользователи — свободные люди, и было бы жесточайшим ущемлением их прав навязывать им необходимость использования каких-либо групп символов в обязаловку. И если убежденный расист хочет иметь пароль "fuckingniggas", то кто вы такой, чтобы запрещать ему это?!
Но если вдруг вы реализуете какие-либо ограничения, то ни в коем случае ни раскрывайте их пользователю заранее и одной пачкой! Выдавайте информацию постепенно. Во-первых, в этом случае злой хакерюга не сможет сразу понять вашу парольную политику и оставит попытки получить доступ, а во-вторых, нет ничего забавнее, чем потом наблюдать в логах, как пользователь трахался, пытаясь понять: какие еще ограничения он не учел?
Да-да, обязательно отражайте в логах все вводимые пароли. Потом, если внезапно рухнет база, ее можно будет легко по ним восстановить.
Ни в коем разе не используйте идентификаторы сессий! Вы сами-то хоть подумали, сколько кода вам придется для этого написать? Да и аутентифицироваться заново на каждую операцию безопаснее. А серверы выдержат, мы же в п.3 их мощность сэкономили.
Додумавшись до идентификаторов сессий (вам заняться больше нечем?) не изобретайте велосипед, вам и так есть где развернуть свою фантазию при реализации функции хэширования. Используйте в качестве идентификаторов GUID, или (вот это вообще будет бомба!) случайное двухзначное число, равное количеству секунд в момент входа в систему.
Двухфакторная аутентификация с отправкой сессионного пароля в SMS-сообщении снимает ровным счетом все угрозы, связанные с несанкционированным доступом. Плюньте в глаз тому, кто будет утверждать обратное. Кстати, в этом случае будет очень удобно использовать мобильный телефон пользователя для восстановления его основного пароля.
Обязательно блокируйте запись пользователя после 5-10 неудачных попыток входа. Ведь потом будет так весело наблюдать за впахивающим саппортом, отбивающимся от запросов на разблокировку всей пользовательской базы разом.
Капча — зло. Пользователя нельзя обижать подозрениями в том, что он робот, и заставлять вводить скукоженные символы. Если уж пришлось, то скукоживайте их без фанатизма, чтобы пользователь мог не напрягаясь испытать радость от того, что он не робот. Да и вообще — используйте легкоугадываемый алгоритм выбора символов для капчи. Тогда постоянные пользователи смогут вводить ее, даже не глядя на экран.
И никогда, ни под каким предлогом, не передавайте аутентификационные данные по защищенному каналу: затрахаетесь потом это отлаживать.
P.S: Уважаемые разработчики, убедительно прошу вас рассмотреть мои просьбы и, по возможности, следовать им. А то работы у меня совсем не останется.
14.06.2011, 19:08
Типа, чисто поржать
Линейный вид
