Заметки о безопасности. Восстановление пароля

[azverin]

Получается, что большинство описанных уязвимостей используют неограниченное количество попыток действий, связанных с безопасностью.
Т.е. общий орг.вывод: не давать делать много раз то, что нужно делать мало раз + ограничивать скорость действий (капча или задержка по времени).

[YUVladimir]

Скорее нужна капча И задержка по времени. Т.к. большинство капч разгадываются автоматически с весьма большой точностью.

[L3n1n]

С смс были аналогичные грабли с подписками и рассылками.
Под утро был чуть удивлен счетом за смс в ХХк рублей.

[Iskin]

Я считаю, что большая часть сайтов должны использовать авторизацию по OAuth или OpenID. Тогда и не надо задумываться о куче вопросов безопасности и юзабилити.

[Disasm]

Это лишь перекладывание вопросов безопасности на плечи другого сайта.

[Iskin]

Полностью согласен — легче один раз подумать вопросы безопасности на паре крупных ресурсов, которые могут себе позволить нормальных специалистов по безопасности, чем каждый раз делать новую систему авторизации, а потом поддерживать кучу старых проектов.

[Disasm]

С точки зрения пользователя это «о, здесь можно авторизоваться через вконташечку», через пару дней пароль от вконташечки уводят вместе с аккаунтом на вашем сайте. Удобно — да, безопасно — вряд ли.

[Iskin]

У ВК есть хорошая система восстановления пароля по СМС.

Я могу вам привести интересный пример. Чтобы не помнить кучу паролей, большинство пользователей использует один на все сайты.Так что можно взломать аккаунд пользователя на мелком сайте и узнать пароль на ваш крупный сайт.

Из-за отсутствия удобства реальная безопасность паролей очень низка.

[Disasm]

Тут вопрос не в том, как увести аккаунт на другом сайте, а в том, что это приведёт к автоматическому получению доступа к сайту с подобным механизмом авторизации. Да, когда пароли везде одинаковые, то разницы никакой. Но если пароли разные, то подобная авторизация уступает традиционным методам в плане безопасности.

[Iskin]

Если пароли одинаковы, то разница как раз есть большая — ваш общий пароль будет открыто передаваться без HTTPS, храниться открыто в базе мелких сайтов и т. п. — и безопасность будет гораздо ниже.

[Iskin]

Я вот только не понял, как могут увести ВК, но не аккаунт на сайте. Сомневаюсь, что в Рунете много сайтов, которые заботятся о безопасности больше, чем Гугль, ВК, Яндекс или Фейсбук.

[dxRang]

вот наглядный пример того, чем открытая авторизация может обренуться для пользователя.

к тому же, ОА ограничивает функционал: нет возможности изменить отображаемое имя для конкретного ресурса, аватар и т.д… не говоря уже о случаях, когда нет желания выставлять на показ свои личные данные ради комментария на каком-нибудь мелком сайте.

[Iskin]

У OpenID было хорошее решение этой проблемы — свой домен, который привязан к сменяемым провайдерам.

[zorgrhrd]

А разве обязательно отвечать на вопрос «Кличка вашего домашнего питомца», кличкой вашего домашнего питомца? По-моему это элементарная проблема безопасности при соц. инженерии, поэтому я не отвечаю на вопрос, а пишу не связанное с ним слово, иначе любой мой сосед сможет сбросить мой пароль.

[InteractiveTechnology]

Конечно, желательно так и делать, но есть простое человеческое незнание всего этого, а ещё чаще мнение кому я нужен.

[Nashev]

Честно говоря, эти контрольные вопросы — на фоне существования социальной инженерии — открытая дыра в безопасности. Какой идиот их вообще придумал, и зачем многие сервисы на них повелись? Поубивал бы!.. :(

[a97]

Ага, и через четыре года начинаешь вспоминать, какую несвязанную фигню ты вколотил при регистрации.
Ответ на вопрос должен быть твоей ассоциацией, причем достаточно устойчивой.
— Гадость?
— Ваша рыба!

[zorgrhrd]

И пароли везде разные и все трудно запомнить. Слово несвязное, но это не набор символов, за много лет практики проблем не было.

[mrded]

Ребята из qip.ru с легкостью восстанавливают пароли от моих ящиков для неизвестных мне людей.
Пожалуй это было единственной причиной перестать ими пользоваться.

[bask]

Через несколько минут был получен готовый инструмент для тестирования, который принимал логин пользователя, посылал запрос на восстановление пароля и за считанные секунды в десяток потоков подбирал этот уникальный хеш, после чего через форму по уникальной ссылке ставил свой пароль 12345

Зачем такие сложности для такого простого случая? Уже есть просчитанные таблицы хэшей до 7-9 символов (иногда достаточно просто вбить в гугл хэш от этой строки). И не нужно никаких многопоточных подборщиков.

[InteractiveTechnology]

Я согласен, можно взять готовые хеши, но ведь это задачка реально на пару минут. Какая разница тратить их на поиск базы или на пару строк кода. Тем более всё равно в итоге нужно кодить, чтобы он эти хеши проверял.
К тому же генерация хеша перед отсылкой запросов на скорость никак не повлияет.