Почему удобство vs безопасность — не трейдофф

    Я с 2014 года работаю над безопасностью мобильных и веб-приложений. Много раз слышал от разных людей и в разном контексте про «трейдофф usability vs security», при этом с самого начала видел в этом какой-то подвох. В этом посте я поделюсь своим мнением, почему, на мой взгляд, это не трейдофф, и на самом деле от него давно стоит отказаться.

    image

    Что это такое


    Под трейдоффом usability vs security как правило подразумевается следующая закономерность: чем безопаснее процесс, тем он неудобнее.

    image

    Поясню на простых примерах, что имеется в виду:

    • Пароль qwerty — удобно, небезопасно. Длинный пароль с символами разного регистра — безопасно, неудобно.
    • Запускать код сразу в продакшн — удобно, небезопасно. Проверять его инструментами безопасности и проводить аудит — безопасно, неудобно.
    • Переходить улицу, когда захочется — удобно, небезопасно. Переходить улицу на зелёный — безопасно, неудобно.
    • Как видите, речь может идти не только о софте, а под «удобством» могут скрываться разные параметры. Тем не менее, закономерность налицо.

    Что может пойти не так


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

    image

    • Длинный пароль с символами разного регистра запомнить сложно, поэтому он один на все аккаунты в соцсетях и интернет-магазины. Кто-то из них точно хранит пароли в plain text и либо потеряет их, либо продаст. В том числе, напомню, наш пароль от всего.
    • Департамент ИБ обязал разработчиков прогонять код инструментом проверки безопасности. Но инструмент каждый раз выдаёт кучу уязвимостей, непонятно, где старые, где новые. В итоге их никто не исправляет.
    • Светофор настроен неправильно, очень долго ждать зелёный, при этом машин нет, и люди решили переходить на красный.

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

    Что делать


    В первую очередь нужно повернуться к лесу задом, а к пользователю передом. Странно даже предлагать юзеру «безопасный, неудобный» процесс, ведь наша работа и заключается в том, чтоб организовать удобный. Давайте откажемся от мысли, что для получения security нужно пожертвовать usability, и попытаемся совместить их в одном решении.

    image

    Наши примеры тогда приобретут следующий вид:

    • Мы не предлагаем пользователю запоминать много длинных паролей. Мы предлагаем ему пользоваться менеджером ключей и запомнить один сильный мастер-пароль. В идеале менеджер ключей должен быть встроен в браузер, чтобы не приходилось каждый раз копипастить.
    • Инструмент безопасности следит, какая уязвимость старая, а какая новая, и отображает их отдельно. Пользователь видит историю работы с этой уязвимостью и понимает контекст. Работать стало проще, уязвимости устраняются.
    • Время светофора рассчитано с учётом потока машин и людей, никому не приходится долго ждать.

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

    Правильный майндсет


    Мысль о том, что security не сочетается с usability до сих пор приходится слышать довольно часто. Некоторые идут дальше и делают утверждение, что по-настоящему безопасный процесс всегда будет неудобен, а значит, доступен только специалистам. Мне такой подход кажется в корне неверным.

    Безопасность — это масс-маркет. Нельзя быть уверенным в безопасности своих соцсетей, если у ваших друзей пароль qwerty: злоумышленник напишет вам от их имени, и в опасности будут уже ваши средства. Соответственно, и безопасные способы хранения паролей (как и решения других задач) должны быть доступны среднему пользователю.

    Постепенно на мобильные и веб-приложения ложится всё больше ответственности: у всех в смартфонах банковские приложения, а у кого-то и криптокошельки. Мы можем предотвратить дурацкие и обидные потери средств, только если изначально будем думать о безопасности и удобстве как вещах взаимодополняющих. Неудобный процесс не может быть безопасен, потому что пользователь не будет ему следовать.

    Автор: Иван Иваницкий, ведущий аналитик Solar appScreener
    Ростелеком-Солар
    Безопасность по имени Солнце

    Комментарии 49

      +3
      Предположу, что рассматривать безопасность/удобство следует в контексте третьего фактора – затратность.

      Как принято считать, что не бывает одновременно быстро, дешево и качественно, так же и в вышеописанных случаях не может быть одновременно безопасно, удобно и экономично.
      На исследование удобных таймингов светофора нужно, как минимум, время, а как максимум, еще и деньги на привлечение сторонних аналитиков, проводящих тесты разных настроек в разное время суток.
      На модернизацию инструмента безопасности нужно время. Если инструмент делают на аутсорсе, тоже понадобятся деньги.
      На внедрение менеджера паролей тоже потребуется время – пользователей нужно обучать и приучать.

      Таким образом, да, бесспорно, можно сделать безопасно и удобно, но это непременно потребует дополнительных затрат. И зачастую ресурсов на покрытие этих затрат у заказчика нет. Дорожникам некогда следить за светофорами на маленьких улочках, им еще новые в эксплуатацию вводить (а обосновать наем новых сотрудников, которые дадут результат, незаметный для человека, не обладающего статистикой, будет довольно трудно). Заборы поставить проще, хотя эффективность их давно под сомнением. С паролями и уязвимостями в коде аналогично: не всякий бизнес может себе позволить вложиться в подобные решения, когда у специалистов и так полно профильных задач. Потому и потери средств мы можем предотвратить, пожертвовав либо временем и/или деньгами, или удобством. Да, в конечном счете при повышении удобства вырастет и безопасность, но все-таки цена вопроса имеет для многих немалое значение.
        0
        Всё так, чтоб сделать и безопасно, и удобно, нужны дополнительные ресурсы. И в случае, если их нет, то объединить удобство и безопасность не получится. Но вот если они есть, то в этом случае важно не упираться в стереотип «безопасность и удобство не совместыми», а обеспечить и то, и другое.
        +1

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


        А заголовок прямо эталон того, как не надо делать: "Почему usability vs security — не трейдофф". Добавьте туда еще "balalaika" для полноты картины.

          0
          Спасибо за обратную связь. Действительно, переборщили видимо. Исправимся
          +2
          Мысль о том, что security не сочетается с usability до сих пор приходится слышать довольно часто.


          Но ведь это ни разу не миф. Вот только навскидку то, что реализовывал в последнем проекте из того, что пользователю не очень удобно:
          — password policy. Мы не разрешаем пользователю задать абсолютно любой пароль. У нас есть определенные требования на минимальный безопасный пароль. Это делает жизнь пользователя чуть менее приятной.
          — после пары попыток неверной аутентификации мы начинаем предлагать ему заполнить капчу, чтобы бороться с брутофорсом. Т.е. пользователь итак не может пароль вспомнить, а я ему еще лишнее действие подсовываю.
          — при изменении настроек аккаунта (пароль, например) пользователю обязательно шлется письмо на почту, которое ему может засорять и без того занятий почтовый ящик. Часть действий в своем профайле (изменение почты, например) требует обязательного подтверждения того, что пользователю принадлежит текущий привязанный ему почтовый ящик.
          — если логин/пароль неверны, то я не сообщаю, есть ли такой логин в системе или нет. Просто говорю, что credentials не подходят. А пользователю, в свою очередь, было бы гораздо удобнее, если бы я ему подсказал, есть ли вообще такой логин в системе или нет.
          — я не говорю пользователям, не существует ли определенная страница или просто конкретно у него нет прав на эту страницу. Просто сообщаю, что данной страницы нет.
          — и т.д. и т.п.

          Все эти действия делают жизнь пользователей чуть менее приятными. Приходится удерживать от них часть информации; давать им больше проверок, когда у них что-то не получается сделать с первых попыток; и т.д.

          Да даже в вашем примере с паролем: «Мы предлагаем ему пользоваться менеджером ключей и запомнить один сильный мастер-пароль.» — для многих это уже неудобно. Если пользователь до этого не пользовался менеджером ключей, то он не захочет делать это прямо сейчас и уж тем более не захочет слушать от вас, зачем ему этот самый менеджер ключей позарез понадобился.
            0
            Ну вот менеджер паролей, встроенный в браузер, который сам предлагает безопасный пароль и сам предлагает его сохранить — хороший пример решения, объединяющего безопасность и удобство. Конечно, у любого инструмента есть порог входа, время, которое нужно потратить на его освоение. Но вряд ли кто-то станет спорить, что удобнее запоминать N паролей, чем получать их автозаполнением от браузера; что удобнее рвать бумагу руками, чем не резать ножницами.

            И да, конечно, в конкретной ситуации мы можем быть вынуждены делать выбор в пользу безопасности или удобства. Я лишь хотел показать, что это правило неуниверсально и часто есть третий путь. Поэтому чтоб его себе случайно не отсечь, нужно перестать думать в терминах «либо безопасность, либо удобство».
              0
              И да, конечно, в конкретной ситуации мы можем быть вынуждены делать выбор в пользу безопасности или удобства.

              Ок, года о чем статья? Этот Трейдофф не миф и постоянно присутсвует.
              [Я понимаю что вы не автор, мой коммент не конкретно вам ;) ]

              +4
              если логин/пароль неверны, то я не сообщаю, есть ли такой логин в системе или нет

              В большинстве случаев система предоставляет возможность узнать, какие логины есть в системе, а каких нет. Это и форма регистрации с ошибкой "логин занят", и встроенный в систему поиск других пользователей, и возможность заглянуть в профайл другого юзера просто вписав его в url… Если в Вашей системе тоже есть штатная возможность определить существование логина, то нет смысла гробить юзабилити конкретно в этом месте.

                0
                Конкретно в этом проекте — нет никакой возможности определить, что логины в системе есть. Восстановление пароля и регистрация молча принимают ваши данные и высылают письмо, которое разнится в зависимости от того, есть ли такой логин уже в системе ли нет.

                Я знаю, что еще возможно определить, есть ли такой логин по скорости ответа сервера. Если сервер быстрее выдал ошибку о неправильных credentials, то значит такого логина в системе нет. Но чтобы увидеть эту разницу, необходимо несколько десяткой (мб сотен) запросов. Но этот маловероятный вид атаки у нас тоже не пройдет, поскольку после нескольких попыток логина появится обязательная к заполнению капча.
                0
                — password policy. Мы не разрешаем пользователю задать абсолютно любой пароль. У нас есть определенные требования на минимальный безопасный пароль. Это делает жизнь пользователя чуть менее приятной.
                Как для меня, так лучше всего система двойных паролей: пользователь может вбить любой свой, но на почту ему также высылается сложный резервный пароль на случай, если аккаунт «уведут».
                Другой вариант — генерировать сложный пароль со стороны сайта и отправлять его на почту. Причем, просить его ввести уже только со второй сессии.

                — после пары попыток неверной аутентификации мы начинаем предлагать ему заполнить капчу, чтобы бороться с брутофорсом. Т.е. пользователь итак не может пароль вспомнить, а я ему еще лишнее действие подсовываю.
                Ага, давайте сразу после первой неверной попытки такое делать, чего-уж там… Мне вообще непонятно, почему количество ошибок, меньшее пяти, вообще кого-то настораживает. Ну и см.п.1.

                — при изменении настроек аккаунта (пароль, например) пользователю обязательно шлется письмо на почту, которое ему может засорять и без того занятий почтовый ящик.
                Скоро е-почта вообще нужна будет только для регистраций. Отсюда идея для старт-апа: почтовый сервис, который выдает для каждой регистрации (на других сайтах) пользователя свой отдельный рандомный под-адрес. В который могут попадать только письма с указанного сайта, остальное в спам.

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

                Вообще, розовые пони существуют. При условии, что их действительно хотят найти… Ну или, если без эмоций, возможна квази-идеальная система, в которой все неудобства будут восприниматься пользователем как обоснованные, а значит и приемлемые.
                  +2
                  пароль со стороны сайта и отправлять его на почту

                  Если только Вы не шифруете письма PGP, то пожалуйста, никогда-никогда-никогда не отправляйте пароли по email — это слишком открытый канал. Когда мне сайт присылает на почту пароль я всегда реагирую на это матом, потому что приходится тут же идти на этот долбанный сайт, и, матеря его разработчиков, срочно менять пароль на сайте и в keepass.


                  Скоро е-почта вообще нужна будет только для регистраций.

                  Вы не поверите, но не все люди переселились в соц.сети, многие продолжают активно использовать email для общения, для получения уведомлений, как таск-трекер, для чтения maillist-ов, etc. Собственно, email продолжает оставаться основным первичным средством связи с любым незнакомым человеком.


                  идея для старт-апа

                  Полно такого. Из похожих и популярных — mailinator.com.

                    –2
                    Если только Вы не шифруете письма PGP, то пожалуйста, никогда-никогда-никогда не отправляйте пароли по email — это слишком открытый канал. Когда мне сайт присылает на почту пароль я всегда реагирую на это матом, потому что приходится тут же идти на этот долбанный сайт, и, матеря его разработчиков, срочно менять пароль на сайте и в keepass.
                    По-большому счету, воровать пароли вообще мало кому надо — оплата может происходить через специальный сервис. Что там остается воровать — переписку ни о чем? А солидные соц-сети могут и пожестче все обставлять. Так что отправка пароля на почту вполне приемлемый вариант для обычного сайта.

                    Вы не поверите, но не все люди переселились в соц.сети, многие продолжают активно использовать email для общения, для получения уведомлений, как таск-трекер, для чтения maillist-ов, etc. Собственно, email продолжает оставаться основным первичным средством связи с любым незнакомым человеком.
                    Так я не против, просто предложил подход, как избавиться от влияния спама.

                    Полно такого. Из похожих и популярных — mailinator.com.
                    Ну, значит и проблемы со спамом нет.
                      0
                      солидные соц-сети

                      Простите, но это оксюморон во всех контекстах касающихся безопасности и приватности.

                        0
                        Моя ремарка была про то, что ситуаций, когда отправлять пароль на почту небезопасно с точки зрения выгодополучения для мошенников, очень мало. Остальные случаи решаются или сторонними сервисами (оплата) или (в случае соц-сетей) привязкой номера телефона и/или двухфакторной аутентификацией.
                          0

                          Не уверен, что правильно Вас понял. Если взять аналогию, то Вы утверждаете, что выходя из квартиры её не обязательно запирать, потому что очень мало кто ходит каждый день по подъездам в надежде найти незапертую дверь в пустую квартиру?


                          Почта передаётся по SMTP, т.е. потенциально проходит через несколько (в среднем — 3-5) недоверенных серверов, причём во многих случаях — открытым текстом, без шифрования даже на транспортном уровне (TLS). Это значит, что мест, где желающие могут перехватить пароль — реально много, и рассчитывать что во всех этих местах никто никогда не будет этим заниматься… ну, см. мою аналогию выше.


                          В нормальных условиях пароль к сайту должен существовать в открытом виде очень короткое время и исключительно в памяти двух компов: несколько миллисекунд при передаче его из менеджера паролей (вроде keepass) в браузер на сайте, и несколько миллисекунд при расчёте хеша от пароля в бэкенде сайта. Перехват его при таком условии на много порядков и сложнее и заметнее, чем при передаче по SMTP (да и не имеет смысла его перехватывать в этих условиях — тут нужен кейлоггер на машине юзера, а тогда у хакера есть доступ сразу ко всем файлам и паролям юзера, т.е. это уже не атака на отдельный пароль).


                          Второй фактор никоим образом не заменяет пароль, и не отменяет требования к сложности пароля или сохранению паролей в секрете. Поэтому он и называется "второй фактор", а не "решение проблемы неудобных паролей".

                            0
                            Не уверен, что правильно Вас понял. Если взять аналогию, то Вы утверждаете, что выходя из квартиры её не обязательно запирать, потому что очень мало кто ходит каждый день по подъездам в надежде найти незапертую дверь в пустую квартиру?
                            Речь о том, что степень «запирания» квартиры должна зависеть от ее содержимого. Если пароль пользователя это накидной крючок, то сгенерированный пароль это уже полноценный замок, и т.д. Не все сайты нуждются в высочайшем уровне безопасности.

                            Почта передаётся по SMTP, т.е. потенциально проходит через несколько (в среднем — 3-5) недоверенных серверов....
                            Для какого-нибудь форума-ни-о-чем этого на самом деле вполне достаточно.

                            В нормальных условиях пароль к сайту должен существовать в открытом виде очень короткое время...
                            Только в тех случаях, когда сайт что-то продает. И то, это можно делать через сторонние сайты (оплата через карту). Что тогда остается злоумышленникам — история покупок?

                            Чем бОльший ущерб может понести пользователь сайта, тем сложнее должна быть защита паролем.
                              +1

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


                              • Мы говорим о людях и юзабилити. Необходимость задумываться для каждого отдельного сайта/пароля о том, насколько критичен конкретно этот сайт, и каким из нескольких способов с разной степенью надёжности/безопасности лучше воспользоваться для хранения конкретно этого пароля… скажем очень мягко: не упростит жизнь пользователя. На практике у юзеров есть только два варианта: либо очень простой и одинаковый везде пароль (если юзер считает, что данный сайт ему вообще не важен), либо тот способ работы с паролями, который юзер использует во всех остальных случаях. В любом случае сайт не может знать выбор юзера, а значит и не имеет права навязывать ему сознательно ослабленную безопасность пароля отправляя его по email.
                              • Очень сложно в момент регистрации на сайте предсказать, какой ущерб может в отдалённом будущем нанести перехват доступа к этому сайту (т.е. получение возможности украсть приватную информацию плюс выполнить какие-то действия от имени чужого аккаунта). Те, кто уже это понял, отказываются от использования простых одинаковых паролей на "неважных" сайтах, и у них остаётся ровно один подход к паролям, одинаковый и для банков и для форумов.
                                –1
                                Сайт должен сам за юзера решать, какой уровень безопасности ему надо предлагать.
                                Если регистрация на сайте не требует при этом предоставления конфиденциальной информации, то никаких проблем с утечкой и так видимой всем информации не будет.
                                А вот уже оценка степени рисков и требуемой безопасности — дело ответственное.
                                  +1
                                  Если регистрация на сайте не требует при этом предоставления конфиденциальной информации, то никаких проблем с утечкой и так видимой всем информации не будет.

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


                                  • Нет никакой связи между тем, какая информация требуется при регистрации, и тем, какая информация в принципе доступна под аккаунтом юзера (т.е. какие проблемы может создать утечка).
                                  • И точно так же нет никакой связи между тем, какая информация "видима всем", и тем, какая может утечь при перехвате доступа в аккаунт юзера.

                                  Чтобы сказанное Вами было (почти) корректно нужно допустить, что речь идёт о достаточно необычном сайте: на нём есть регистрация, но при этом абсолютно все (исключая один только пароль) данные о юзере, которые доступны ему самому, так же доступны абсолютно всем другим юзерам. (Я лично таких сайтов не знаю ни одного.)


                                  А "почти" корректно это потому, что помимо утечки данных доступ к чужому аккаунту зачастую так же даёт возможность проявлять на сайте какую-то видимую другим юзерам активность (писать им сообщения, выкладывать статьи, etc.), изменять данные о своём аккаунте (напр. сменить адрес доставки посылок, etc.) а так же удалять данные из своего аккаунта (напр. накапливаемые годами "избранные" статьи) — иными словами ущерб от украденного пароля это далеко не только утечка данных.

                                    0
                                    Нет никакой связи между тем, какая информация требуется при регистрации, и тем, какая информация в принципе доступна под аккаунтом юзера (т.е. какие проблемы может создать утечка).
                                    Ну так я же ниже написал, что это может оценить владелец сайта (исходя из самой его тематики).

                                    И точно так же нет никакой связи между тем, какая информация «видима всем», и тем, какая может утечь при перехвате доступа в аккаунт юзера.
                                    Если это блог-ни-о-чем, то зарегистрировавшись под почтой с вымышленным логином, юзер принципиально не «светится». Овчинка выделки не стоит.

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

                                    Безопасность должна нарастать пошагово, когда пользователь видит оправданность этого. Тогда явления «неудобства» не возникает.
                                      +1
                                      это может оценить владелец сайта

                                      Не может. Если один юзер в личных сообщениях другому рассказывает про любовницу, или высокие доходы, и к его аккаунту получает доступ жена или мошенник… Да и просто невозможно оценить ущерб от того, что Вам с аккаунта близкого Вам человека напишет какую-то пургу мошенник.

                                        –2
                                        Так владелец сайта должен понимать о чем речь идет — о соцсетях с реальными людьми или о анонимных аккаунтах на форуме-ни-о-чем. Я что-то устал эту мысль доносить.
                                0
                                Речь о том, что степень «запирания» квартиры должна зависеть от ее содержимого.

                                И это теоритические основы секьюрити! О которых к моему частому удивлению осбобенно седобородые ITшникини не особо слышали.

                                  0
                                  Это теоретические основы юзабельности.
                                    0

                                    В юзабельности теорию не учил. Но согласен конечо. это две противолопоженные стороны это-го trade off ;)

                    0

                    Отличный пример. Тоже когдато строил систему регистрации и логина и вспоминаю те же дискусси.
                    Некоторы технари-старожилы говорили, что нет никако-го трейдоффа, в их понимании просто безопасность всегда выигрывает в любом подобном трейдоффе естьли он должен существовать.
                    Что такое безопасность естественно определяли они. Их немного вводил в ступор мой аргумент что пароль в 10 знаков это недостаточно секьюрно и я им приводил какую-то убедительную рекомендацию (с сылками) чуть ли не на 20 заковыристых знаков чтобы потролить их. Некотрые суть троллинга поняли ;)

                    0
                    … при этом все удобство заканчивается тогда, когда пользователь забывает пресловутый «сильный пароль» от менеджера паролей, а вся безопасность — когда он же (во избежание вышеописанного) записывает злосчастный «сильный пароль» от менеджера паролей на подставке для монитора…

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

                    Так например, FaceID и системы с отпечатком пальца оказываются подвержены подделке с помощью моделирования, менеджер паролей может быть взломан или подменен, а мастер-пароль — забыт или незаметно скомпрометирован, сохраненный локально ключ доступа — украден вирусом, или скачан при временном доступе к физическому хосту со стороны злоумышленника.

                    Таким образом, кажущаяся удобной защита от одних рисков приводит к возникновению (или усилению) других. Похоже, игра в этом случае таки остается с нулевой суммой, лишь возрастает количество неизвестных.
                      +1
                      Талантливый человек всегда найдёт способ выстрелить себе в ногу. Наша задача — оставить ему для этого как можно меньше возможностей. И менеджер паролей всё-таки явно сокращает их количество по сравнению с просто кучей паролей. Один пароль уж явно можно запомнить и нет смысла писать на бумажке. Не говоря уже о том, что та самая бумажка — это и есть менеджер паролей, просто плохой.
                      +1
                      Мы не предлагаем пользователю запоминать много длинных паролей. Мы предлагаем ему пользоваться менеджером ключей и запомнить один сильный мастер-пароль.

                      Вот только у нас еще есть требования 2FA. И теперь у нас есть пароль (или, если нам повезло. и нам разрешили, биометрика) и еще второй фактор. И это менее удобно, чем если бы не было ни того, ни другого, а мобильное приложение просто считало бы, что если пользователь безопасно аутентифицирован телефоном, и можно дать весь доступ.


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

                        +1
                        Я не понял вашей логики. Вы добавили к моему примеру своё требование 2FA и он перестал работать — ну ок, только это уже не мой пример. Менеджер паролей всё ещё и удобнее, и безопаснее, чем запоминание/записывание каждого пароля отдельно.
                          –1
                          Менеджер паролей всё ещё и удобнее, и безопаснее, чем запоминание/записывание каждого пароля отдельно.

                          Но менее удобен, чем не вводить пароля вообще, не правда ли?

                            0
                            И менее безопасен, чем просто не давать никому доступа к системе, не так ли?) И что?
                              0

                              И то, что вот он и есть ваш компромис: добавив аутентификацию, мы сделали более безопасно и менее удобно. Соответственно, 2FA (или MFA, не суть) делает еще один шаг по той же дорожке: более безопасно, менее удобно.

                                0
                                Ну я же не пишу про 2FA. Я пишу про менеджер паролей, и с ним получается более безопасно и более удобно. Я же не утверждаю, что _всегда_ можно найти такое решение. Я утверждаю, что фундаментального противоречия между безопасностью и удобством нет, а значит, в ряде случаев их можно совместить, и отчаиваться не стоит.
                        +1
                        Эта тема, на самом деле, более глубокая, чем просто безопасность vs. удобство.
                        Невозможно вообще добиться приемлемого результата, если на пути под удар ставится удобство.

                        В контексте «безопасность vs. удобство» это значит, что если пользоваться системой становится неудобно, то пользователи либо просто прекращают пользоваться этой мега-безопасной системой, либо, если отказаться невозможно (на работе, например), начинают ей пользоваться «неправильно». Т.е. эксплойтить дыры, воспринимать безопасников как истинных врагов, иногда даже и вредить им, либо в самом безобидном случае — просто не выполнять свою непосредственную работу на достаточном для выживания организации уровне эффективности.

                        Но этот принцип проявлятся повсюду.
                        * Например, можно ли обзавестись какой-то привычкой, если не позаботиться о том, чтобы она органично и удобно вписывалась в жизнь? IMHO нет, нельзя.
                        * Будут ли участники дорожного движения соблюдать правила, если это неудобно? Тоже нет.
                        * И так далее.

                        По моим наблюдениям, граница между тем, что делается, и тем, что не делается — как раз проходит по разделу «удобно» / «неудобно».
                          0
                          Согласен на сто процентов! Поэтому и предлагаю отказаться от оправдания «ну, безопасность и удобство несовместимы, поэтому сделаем неудобно». Сделаем неудобно — не будут пользоваться; сделаем небезопасно — сломают. Надо искать тот путь, на котором удобство и безопасность сосуществуют. Зачастую это, как верно подметили выше, будет значить более дорогую разработку)
                            +2
                            Есть кейсы, когда неудобный подход все-таки побеждает.
                            Если штрафы поднимут, количество нарушений сократится, и в целом станет чуть безопаснее. Если полицейским (ДПС и аналогам) разрешить ходить в штатском при исполнении и останавливать при этом нарушителей, станет еще безопаснее, и люди будут готовы и по десять минут ждать на светофоре, лишь бы не получить непосильный штраф.

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

                            Не стоит недооценивать систему штрафов, она отлично навязывает привычки независимо от того, несут ли они полезную для человека функцию. Добиться приемлемого результата в определенной области таким образом можно. Но тогда возникнут проблемы другого характера, например, текучка кадров, особенно, невысокой квалификации или разного рода «итальянские забастовки». Локальная цель выполнена, безопасность возросла. Глобальная цель отдалилась – бизнес начинает тормозить. К сожалению, до сих пор много руководителей, особенно, низшего звена, которые не осознают подобные риски.

                            PS: А ещё есть отдельная группа менеджеров, которые навязывают небезопасные и неудобные решения, но это уже совсем грустный вариант.
                              +1
                              Аналогично и с бизнесом: если сотрудникам в договоре прописать штраф в размере месячной зарплаты за использование слабого пароля и ненадлежащее его хранение, они будут вынуждены применять неудобные методы обеспечения безопасности

                              Имхо, при этом надо ещё и честно штрафовать за нарушение. Иначе может получится весёлая ситуация: во внутреннем чата одной большой компании (информация из этого чата уже утекла, что забавно) пишут всем, что нельзя использовать Google Docs с доступом по ссылке, это считается нарушением их NDA, за это наказание вплоть до увольнения. Так пишут пару раз, никого не уволили, в итоге половина файлов этой компании все ещё доступна по ссылке, а в чате сидят левые люди.


                              Нужен и пряник, и кнут, но кнут ещё и бить должен, если есть необходимость.

                                +2
                                Ну я понимаю, что сейчас трактую всё слишком широко, и так можно совсем далеко зайти, но удобство я скорее имел в виду интегральное.

                                Т.е. если я могу нарушить скоростной режим, заплатить атвоматом штраф, а денег у меня много, и мне удобно нарушить — то я нарушу. Но если штраф автоматом я не заплачу, а гарантированно придётся записываться на приём к начальнику гаи, там на меня помои выльют, мне надо будет выпрашивать прощения для восстановления прав — то это уже максимально неудобно. Такой режим я нарушать не буду, т.к. неудобно. Но в конечном счёте если никто не будет нарушать, то мне опять будет удобно. Удобнее, чем было до, когда мне одному было удобно нарушать. И уж точно ещё лучше совместить два подхода: когда ехать правильно удобно, а нарушать максимально неудобно.

                                Тот же подход и с привычками.
                                На правах риска «неудобного разговора с начальником гаи», я могу всем публично рассказать о своей новой привычке, которой ещё нет. И потом мне будет неудобно несоответствовать образу. Но этот подход сам по себе едва сработает, если я не сделаю так, что новая желанная привычка будет удобной в графике моей жизни. Чтобы её не просто было надо делать, а было удобно делать. Даже не надо «хочу делать», достаточно просто «удобно делать».
                                  +1
                                  Вы и правда зашли далеко, но мне понравилось)
                              +2

                              Тема поста на русском: не требуется компромисс между безопасностью и удобством.
                              Но вам привели кучу примеров, в том числе по вашим кейсам, демонстрирующих, что компромисс никуда не делся. Вы можете сделать удобнее и безопаснее за счёт дополнительных затрат, но исходное противоречие никуда не исчезает => выбор между безопаснстью и удобством по-прежнему на месте

                                0

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


                                Например, многие думают что ограничения пароля (т.н. password policy) увеличивает безопасность. Но это совершенно не так! Всякое ограничение состава пароля, только уменьшает безопасность. Оно просто неудобно и поэтому выглядит безопасней.


                                А потребители, конечно очень быстро придумывают словарьные пароли, которые отвечают всем требованиям.


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

                                  0
                                  Например, многие думают что ограничения пароля (т.н. password policy) увеличивает безопасность. Но это совершенно не так! Всякое ограничение состава пароля, только уменьшает безопасность. Оно просто неудобно и поэтому выглядит безопасней.

                                  А потребители, конечно очень быстро придумывают словарьные пароли, которые отвечают всем требованиям.


                                  Минимум 8 символов, один символ в верхнем регистре, одна цифра, один спецсимвол, первые и последние 2 значения только символы в нижнем регистре

                                  А теперь давай, придумай словарный пароль, который соотвествует этому требованию и я лайкну тебя.
                                    +3

                                    qw1!Qwer — чем не словарьный?

                                  –1
                                  На мой взгляд, вся эта шумиха вокруг безопасности слишком сильно раздута. У простого, среднестатистического пользователя нет причин особо о ней беспокоиться.

                                  Сколько раз за всю жизнь взламывали ваши аккаунты? У меня за 40+ лет ни разу.

                                  Поэтому лично я не стану пользоваться безопасным, но неудобным приложением, даже если в нем соблюден компромисс между этими двумя сущностями.
                                  Единственное, что может меня привлечь, это предусмотренная разработчиком опция: «Вам как, побезопаснее, или поудобнее?» Вот тогда да, выберу последнее, и буду пользоваться.
                                    –1

                                    Зря вас заминусовали за это не совсем популярное мение в "профессиональном" комьюнити. Вы просто озвучили мысли многих пользоватеей и подчеркнули аргумент за юзабилити...

                                      –1
                                      Я даже примерно догадываюсь, кто заминусовал — безопасники ;-)
                                      Ну конечно, ведь такое мнение лишает их работы…
                                      А ведь какие замечательные продукты можно было бы выпускать, если перенаправить ресурсы безопасников на usability…
                                        –1

                                        Только Two-factor authentication на вашу аппликушечку по учету кошечек! и только с ротацией паролей каждые 6 недель! ;) — И никаких трейдоффоф!

                                    0

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


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


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


                                    К тому же, неудобная система сама по себе менее безопасна, потому что потребитель активно сопротивляется, а он умный. Пример обсудили наверх – ограничения на пароль – пользы ноль, а удобство пострадало, потребитель недоволен. Но правда, выглядит «безопасно». Только выглядит.

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

                                    Самое читаемое