Как не продолбать пароли в Python скриптах
Все меняется, когда мы убираем из схемы человека, который старательно вводит ключ с бумажки. При взаимодействии двух информационных систем, на клиентской стороне в любом случае должен храниться пароль в открытом для системы виде, чтобы его можно было передать и сравнить с эталонным хешем. И вот на этом этапе админы обычно открывают местный филиал велосипедостроительного завода и начинают старательно прятать, обфусцировать и закапывать секретный ключ в коде скриптов. Многие из этих вариантов не просто бесполезны, но и опасны. Я попробую предложить удобное и безопасное решение этой проблемы для python. И чуть затронем powershell.
Как делать не надо
Всем знакома концепция «временного скриптика». Вот буквально только данные по-быстрому распарсить из базы и удалить. А потом внезапно выясняется, что скрипт уже из dev-зоны мигрировал куда-то в продакшен. И тут начинают всплывать неприятные сюрпризы от изначальной «одноразовости».
Чаще всего встречается вариант в стиле:
Проблема в том, что здесь пароль светится в открытом виде и достаточно просто обнаруживается среди залежей старых скриптов автоматическим поиском. Чуть более сложный вариант идет по пути security through obscurity, с хранением пароля в зашифрованном виде прямо в коде. При этом расшифровка обратно должна выполняться тут же, иначе клиент не сможет предъявить этот пароль серверной стороне. Такой способ спасет максимум от случайного взгляда, но любой серьезный разбор кода вручную позволит без проблем вытащить секретный ключ. Код ниже спасет только от таких «shoulder surfers»:
Самый неприятный сценарий — использования систем контроля версии, например git, для таких файлов с чувствительной информацией. Даже, если автор решит вычистить все пароли — они останутся в истории репозитория. Фактически, если вы запушили в git файл с секретными данными — можете автоматически считать их скомпрометированными и немедленно начинать процедуру замены всех затронутых credentials.
Использование системного хранилища
Есть крутейшая библиотека keyring. Основной принцип работы строится на том, что у каждого пользователя ОС есть свое зашифрованное хранилище, доступ к которому возможен только после входа пользователя в систему. Она кроссплатформенная и будет использовать тот бэкенд для хранения паролей, который предоставлен операционной системой:
Сравним сложность атаки
При хранении пароля непосредственно в скрипте нужно:
Пример использования
Безопасный ввод пароля
Еще один частый вариант утечки секретных паролей — история командной строки. Использование стандартного input здесь недопустимо:
В примере выше я уже упоминал библиотеку getpass:
Ввод данных при ее использовании аналогичен классическому *nix подходу при входе в систему. Ни в какие системные логи данные не пишутся и не отображаются на экране.
Немного о Powershell
Для Powershell правильным вариантом является использование штатного Windows Credential Locker.
Реализуется это модулем CredentialManager.
Как не хранить логин и пароль в коде в открытом виде?
Помощь в написании контрольных, курсовых и дипломных работ здесь.
Авторизация пользователя. Как хранить логин и пароль
Всем добрый день! Наконец-то добралась до авторизации пользователя. Отсюда вопрос: Где и как.
mssql + Android логин пароль где хранить?
есть сайт (интернет магазин ASP + MSSQL) поднят на хостинге у провайдера, приложение должно брать.
Где хранить логин и пароль (авторизация на сайте)
Доброго времени суток! Была поставлена задача сделать сайт с использованием JS. Есть сайт HTML.
В каких случаях? И что мешает сдампить память с char[]?
Добавлено через 1 минуту
ага. пароль от БД сервера запрашивать каждый раз на старте =)))
Добавлено через 49 секунд
Я не понял что имел ввиду korvin_, и сейчас не понимаю что смешного в том чтобы запрашивать пароль (например на время сессии) при доступе к БД или какому либо сервису 
Логика такая : если опасно хранить в коде потому что можно его «прочитать» с дампа памяти на этом компьютере, то на этом комьютере также можно прочитать проперти файл, путь обращения, прописаный тут же, к какому либо файлу (где хранится ключ), или сам ключ с дампа памяти (мы же будем его «читать» на предмет того подходит ли он нам, откуда бы он к нам не попал).
Практика : комп можно взламать (рас дамп кто-то читает), или я с открытой сети (ноут, телефон), или вообще в интернет-кафе с чужого компа хочу купить билет и мне надо доступ к счету. Я же не буду там хранить пароль?! 
Добавлено через 14 минут
Представь что сервер этого форума написан на джава. У кого и когда надо спрашивать пароль к БД?
В реальности все несколько сложнее. Обычно «взломать компьютер» нельзя. Вместо этого используются другие векторы атаки.
Приведу простой пример. Ты написал сервер и задеплоил его на удаленную виртуалку. Доступ к ней защищен, все как надо. Однако ты используешь спринг бут и у тебя есть actuator. Это очень удобная штука чтобы решать разные проблемы. И ты по запарке или по незнанию забыл закрыть апи актуатора паролем. Или дал какой-то простой пароль.
Теперь я могу сделать дамп памяти твоего сервера, не заходя на сервер и вообще не имея на него доступ. Просто выполнить запрос, зная что у тебя есть актуатор и получить обратно файлик.
Смысл в том, что чем сложнее система и чем больше модулей она включает (а особенно если её разрабатывает команда или несколько команд), тем больше вероятность получить где-то дыру в защите или много мелких дырочек, по одиночке ни на что не влияющих, но вместе позволяющий провести атаку на сервер.
В данном случае речь идет о 2х вобщем то не критчиных вещах.
1. Нет пароля на актуатор
2. БД не сидит за VPN (но имеет сложный пароль)
По отдельности это серьезные, но не критичные проблемы, однако вместе они дают полный доступ к твоему серверу.
PS. Все вышесказанное, конечно не относится к пет проектам студентов, а имеет смысл для действительно больших энтерпрайз решений.
Про хранение паролей в БД
Сегодня посмотрим, как лучше всего хранить пароли в базе данных и как известные платформы решают эту задачу.
Plaintext
Когда встал вопрос хранения паролей, конечно, первой идеей было просто записывать их в открытом виде в соответствующей табличке в базе данных. И все бы ничего, если бы доступ к ней действительно напрямую клиенты получить не могли. Но, к сожалению, в различных веб-приложениях по-прежнему иногда работает такая известная всем SQL-инъекция, не говоря уже о других потенциальных уязвимостях. В вопросах безопасности вообще принято предполагать худшее и готовить план действий и защиту даже на такой случай. Будем считать, что злоумышленник нашел в веб-приложении лазейку, тем или иным способом радостно выгружает себе таблицу с именами и паролями пользователей и дальше уже распоряжается ими, как ему вздумается. В общем случае его дальнейшие действия могут быть следующими:
Шифрование Хэширование
Идея сразу оказывается не такой хорошей. Что делать? Здорово было бы хранить пароли в зашифрованном виде. Тогда, даже если их извлекут, восстановить не смогут или, по крайней мере, потратят на это слишком много времени. Здесь выбор встает между двумя ветками развития: шифровать пароли или хэшировать. Разработчики остановились на втором, и, в принципе, понятно, почему. Сравним наших претендентов по разным характеристикам:
Атаки на хэшированные пароли
Итак, злоумышленник заполучил нашу таблицу с именами пользователей и паролей. Пароли теперь захэшированы, но это нашего атакующего не останавливает, и он всерьез намерен их восстановить. Его возможные действия:
MD5 – 627 мс
SHA-1 – 604 мс
SHA-256 – 739 мс
SHA-512 – 1056 мс
А ведь сегодня брутфорс можно распараллелить и выполнить в разы быстрее на GPU (а также на APU, DSP и FPGA). Однако помимо выбора более долгого алгоритма и более длинного выходного результата можно сделать кое-что еще.
Хэширование хэша
Чтобы помешать нарушителю воспользоваться готовыми радужными таблицами, существует техника хэширования пароля несколько раз. То есть вычисляем хэш от хэша от хэша от хэша… и так n раз (надо, правда, сильно с этим не увлекаться, потому что при обычной проверке пароля пользователя серверу тоже придется это проделывать). Теперь так просто по радужной таблице он пароль не найдет, да и время на брутфорс заметно увеличится. Но ничто не остановит злоумышленника от того, чтобы сгенерировать радужную таблицу по словарю паролей, зная алгоритм хэширования. Тем более, для самых популярных комбинаций этого метода такие таблицы уже сгенерированы:
«
Добавить соль по вкусу
Для того, чтобы и это он не смог сделать, пароли сегодня хэшируются с добавлением соли.
Соль – это дополнительная случайная строка, которая приписывается к паролю и хэшируется вместе с ним. Из полученного таким образом хэша по радужной таблице пароль уже не восстановишь. Зная соль и выходной хэш, злоумышленник обречен на брутфорс и никакие заранее вычисленные таблицы ему, скорее всего, не помогут.
Таксономия соления паролей:
1. По принципу соления:
Как хранят пароли различные CMS
WordPress
До версий 3.х пароли просто хэшировались с помощью MD5. Сейчас используется библиотека phpass. По умолчанию к паролю спереди приписывается соль и полученная строка хэшируется MD5 2^8 раз.
Joomla
До версии 1.0.12 использовался просто MD5. Используется библиотека phpass, по умолчанию bcrypt с солью и 2^10 повторениями.
Drupal
До версии 6 md5 без соли. Используется библиотека phpass. По умолчанию соленый sha512 с 2^16 повторениями.
Silverstripe
Использует соленый Blowfish c 2^10 повторениями.
Как хранить пароли если ты ПАРАНОИК?
Недавно мне на глаза попадалась публикация на Хабре про сервер взлома паролей с кучей GPU.
Ссылку я добросовестно где-то профукал, но помню, что в статье говорилось про феноменальную скорость перебора паролей на этом «девайсе». Что 8-значный пароль по полной раскладке клавиатуры и всем регистрам ломался чуть ли не за 5-10 секунд, аж GPU нагреться не успевали.
Вот тут-то меня и посетила мысль: а как вообще при современных вычислительных мощностях оберегать свои пароли от компрометации?
Собственно, и решил поделиться двумя методами, которые использую лично я:
1) Парольная фраза;
2) Двойной слепой пароль.
Парольная фраза
— А откуда ты узнала пароль?
— А я и не знала.
— То есть? — опешил я.
— А то и есть. Он слишком часто повторял фразу «Мы лишь тени на ветру», и я понадеялась, что это и будет паролем. А вводить его можно лишь единожды.
— Судьба с нами играет, — мимо воли резюмировал я.
Сознание отказывалось до конца поверить в происходящее.
Синто. Чужие звезды. – Пушкарева Л.М.
Как вы уже могли догадаться из названия, суть метода заключается в том, чтобы вместо 8, 12 … N-значных паролей использовать некие осмысленные фразы или выражения из своих любимых произведений: кино, книг, философских трудов или просто житейских мудростей.
Было время, когда моей любимой заменой паролю в различных системах была фраза «YouShallNotPass!-Said_Gandalf».
Можно использовать русское написание в сочетании с английской раскладкой.
Так, легко и непринужденно парольная фраза «Платон_мне_друг_но_истина_дороже» превращается в «Gkfnjy_vyt_lheu_yj_bcnbyf_ljhj;t».
Основной плюс этого метода — мы с легкостью выходим за привычные значения паролей (8-12 символов).
Из минусов следует отметить, что достаточно хорошо вас знающий человек сможет просто угадать эту фразу. Хоть это и не будет просто, но вероятность всё же есть.
Двойной слепой пароль (Double Blind Password)
К своему удивлению, я не встречал статей по описанию этого метода защиты пароля в русскоязычных источниках. Не помню уже даже, где и как получил знание этого метода, но, на мой взгляд, он весьма хорош для защиты паролей. Особенно в тех случаях, когда вы не готовы доверять даже менеджерам паролей!
Этот метод применим только в связке с каким-либо менеджером паролей, благо сейчас их не использует только ленивый.
Суть метода: вы генерируете некий сложный пароль и сохраняете его в менеджере паролей под соответствующей записью.
Пример: пароль для ВКонтакте – ERTnmm@#dkf901
Далее добавляете к нему уникальную ключ-фразу. Ну, например, Pushistik777.
Получившуюся комбинацию — ERTnmm@#dkf901Pushistik777 — устанавливаете в качестве пароля для ВКонтакте в самой соц. сети.
Таким образом, даже если злоумышленник сумеет получить доступ к вашему менеджеру паролей, то он всё равно не завладеет искомым паролем и не сможет зайти в ваш аккаунт ВКонтакте.
У него будет только первая часть пароля, ERTnmm@#dkf901, которая хранится в менеджере. А вторую часть, Pushistik777, вы держите исключительно у себя в голове и никому и никогда не говорите.
Ну и, как вы уже догадались, для каждого следующего сервиса вы генерируете новую уникальную первую часть пароля и заносите её в менеджер паролей, а вторая часть остается той же (Pushistik777).
Оргвыводы
Выводы, выводы… А, собственно, нет их) Если знаете ещё какие-либо методы защиты паролей в этом бешено прогрессирующем IT-мире, поделитесь в комментариях.
Надеюсь, рассмотренные мною 2 метода будут кому-то полезны и смогут повысить вашу безопасность.
РНР-безопасность: где и как хранить пароли. Часть 1
Каждый год в мире происходит все больше хакерских атак: от краж кредитных карт до взломов сайтов онлайн-магазинов. Уверены, что ваши скрипты по настоящему защищены? В преддверии старта курса «Backend-разработчик на PHP» наш коллега подготовил интересную публикацию на тему безопасности в PHP.
Введение
Скандал с Facebook и Cambridge Analytica, утечка переписки Демократической партии США в 2016 году, нарушение безопасности данных Google в 2018 году, взлом Yahoo Voice в 2012 году — вот лишь несколько примеров крупных утечек, зафиксированных за последние несколько лет.
Информация в глобальном масштабе сегодня доступна для нас, как никогда ранее. Если не проявлять должную осторожность, информация о нас самих (в том числе сведения конфиденциального характера) тоже могут попасть в открытый доступ.
Неважно, разработкой какого именно проекта вы занимаетесь: детской игрой с открытым кодом или выполняете заказ крупного предприятия. Ваша обязанность как веб-разработчика состоит в том, чтобы обеспечить безопасность всем своим платформам. Безопасность — это очень непростой аспект.
Язык РНР предоставляет несколько инструментов и функций, которые можно задействовать для обеспечения безопасности приложения.
3 правила безопасности паролей
Пароли пользователей должны оставаться неизвестными для вас.
Я до сих пор вспоминаю свои первые шаги в роли РНР-разработчика. Первым созданным мной приложением стала игра, где я вместе с друзьями играл роль строителя небоскрёбов. Каждый из нас мог залогиниться в свой аккаунт, купить строителей и каждую неделю отправлять свою бригаду на новую стройку. Я создал базовые аккаунты: добавил для каждого пользователя логин и пароль и отправил их им по е-мейлу. И только через пару месяцев я понял, насколько это было глупо.
Общее правило таково: вы не только не должны знать пароли своих пользователей — у вас не должно быть возможности узнать их. Это очень серьезный аспект, который может повлечь даже юридическую ответственность.
Методом проб и ошибок вы все равно придете к выводу, что пароли не надо хранить в формате обычного текста или в таком виде, чтобы они легко поддались расшифровке.
Не вводите ограничения на пароли
Давайте сыграем в одну игру. Попробуйте угадать пароль:
Сложно, правда? Давайте попробуем так:
Теперь вы знаете, что здесь есть заглавная буква и несколько прописных. А если вот так:
Теперь вам будет намного легче угадать пароль — ведь вы знаете, что он включает в себя заглавную букву, прописные буквы и число.
То же самое происходит в тех случаях, когда вы навязываете пользователям ограничения и маски для их паролей. Если в вашем приложении заложено требование следовать определенному шаблону, вы даете злоумышленникам намеки, которые они могут использовать против вас.
Требовать некую минимальную длину пароля — это нормально, так как длина пароля влияет на то время, которое требуется, чтобы подобрать его. Однако вместо этого будет намного полезнее узнать, как работают алгоритмы и хеширование.
Кстати, правильный ответ к приведенной выше загадке — «Porsche911» 🙂
Никогда не отправляйте пароли по е-мейлу в чистом виде
Одной из моих первых ошибок в роли веб-разработчика стало то, что я заблаговременно не научился управлять паролями.
Представьте, что вы клиент и вы нанимаете разработчика, чтобы он создал для вашего бизнеса симпатичный сайт электронной коммерции. Этот разработчик прислал вам е-мейл, который содержит пароль для вашего сайта. Теперь вам известно три вещи о вашем сотруднике:
А вот как должен поступить веб-разработчик:
Видите, насколько возросла безопасность приложения благодаря этим простым шагам? При желании, мы можем повысить уровень безопасности еще больше, добавив лимит времени между запросом и установлением нового пароля.
Как хешировать пароли пользователей
Пароли в веб-приложении нужно хешировать, а не зашифровывать. Шифрование — это двухсторонний алгоритм. Шифровке подвергается последовательность, которую вы затем можете расшифровать и использовать повторно. Этот метод часто используется в разведке для получения информации от союзников.
Хеширование предполагает, что последовательность нельзя вернуть в формат незашифрованного текста. Именно это конечная цель всего процесса.
Для достижения разных целей разработано множество алгоритмов: одни отличаются высокой скоростью, другие высокой надежностью. Эта технология постоянно эволюционирует, и за последние несколько лет претерпела немало изменений. Сейчас мы рассмотрим три наиболее популярные ее разновидности в хронологическом порядке.
Это была исторически первая функция хеширования. Аббревиатура SHA-1 расшифровывается как «безопасный алгоритм хеширования», разработало его Агентство национальной безопасности США.
SHA-1 был хорошо известен и широко востребован в сфере РНР для создания 20-байтовой шестнадцатеричной строки длиной в 40 символов.
SSL-индустрия в течение нескольких лет пользовалась SHA-1 для цифровых подписей. Затем, после выявления некоторых слабых мест, в Google решили, что пора переходить на SHA-2.
Первая версия алгоритма была признана устаревшей в 2005 году. Впоследствии были разработаны и приняты к использованию новые версии: SHA-2, SHA-2 и SHA-256.
Bcrypt
Bcrypt, не являясь результатом естественного развития SHA, сумел привлечь к себе широкую аудиторию благодаря своему уровню безопасности.
Этот крайне медленный алгоритм был создан с целью создания максимально безопасных хешированных последовательностей. В процессе хеширования данных он проходит несколько циклов, что в вычислительной технике описывается показателем трудозатрат. Чем выше показатель трудозатрат, тем дороже будет для хакера заполучить пароль.
Есть и хорошая новость: в будущем мы сможем использовать более мощные машины, способные на более скоростное прохождение большего количества циклов.
Argon2
Это новый модный алгоритм в сфере хеширования, разработанный Алексом Бирюковым, Даниэлем Дину и Дмитрием Ховратовичем из Люксембургского университета. В 2015 году он стал победителем Конкурса хеширования паролей.
Argon2 представлен в 3 версиях:
Во второй части статьи я расскажу, как использовать это хеширование в РНР, задействуя встроенные функции, а сейчас хочу пригласить всех на бесплатный онлайн вебинар «ServerLess PHP», в рамках которого мы познакомимся с концепцией Serverless, поговорим о её реализации в AWS, применимости, ценах. Разберём принципы сборки и запуска, а также построим простой TG-бот на базе AWS Lambda.
