|
|
(не показаны 3 промежуточные версии 2 участников) |
Строка 1: |
Строка 1: |
− | | + | #REDIRECT [[SuperGenPass]] |
− | ==Проблема==
| + | |
− | | + | |
− | Все пользователи интернета ежедневно сталкиваются с сервисами, требующими авторизации, скажем даже прямей — среднестатический интернет-пользователь пользуется сотнями и более сайтов-сервисов,
| + | |
− | совершенно разной функциональностью — интернет-магазины, банкинг, рабочая groupware, развлекательные блоги-социальные сети, сайты знакомств, обмен знаниями в форумах и вики-системах…
| + | |
− | | + | |
− | И до сих пор единственным распространенным способом авторизации является предъявление пароля — того, что можно спрятать в голове, то, что всегда с собой.
| + | |
− | | + | |
− | Возникает первая проблема — как выбрать пароль, чтобы он,
| + | |
− | * с одной стороны, укладывался в голове, и мог быть предъявлен по требованию, а не записывался на стикер, хранимый под клавиатурой (блокнот, флешку, внешний сервис хранения паролей — которые не только уязвимы для перехвата, но и могут просто потеряться и стать недоступными),
| + | |
− | * и не подбирался атакой по словарям — с другой.
| + | |
− | Тут конфликт — трудноподбираемые пароли сложно запомнить, а легкозапоминаемые — уязвимы для подбора.
| + | |
− | | + | |
− | Да, многие придумывают свои собственные эвристики для «статистически невычислимых» паролей, используют безумные словосочетания, построенные на личных ассоциативных рядах, комбинируя с отражениями раскладок с русской на английскую, вставку цифр, любимые опечатки и т.п.
| + | |
− | | + | |
− | Но проблема усложняется тем, что нет никакой единой авторизации — каждый интернет-сервис ведет свой собственный учет аккаунтов.
| + | |
− | И в большинстве случаев, они хранят пароли в исходном виде (по крайней мере, невозможно проверить, что это не так), так что доверяя им пароль, нужно быть готовым к тому, что произойдет его утечка<ref>Впрочем, утечка может произойти и не только по их вине — утечка паролей из броузера, вирусы-трояны-кейлоггеры…</ref>.
| + | |
− | | + | |
− | И даже если потеря аккаунта в самом сервисе не видится пользователю проблемой — подумаешь, маловажный интернет-магазин, и полумертвый стартап, проблема будет в том, что грамотный dataminer может легко вычислить («Google-Yandex-Radarix—…») остальные аккаунты пользователя, которых принято привязывать к уникальному нику или emailу, и атаковать их, а это уже и приведет к существенным потерям — денег, репутации, информации или всего вместе взятого.
| + | |
− | | + | |
− | Да, возникают очевидные идеи защиты.
| + | |
− | Например, разделять в интернете общественно-одобряемую деятельность («AlexanderIvanov@mycompany.ru»), от, скажем, ''репутационно-сомнительной'' («BiBigOneMacho@gmail.com»), и от строго секретной (руление деньгами и собственностью).
| + | |
− | Но проблема в том, что таких кластеров не может быть много, ведь голова-то не резиновая, а внутри такого кластера сохраняется уязвимость из-за утечки.
| + | |
− | | + | |
− | Некоторые пытаются строить уникальные пароли, основываясь на URLе интернет-ресурса, добавляя в пароль доменное имя или ''вычислимую от него в уме'' функцию,
| + | |
− | liveinternet.ru -> l10t.ру
| + | |
− | livejournal.com -> kbdt;jehyfk/rjv
| + | |
− | | + | |
− | О легко вычислимой в уме функции, как вы видите, легко догадаться.
| + | |
− | | + | |
− | Но ведь злоумышленник, если пароль не подойдет, сможет использовать полученные данные как наводку для угадывания других паролей, и пароли типа «ливжурналсолнце91» и «яндекссолнце91» прекрасно подскажут ему пароль в Google-сервисах.
| + | |
− | | + | |
− | == Примечания ==
| + | |
− | <references/>
| + | |
− | | + | |
− | | + | |
− | | + | |
− | {{replicate-from-custiswiki-to-lib}}
| + | |