Вы используете устаревший браузер!

Страница может отображаться некорректно.

Правила гигиены

Правила гигиены

Другие выпуски этой рубрики (161)
  • добавить в избранное
    Добавить в закладки

Кто увидит ваш пароль

Прочитали: 3649 Комментариев: 51 Рейтинг: 69

17 апреля 2019

В ходе обсуждения темы утечки паролей (выпуск «Взломщики крадутся незаметно») читатели проекта «Антивирусная правДА!» неоднократно спрашивали нас о том, видят ли владельцы сайтов пароли пользователей. Вот один из вопросов, который отражает общие опасения:

А у меня всегда вопрос в таких темах - зачем пользователю менять и усложнять пароль, если ломают не твою учётку, а базу данных?
И с паролями на учётки DrWeb - вы их всё-таки видите? Тогда тот же вопрос - чем сложность пароля ab123cd отличается от Ch3Ck_=0Fr_!Gn8?\'n12@az, если они просто хранятся в открытом виде в парах с логинами?

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

Исследователи обнаружили около 18% приложений, которые на самом деле даже не шифруют трафик пользователя, 38% вместе со своей программой могут нам предложить вирус или назойливую рекламу. Но самое опасное то, что более 80% приложений тайно получают доступ почти ко всем секретным данным, включая сообщения между пользователями и доступ к аккаунтам.

Источник

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

Кстати, не паролем единым:

Даже если сервис хранит их в зашифрованном виде и у сотрудников компании нет доступа к пользовательским данным, как минимум у него есть ваши IP-адреса. Бывший «Король спама», создатель ботнет-сети Kelihos Петр Левашов, нынче экстрадированный в США, был арестован в Барселоне по запросу американских властей.

Правоохранительные органы длительное время следили за его аккаунтом iCloud, благодаря IP-адресам подключений получали данные о его местонахождении. А Apple охотно, и главное тайно, передавала данные правоохранительным органам.

Источник

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

В идеале сам пароль вообще нигде храниться не должен.

То, что вводит пользователь в поле пароль (например 12345), не записывают в базу данных. Создают хэш этого пароля + соль. Почитайте о солении паролей. На выходе в вашей базе в поле password должен быть хэш (bdadb0330124cda0e8499c9cd118f7bd). Если пользователю нужно войти, то вы сравниваете хэш, который получился после ввода пароля, с тем, который хранится в вашей базе данных.

Источник

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

Если пароль простой, то «взломать» хэш можно перебором, просто вводя разные пароли, – и рано или поздно получится хэш, совпадающий с нужным.

Возможные действия злоумышленника:

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

Источник

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

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

Внимание! Не надейтесь на соль! Сами создавайте сложные пароли.

Почему используют хэш, а не шифруют пароли?

  • Трудоемкость. Шифрование занимает больше времени, а какое преобразование мы бы ни выбрали, его придется проделывать при каждой проверке пароля. Одним из требований к хэш-функциям же является быстрота выполнения.
  • Длина выходных значений. Результат шифрования имеет переменную длину, результат хэширования – всегда одинаковую, а хранить однородные по размеру данные в базе данных очень уж удобно. Не говоря уже о том, что длина пароля в зашифрованном виде будет давать некоторую информацию о длине исходного пароля.
  • Управление ключами. Для шифрования требуется ключ, который тоже где-то придется хранить и надеяться, что его никто не найдет. В любом случае, генерация и управление ключами это отдельная история (они не должны быть слабыми, их нужно регулярно менять и так далее).

Источник

Сами хэши можно хранить даже в простом текстовом файле, но это неудобно. Как правило, используется база данных, а то и не одна (примеры можно посмотреть по ссылке выше).

Как правило (дабы избежать холивара – сформулирую более конкретно: у многих популярных CMS (http://www.ratingruneta.ru/cms) или так (http://trends.builtwith.com/cms)), логины и пароли (чаще не сами пароли, а значение хэш-функции от пароля) хранятся в базе. Иногда применяется не просто хэширование, а «засаливание» паролей – у каждого движка (а иногда и у разных версий одного движка они могут отличаться) свои правила хранения паролей.

У меня, например, в php-файле.

Ещё есть HTTP_AUTH (как с использованием базы, так и .htaccess+.htpasswd), csv, ini-файлы... В некоторых случаях (фреймворки/плагины) правила и условия хранения паролей можно изменять/задавать самостоятельно. Про «авторские» движки вообще сложно рассуждать.

Источник

Так что нет у нас доступа к вашим паролям. Да он нам и не нужен.

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

#пароль

Антивирусная правДА! рекомендует

  • Ваши пароли в явном виде нигде у нас не хранятся.
  • На бога надейся, а сам не плошай: благоразумное интернет-пользование подразумевает серьезное отношение к паролям. Нельзя доверяться простым паролям, использовать один и тот же пароль для разных сайтов, хранить пароли в открытом доступе. Также большим риском для безопасности является использование при авторизации на том или ином ресурсе общественных Wi-Fi-сетей и «случайных» компьютеров.

Оцените выпуск

Сделайте репост

Необходимо войти на страницу выпуска через аккаунт на сайте «Доктор Веб» (или создать аккаунт). Аккаунт должен быть связан с вашим аккаунтом в социальной сети. Видео о связывании аккаунта.


Нам важно ваше мнение

Чтобы оставить комментарий, нужно зайти через свой аккаунт на сайте «Доктор Веб». Если аккаунта еще нет, его можно создать.

Комментарии пользователей

Комментарии к другим выпускам | Мои комментарии

 
На страницу: