Комментарии 49
Как принято считать, что не бывает одновременно быстро, дешево и качественно, так же и в вышеописанных случаях не может быть одновременно безопасно, удобно и экономично.
На исследование удобных таймингов светофора нужно, как минимум, время, а как максимум, еще и деньги на привлечение сторонних аналитиков, проводящих тесты разных настроек в разное время суток.
На модернизацию инструмента безопасности нужно время. Если инструмент делают на аутсорсе, тоже понадобятся деньги.
На внедрение менеджера паролей тоже потребуется время – пользователей нужно обучать и приучать.
Таким образом, да, бесспорно, можно сделать безопасно и удобно, но это непременно потребует дополнительных затрат. И зачастую ресурсов на покрытие этих затрат у заказчика нет. Дорожникам некогда следить за светофорами на маленьких улочках, им еще новые в эксплуатацию вводить (а обосновать наем новых сотрудников, которые дадут результат, незаметный для человека, не обладающего статистикой, будет довольно трудно). Заборы поставить проще, хотя эффективность их давно под сомнением. С паролями и уязвимостями в коде аналогично: не всякий бизнес может себе позволить вложиться в подобные решения, когда у специалистов и так полно профильных задач. Потому и потери средств мы можем предотвратить, пожертвовав либо временем и/или деньгами, или удобством. Да, в конечном счете при повышении удобства вырастет и безопасность, но все-таки цена вопроса имеет для многих немалое значение.
Я не ханжа и сам, порой, употребляю англицизмы, но вашу мешанину из русского, английского и англицизмов читать невозможно. Пишите на английском.
А заголовок прямо эталон того, как не надо делать: "Почему usability vs security — не трейдофф". Добавьте туда еще "balalaika" для полноты картины.
Мысль о том, что security не сочетается с usability до сих пор приходится слышать довольно часто.
Но ведь это ни разу не миф. Вот только навскидку то, что реализовывал в последнем проекте из того, что пользователю не очень удобно:
— password policy. Мы не разрешаем пользователю задать абсолютно любой пароль. У нас есть определенные требования на минимальный безопасный пароль. Это делает жизнь пользователя чуть менее приятной.
— после пары попыток неверной аутентификации мы начинаем предлагать ему заполнить капчу, чтобы бороться с брутофорсом. Т.е. пользователь итак не может пароль вспомнить, а я ему еще лишнее действие подсовываю.
— при изменении настроек аккаунта (пароль, например) пользователю обязательно шлется письмо на почту, которое ему может засорять и без того занятий почтовый ящик. Часть действий в своем профайле (изменение почты, например) требует обязательного подтверждения того, что пользователю принадлежит текущий привязанный ему почтовый ящик.
— если логин/пароль неверны, то я не сообщаю, есть ли такой логин в системе или нет. Просто говорю, что credentials не подходят. А пользователю, в свою очередь, было бы гораздо удобнее, если бы я ему подсказал, есть ли вообще такой логин в системе или нет.
— я не говорю пользователям, не существует ли определенная страница или просто конкретно у него нет прав на эту страницу. Просто сообщаю, что данной страницы нет.
— и т.д. и т.п.
Все эти действия делают жизнь пользователей чуть менее приятными. Приходится удерживать от них часть информации; давать им больше проверок, когда у них что-то не получается сделать с первых попыток; и т.д.
Да даже в вашем примере с паролем: «Мы предлагаем ему пользоваться менеджером ключей и запомнить один сильный мастер-пароль.» — для многих это уже неудобно. Если пользователь до этого не пользовался менеджером ключей, то он не захочет делать это прямо сейчас и уж тем более не захочет слушать от вас, зачем ему этот самый менеджер ключей позарез понадобился.
И да, конечно, в конкретной ситуации мы можем быть вынуждены делать выбор в пользу безопасности или удобства. Я лишь хотел показать, что это правило неуниверсально и часто есть третий путь. Поэтому чтоб его себе случайно не отсечь, нужно перестать думать в терминах «либо безопасность, либо удобство».
если логин/пароль неверны, то я не сообщаю, есть ли такой логин в системе или нет
В большинстве случаев система предоставляет возможность узнать, какие логины есть в системе, а каких нет. Это и форма регистрации с ошибкой "логин занят", и встроенный в систему поиск других пользователей, и возможность заглянуть в профайл другого юзера просто вписав его в url… Если в Вашей системе тоже есть штатная возможность определить существование логина, то нет смысла гробить юзабилити конкретно в этом месте.
Я знаю, что еще возможно определить, есть ли такой логин по скорости ответа сервера. Если сервер быстрее выдал ошибку о неправильных credentials, то значит такого логина в системе нет. Но чтобы увидеть эту разницу, необходимо несколько десяткой (мб сотен) запросов. Но этот маловероятный вид атаки у нас тоже не пройдет, поскольку после нескольких попыток логина появится обязательная к заполнению капча.
— password policy. Мы не разрешаем пользователю задать абсолютно любой пароль. У нас есть определенные требования на минимальный безопасный пароль. Это делает жизнь пользователя чуть менее приятной.Как для меня, так лучше всего система двойных паролей: пользователь может вбить любой свой, но на почту ему также высылается сложный резервный пароль на случай, если аккаунт «уведут».
Другой вариант — генерировать сложный пароль со стороны сайта и отправлять его на почту. Причем, просить его ввести уже только со второй сессии.
— после пары попыток неверной аутентификации мы начинаем предлагать ему заполнить капчу, чтобы бороться с брутофорсом. Т.е. пользователь итак не может пароль вспомнить, а я ему еще лишнее действие подсовываю.Ага, давайте сразу после первой неверной попытки такое делать, чего-уж там… Мне вообще непонятно, почему количество ошибок, меньшее пяти, вообще кого-то настораживает. Ну и см.п.1.
— при изменении настроек аккаунта (пароль, например) пользователю обязательно шлется письмо на почту, которое ему может засорять и без того занятий почтовый ящик.Скоро е-почта вообще нужна будет только для регистраций. Отсюда идея для старт-апа: почтовый сервис, который выдает для каждой регистрации (на других сайтах) пользователя свой отдельный рандомный под-адрес. В который могут попадать только письма с указанного сайта, остальное в спам.
— если логин/пароль неверны, то я не сообщаю, есть ли такой логин в системе или нет. Просто говорю, что credentials не подходят. А пользователю, в свою очередь, было бы гораздо удобнее, если бы я ему подсказал, есть ли вообще такой логин в системе или нет.Лучше, чтобы сервис автоматически перенаправлял пользователя на его почту (которая и должна вводиться как логин).
Вообще, розовые пони существуют. При условии, что их действительно хотят найти… Ну или, если без эмоций, возможна квази-идеальная система, в которой все неудобства будут восприниматься пользователем как обоснованные, а значит и приемлемые.
пароль со стороны сайта и отправлять его на почту
Если только Вы не шифруете письма PGP, то пожалуйста, никогда-никогда-никогда не отправляйте пароли по email — это слишком открытый канал. Когда мне сайт присылает на почту пароль я всегда реагирую на это матом, потому что приходится тут же идти на этот долбанный сайт, и, матеря его разработчиков, срочно менять пароль на сайте и в keepass.
Скоро е-почта вообще нужна будет только для регистраций.
Вы не поверите, но не все люди переселились в соц.сети, многие продолжают активно использовать email для общения, для получения уведомлений, как таск-трекер, для чтения maillist-ов, etc. Собственно, email продолжает оставаться основным первичным средством связи с любым незнакомым человеком.
идея для старт-апа
Полно такого. Из похожих и популярных — mailinator.com.
Если только Вы не шифруете письма PGP, то пожалуйста, никогда-никогда-никогда не отправляйте пароли по email — это слишком открытый канал. Когда мне сайт присылает на почту пароль я всегда реагирую на это матом, потому что приходится тут же идти на этот долбанный сайт, и, матеря его разработчиков, срочно менять пароль на сайте и в keepass.По-большому счету, воровать пароли вообще мало кому надо — оплата может происходить через специальный сервис. Что там остается воровать — переписку ни о чем? А солидные соц-сети могут и пожестче все обставлять. Так что отправка пароля на почту вполне приемлемый вариант для обычного сайта.
Вы не поверите, но не все люди переселились в соц.сети, многие продолжают активно использовать email для общения, для получения уведомлений, как таск-трекер, для чтения maillist-ов, etc. Собственно, email продолжает оставаться основным первичным средством связи с любым незнакомым человеком.Так я не против, просто предложил подход, как избавиться от влияния спама.
Полно такого. Из похожих и популярных — mailinator.com.Ну, значит и проблемы со спамом нет.
солидные соц-сети
Простите, но это оксюморон во всех контекстах касающихся безопасности и приватности.
Не уверен, что правильно Вас понял. Если взять аналогию, то Вы утверждаете, что выходя из квартиры её не обязательно запирать, потому что очень мало кто ходит каждый день по подъездам в надежде найти незапертую дверь в пустую квартиру?
Почта передаётся по SMTP, т.е. потенциально проходит через несколько (в среднем — 3-5) недоверенных серверов, причём во многих случаях — открытым текстом, без шифрования даже на транспортном уровне (TLS). Это значит, что мест, где желающие могут перехватить пароль — реально много, и рассчитывать что во всех этих местах никто никогда не будет этим заниматься… ну, см. мою аналогию выше.
В нормальных условиях пароль к сайту должен существовать в открытом виде очень короткое время и исключительно в памяти двух компов: несколько миллисекунд при передаче его из менеджера паролей (вроде keepass) в браузер на сайте, и несколько миллисекунд при расчёте хеша от пароля в бэкенде сайта. Перехват его при таком условии на много порядков и сложнее и заметнее, чем при передаче по SMTP (да и не имеет смысла его перехватывать в этих условиях — тут нужен кейлоггер на машине юзера, а тогда у хакера есть доступ сразу ко всем файлам и паролям юзера, т.е. это уже не атака на отдельный пароль).
Второй фактор никоим образом не заменяет пароль, и не отменяет требования к сложности пароля или сохранению паролей в секрете. Поэтому он и называется "второй фактор", а не "решение проблемы неудобных паролей".
Не уверен, что правильно Вас понял. Если взять аналогию, то Вы утверждаете, что выходя из квартиры её не обязательно запирать, потому что очень мало кто ходит каждый день по подъездам в надежде найти незапертую дверь в пустую квартиру?Речь о том, что степень «запирания» квартиры должна зависеть от ее содержимого. Если пароль пользователя это накидной крючок, то сгенерированный пароль это уже полноценный замок, и т.д. Не все сайты нуждются в высочайшем уровне безопасности.
Почта передаётся по SMTP, т.е. потенциально проходит через несколько (в среднем — 3-5) недоверенных серверов....Для какого-нибудь форума-ни-о-чем этого на самом деле вполне достаточно.
В нормальных условиях пароль к сайту должен существовать в открытом виде очень короткое время...Только в тех случаях, когда сайт что-то продает. И то, это можно делать через сторонние сайты (оплата через карту). Что тогда остается злоумышленникам — история покупок?
Чем бОльший ущерб может понести пользователь сайта, тем сложнее должна быть защита паролем.
Видите ли… в теории, если речь о шарообразной лошади в вакууме — Ваш подход вполне имеет право на жизнь. Но на практике есть два момента, которые делают его полностью не жизнеспособным:
- Мы говорим о людях и юзабилити. Необходимость задумываться для каждого отдельного сайта/пароля о том, насколько критичен конкретно этот сайт, и каким из нескольких способов с разной степенью надёжности/безопасности лучше воспользоваться для хранения конкретно этого пароля… скажем очень мягко: не упростит жизнь пользователя. На практике у юзеров есть только два варианта: либо очень простой и одинаковый везде пароль (если юзер считает, что данный сайт ему вообще не важен), либо тот способ работы с паролями, который юзер использует во всех остальных случаях. В любом случае сайт не может знать выбор юзера, а значит и не имеет права навязывать ему сознательно ослабленную безопасность пароля отправляя его по email.
- Очень сложно в момент регистрации на сайте предсказать, какой ущерб может в отдалённом будущем нанести перехват доступа к этому сайту (т.е. получение возможности украсть приватную информацию плюс выполнить какие-то действия от имени чужого аккаунта). Те, кто уже это понял, отказываются от использования простых одинаковых паролей на "неважных" сайтах, и у них остаётся ровно один подход к паролям, одинаковый и для банков и для форумов.
Если регистрация на сайте не требует при этом предоставления конфиденциальной информации, то никаких проблем с утечкой и так видимой всем информации не будет.
А вот уже оценка степени рисков и требуемой безопасности — дело ответственное.
Если регистрация на сайте не требует при этом предоставления конфиденциальной информации, то никаких проблем с утечкой и так видимой всем информации не будет.
Попытался подобрать какой-то способ сказать это мягко, но не смог, поэтому скажу прямо: у процитированной фразы проблемы с логикой, причём довольно серьёзные.
- Нет никакой связи между тем, какая информация требуется при регистрации, и тем, какая информация в принципе доступна под аккаунтом юзера (т.е. какие проблемы может создать утечка).
- И точно так же нет никакой связи между тем, какая информация "видима всем", и тем, какая может утечь при перехвате доступа в аккаунт юзера.
Чтобы сказанное Вами было (почти) корректно нужно допустить, что речь идёт о достаточно необычном сайте: на нём есть регистрация, но при этом абсолютно все (исключая один только пароль) данные о юзере, которые доступны ему самому, так же доступны абсолютно всем другим юзерам. (Я лично таких сайтов не знаю ни одного.)
А "почти" корректно это потому, что помимо утечки данных доступ к чужому аккаунту зачастую так же даёт возможность проявлять на сайте какую-то видимую другим юзерам активность (писать им сообщения, выкладывать статьи, etc.), изменять данные о своём аккаунте (напр. сменить адрес доставки посылок, etc.) а так же удалять данные из своего аккаунта (напр. накапливаемые годами "избранные" статьи) — иными словами ущерб от украденного пароля это далеко не только утечка данных.
Нет никакой связи между тем, какая информация требуется при регистрации, и тем, какая информация в принципе доступна под аккаунтом юзера (т.е. какие проблемы может создать утечка).Ну так я же ниже написал, что это может оценить владелец сайта (исходя из самой его тематики).
И точно так же нет никакой связи между тем, какая информация «видима всем», и тем, какая может утечь при перехвате доступа в аккаунт юзера.Если это блог-ни-о-чем, то зарегистрировавшись под почтой с вымышленным логином, юзер принципиально не «светится». Овчинка выделки не стоит.
Про продающие сайты я тоже написал, что там требования уже выше. Но до последнего шага (например оформления покупки) вполне сойдет и «опасный» пароль от пользователя.
Безопасность должна нарастать пошагово, когда пользователь видит оправданность этого. Тогда явления «неудобства» не возникает.
это может оценить владелец сайта
Не может. Если один юзер в личных сообщениях другому рассказывает про любовницу, или высокие доходы, и к его аккаунту получает доступ жена или мошенник… Да и просто невозможно оценить ущерб от того, что Вам с аккаунта близкого Вам человека напишет какую-то пургу мошенник.
Речь о том, что степень «запирания» квартиры должна зависеть от ее содержимого.
И это теоритические основы секьюрити! О которых к моему частому удивлению осбобенно седобородые ITшникини не особо слышали.
Отличный пример. Тоже когдато строил систему регистрации и логина и вспоминаю те же дискусси.
Некоторы технари-старожилы говорили, что нет никако-го трейдоффа, в их понимании просто безопасность всегда выигрывает в любом подобном трейдоффе естьли он должен существовать.
Что такое безопасность естественно определяли они. Их немного вводил в ступор мой аргумент что пароль в 10 знаков это недостаточно секьюрно и я им приводил какую-то убедительную рекомендацию (с сылками) чуть ли не на 20 заковыристых знаков чтобы потролить их. Некотрые суть троллинга поняли ;)
Попытки разрешить противоречие между безопасностью и удобством с помощью дополнительных инструментов имхо приводит скорее не к поставленной цели, а к возникновению (или усилению) новых, еще не исследованных рисков, которые не заметны на фоне новизны применяемого инструмента.
Так например, FaceID и системы с отпечатком пальца оказываются подвержены подделке с помощью моделирования, менеджер паролей может быть взломан или подменен, а мастер-пароль — забыт или незаметно скомпрометирован, сохраненный локально ключ доступа — украден вирусом, или скачан при временном доступе к физическому хосту со стороны злоумышленника.
Таким образом, кажущаяся удобной защита от одних рисков приводит к возникновению (или усилению) других. Похоже, игра в этом случае таки остается с нулевой суммой, лишь возрастает количество неизвестных.
Мы не предлагаем пользователю запоминать много длинных паролей. Мы предлагаем ему пользоваться менеджером ключей и запомнить один сильный мастер-пароль.
Вот только у нас еще есть требования 2FA. И теперь у нас есть пароль (или, если нам повезло. и нам разрешили, биометрика) и еще второй фактор. И это менее удобно, чем если бы не было ни того, ни другого, а мобильное приложение просто считало бы, что если пользователь безопасно аутентифицирован телефоном, и можно дать весь доступ.
Так что компромис-то никуда не делся, вы просто нашли способ сделать чуть более удобно при очень маленькой потере безопасности. Но сделать еще удобнее, не потеряв в безопасности, вы все равно не сможете.
Менеджер паролей всё ещё и удобнее, и безопаснее, чем запоминание/записывание каждого пароля отдельно.
Но менее удобен, чем не вводить пароля вообще, не правда ли?
И то, что вот он и есть ваш компромис: добавив аутентификацию, мы сделали более безопасно и менее удобно. Соответственно, 2FA (или MFA, не суть) делает еще один шаг по той же дорожке: более безопасно, менее удобно.
Если штрафы поднимут, количество нарушений сократится, и в целом станет чуть безопаснее. Если полицейским (ДПС и аналогам) разрешить ходить в штатском при исполнении и останавливать при этом нарушителей, станет еще безопаснее, и люди будут готовы и по десять минут ждать на светофоре, лишь бы не получить непосильный штраф.
Аналогично и с бизнесом: если сотрудникам в договоре прописать штраф в размере месячной зарплаты за использование слабого пароля и ненадлежащее его хранение, они будут вынуждены применять неудобные методы обеспечения безопасности.
Не стоит недооценивать систему штрафов, она отлично навязывает привычки независимо от того, несут ли они полезную для человека функцию. Добиться приемлемого результата в определенной области таким образом можно. Но тогда возникнут проблемы другого характера, например, текучка кадров, особенно, невысокой квалификации или разного рода «итальянские забастовки». Локальная цель выполнена, безопасность возросла. Глобальная цель отдалилась – бизнес начинает тормозить. К сожалению, до сих пор много руководителей, особенно, низшего звена, которые не осознают подобные риски.
PS: А ещё есть отдельная группа менеджеров, которые навязывают небезопасные и неудобные решения, но это уже совсем грустный вариант.
Аналогично и с бизнесом: если сотрудникам в договоре прописать штраф в размере месячной зарплаты за использование слабого пароля и ненадлежащее его хранение, они будут вынуждены применять неудобные методы обеспечения безопасности
Имхо, при этом надо ещё и честно штрафовать за нарушение. Иначе может получится весёлая ситуация: во внутреннем чата одной большой компании (информация из этого чата уже утекла, что забавно) пишут всем, что нельзя использовать Google Docs с доступом по ссылке, это считается нарушением их NDA, за это наказание вплоть до увольнения. Так пишут пару раз, никого не уволили, в итоге половина файлов этой компании все ещё доступна по ссылке, а в чате сидят левые люди.
Нужен и пряник, и кнут, но кнут ещё и бить должен, если есть необходимость.
Тема поста на русском: не требуется компромисс между безопасностью и удобством.
Но вам привели кучу примеров, в том числе по вашим кейсам, демонстрирующих, что компромисс никуда не делся. Вы можете сделать удобнее и безопаснее за счёт дополнительных затрат, но исходное противоречие никуда не исчезает => выбор между безопаснстью и удобством по-прежнему на месте
С автором согласен на 100%. Даже скажу еще – некоторые разработчики идут дальше и путают неудобство с безопасностью. То есть, думают, что если сделают просто неудобно, то безопасность повыситься сама собой.
Например, многие думают что ограничения пароля (т.н. password policy) увеличивает безопасность. Но это совершенно не так! Всякое ограничение состава пароля, только уменьшает безопасность. Оно просто неудобно и поэтому выглядит безопасней.
А потребители, конечно очень быстро придумывают словарьные пароли, которые отвечают всем требованиям.
То же самое с листочкам. По сути, записать сложный пароль на бумаге не так уж и плохо. Плохо, если люди не ценят этого листочка и вешают его на мониторе. А так, люди довольно хороши в сохранении бумажных листочках в тайне. Если видят в этом смысл.
Например, многие думают что ограничения пароля (т.н. password policy) увеличивает безопасность. Но это совершенно не так! Всякое ограничение состава пароля, только уменьшает безопасность. Оно просто неудобно и поэтому выглядит безопасней.
А потребители, конечно очень быстро придумывают словарьные пароли, которые отвечают всем требованиям.
Минимум 8 символов, один символ в верхнем регистре, одна цифра, один спецсимвол, первые и последние 2 значения только символы в нижнем регистре
А теперь давай, придумай словарный пароль, который соотвествует этому требованию и я лайкну тебя.
Сколько раз за всю жизнь взламывали ваши аккаунты? У меня за 40+ лет ни разу.
Поэтому лично я не стану пользоваться безопасным, но неудобным приложением, даже если в нем соблюден компромисс между этими двумя сущностями.
Единственное, что может меня привлечь, это предусмотренная разработчиком опция: «Вам как, побезопаснее, или поудобнее?» Вот тогда да, выберу последнее, и буду пользоваться.
Зря вас заминусовали за это не совсем популярное мение в "профессиональном" комьюнити. Вы просто озвучили мысли многих пользоватеей и подчеркнули аргумент за юзабилити...
Компромисс безопасность/удобство, по сути ложный компромисс. Потому что, увеличить удобство, можно многими путями. И повысить безопасность тоже можно по разному.
И вот, если разработчик выберет тот способ повышения безопасности, который уменьшает удобство, то это компромисс. Но ведь, можно выбрать и способ, который не уменьшает удобство. Тогда и компромисса не будет.
Выходит, что все в руках разработчика. Если он убежден, что высокая безопасность всегда неудобна, то так и будет. А если думает головой и выбирает правильные способы повышения безопасности, то удобство никак не пострадает.
К тому же, неудобная система сама по себе менее безопасна, потому что потребитель активно сопротивляется, а он умный. Пример обсудили наверх – ограничения на пароль – пользы ноль, а удобство пострадало, потребитель недоволен. Но правда, выглядит «безопасно». Только выглядит.
Почему удобство vs безопасность — не трейдофф