Двойные стандарты в шифровании учетных записей

image
Думаю каждый, кто хоть немного интересовался информационной безопасностью, да и просто периодически читает про события в сфере IT, встречал новости, что очередная компания или интернет-сервис были взломаны, и у них были украдены учетные записи пользователей, куда обычно входят электронные адреса, пароли, номера кредитных карт, как зовут вашего домашнего питомца и многое другое (далеко ходить за примером не нужно, в октябре этого года Adobe «поделилась» базой на 130-150 миллионов учетных записей). И хорошо еще, если сервис позаботился о хешировании паролей хотя бы без применения соли, в таком случае можно надеяться, что если злоумышленники захотят воспользоваться украденным, то им придется приложить некоторые усилия для этого.

Но достаточно продолжительное время меня удивляло другое — почему в большинстве случаев хешируются лишь пароли, почему такое пренебрежение к другим важным данным пользователя, как электронные адреса или номера кредитных карт?

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

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

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

Как видите, проблемы есть, и они актуальны. Равнодушие владельца сервиса может нанести серьезных урон как его пользователям, если тот не побеспокоился о надежности сервиса от взломов и потери данных, так и себе, потеряв доверие текущей и будущей аудитории. Что же тогда можно попробовать предложить на случаи, когда данные однажды все же будут украдены?

1) Самое простое и логичное, хешируем пароли. Защита паролей может снизить риск для пользователя, если тот использует одинаковые пароли для разных сервисов. Как ни печально, до сих пор много где не применяется даже эта банальная мера предосторожности. Также, не стесняемся пользоваться солью.

2) Шифруем также и те данные, которые не используются сервисом прямо по назначению либо могут быть зашифрованы без снижения эффективности работы сервиса. Что можно предложить сходу, так это хеширование электронных адресов и ответов на секретные пароли, или другие данные, которые используются лишь при авторизации и похожих операциях. Обычно нет нужды хранить эти данные в открытом виде, если они используются однократно лишь при заходе в систему. Хотя у данного подхода есть и обратная сторона, сервис не сможет рассылать вам письма, если захочет этого, но в ряде случаев такой потребности нет, и электронная почта используется лишь для валидации учетной записи.

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

Время идет, и проблемы безопасности данных и слежки с каждым днем ощущаются все острее, и сложно представить, чем может обернуться потеря своих персональных данных завтрашним днем, если не побеспокоиться об этом уже сегодня. Уже сейчас мы можем наблюдать, как неосторожность человека в отношении своих данных может дорого ему обойтись, если не придавать значения, казалось бы, тривиальным вещам. А что вы думаете на этот счет?
AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 17

    +10
    Пароли шифруют необратимо, а для шифрования других данных, нужны обратимые методы шифрования. Пароль для них придётся хранить на сервере или клиенте, он тоже может утечь.

    Усложняете жизнь двум организациям из трёх букв.
      –3
      Безопасность в интернете — вещь относительная и никогда не может быть полной, всегда найдется кто-то умнее и настойчивее и обойдет ее. Защита предназначена для того, чтобы усложнить эту задачу для страждующих.

      Хранение пароля на сервере, конечно же, не вариант, теряется смысл. Ключ же стоит хранить лишь на стороне клиента. Если сервер не занимается заботливым кешированием ключей, то в случае потери базы ключи так просто не достанутся третьим лицам.
      +2
      Получается что зашифрованные данные и ключи для расшифровки будут храниться вместе. Так что смысла в этом нет. Если же ключ для расшифровки будет вводить пользователь при логине, то сохранность данных будет ровно до того момента пока он помнит пароль. Вот и весь сказ.
        0
        В том то и дело, ключи (не соль, ее можно оставить на сервере) для дешифрования не стоит хранить вместе с данными, ключ будет передан клиентом в тот момент, когда он взаимодействует с сервисом, и удален из памяти по окончанию работы пользователя. А то, что сохранность до тех пор, пока есть пароль — нередко такой меры будет достаточно, чтобы понизить ценность украденной базы.
          +1
          Так я не понял, а что будет происходить с данными когда пользователь забыл/потерял ключ для расшифровки?
            0
            В случае шифрования данных, пользователю ничего не остается, как либо попытаться вспомнить ключ, либо проститься со своими данными. За должную безопасность придется платить соответствующим образом. Разумеется, такая мера предосторожности подходит лишь для случаев, когда человек морально готов к такому исходу.
              +1
              Ну вот, теперь осталось убедить в необходимости такого подхода 99% населения. А до тех пор пока не убедите, они будут уходить к конкурентам. Если устраивает такой расклад — флаг в руки.
              0
              Беда будет. Тут уж каждому нужно выбирать. Либо данные не шифруются, либо данные шифруются и, в ситуации «забыл пароль», данным кирдык.
            +1
            Зачем хранить вместе?
            Есть сервер базы данных, есть сервер приложений, делаем сервер шифрования, который хранит ключи к зашифрованным данным и отдаёт их (или расшифрованные данные?) серверу приложений по запросу с хэшем пользовательского пароля (отличным от того, который хранится в таблице паролей), и с задержкой (имя-фамилия-телефон-адрес-почта-кредитка нужны редко и не сразу для всех).
            Это не решит проблему полностью, но затруднит взлом (нужно иметь доступ сразу к трём серверам) и может подать сигнал тревоги в случае массовой расшифровки пользовательских данных.
            +2
            Вы, наверное, в некоторых местах под шифрованием, всё-таки имеете ввиду хеширование? Особенно в месте про пароли — так как пароли надо хешировать (а ещё посолить и поперчить), а вот прочие данные можно и зашифровать :)
              0
              Да, верно :) Пройдусь еще раз по статье и исправлю, где есть такие неточности. Буду признателен, если напишите в личку, где я упустил.
              +2
              Хэшировать можно только что что уже не нужно будет в оригинальном виде. Например хешировать электронную почту — бред.
                0
                Все зависит от того, как она используется. Если ее используют для обратной связи — да, хешировать ее не вариант. Если для регистрации, сброса пароля, логина (т.е. в качестве идентификатора пользователя) или просто для галочки — почему бы и нет. Я мельком видел утерянную базу Adobe, и там попадались электронные адреса, которые были невалидны, а значит их никто не проверят, и что-то мне подсказывает, что таких случаев далеко не единицы. В данной ситуации, хранить лишь хеш имело смысл.
                  0
                  Если почта зашифрована, то использовать её для сброса пароля не получится — что бы её расшифровать, нужен тот самый пароль, который пользователь забыл.
                    0
                    Вовсе нет, если речь идет о первых двух случаях (поскольку в третьем случае, где используется именно шифрование данных, а не хеширование, сброс пароля просто не предусмотрен по определению). Если пользователь в какой-то момент понимает, что забыл пароль (в данном случае, пароль является лишь кодовой фразой для подтверждения владения аккаунтом), он указывает свой электронный адрес для сброса пароля в соответствующей форме, сервис берет хеш адреса, находит в базе нужную учетную запись и меняет пароль. Аналогично и для обычной авторизации — используя, допустим, пару логин/пароль, сервер возьмет хеш от обоих значений и проверит, что найденная запись с таким же хешем логина имеет такой же хеш и для пароля.
                      0
                      Обычно почта ещё используется для отправки каких-либо уведомлений — в этом случае придётся хранить адрес в открытом виде. Аналогично, логин обычно публичный и виден, например, на странице с данными пользователя или в записях на форуме.
                        0
                        Верно, я это отметил в конце второго случая, что сервис не сможет использовать хешированные данные, как например отправка уведомлений на случай хеша адреса. Все очень зависит от конкретного сервиса и того, как он использует данные. Описанные варианты не являются универсальными (ну, разве что кроме первого) на все случаи защиты данных, это лишь возможные способы для тех сервисов, где это допустимо.

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

              Only users with full accounts can post comments. Log in, please.