Как хранить пароли python

Хеширование паролей в Python: туториал по Bcrypt с примерами

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

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

Могу ли я хранить пароли в виде простого текста?

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

• user.one@gmail.com – somePa$$wordHere
• user.two@hotmail.com – otherPlainTextPass

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

Наилучшее решение — хеширование

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

• user.one@gmail.com – cab864878af008fbc550087940ffacdb79a7f82201725e3350e25d6cfbdd4255
• user.two@hotmail.com – 42a7fd2b639d18b3aba5db8504d4530f1f1ab58ab9615414b7629d6ec5c157b8

Они не смогут использовать хеш для входа в другие системы, потому что у них нет доступа к исходному паролю.

В Python существует библиотека Bcrypt, которая является функцией получения сильных ключей, которую можно использовать в производственных системах:

import bcrypt bcrypt.hashpw('userPlainTextPassword'.encode(), bcrypt.gensalt())

Радужные таблицы и соли

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

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

Например, допустим, что LoveMatchingToday обновился и начал хешировать пароли, но не содержал уникальных солей. Злоумышленник может иметь предварительно вычисленную таблицу хэшей:

• aab864878af008fbc550087940ffacdb79a7f82201725e3350e25d6cfbdd425f = password123
• afg3683232297323f2f0087940ffacdb79a7f8284723732350e25d6cfbdd4cccc = shadowTheHedgehog1234

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

По этой причине нам нужно «посолить» пароли. К счастью, Bcrypt обрабатывает засолку автоматически. Однако, ради обучения давайте предположим, что этого не случилось. Если бы такого не произошло, наш псевдокод выглядел бы примерно так:

# Save new password salt = creatRandomSalt() hashedPassword = hash(newPassword.concat(salt)) database.save(hashedPassword, salt) # Check password hashedPassword, salt = database.GetUserCredentals() passwordInput = userInput if hash(passwordInput.concat(salt)) == hashedPassword: login() else: failure()

Однако, поскольку Bcrypt автоматически сохраняет соль с хэшированным результатом в формате «», мы можем просто использовать следующий код:

import bcrypt # password = userInput hashAndSalt = bcrypt.hashpw(password.encode(), bcrypt.gensalt()) # save "hashAndSalt" in data base # To check: # password = userInput valid = bcrypt.checkpw(password.encode(), hashAndSalt)

Хранение пароля в Python

Всем привет. Такой вопрос, работаю с Apache Airflow, поднят в контейнерах. Так как стенд тестовый, то часто контейнеры приходится перестраивать (много косячим, приходится все откатывать). Вследствие этого слетают все настроенные соединения, постоянно добавлять их в веб-интерфейсе надоело, появилась задумка сделать баш или питон оператор, который будет добавлять эти соединения. Загвоздка в том, что для подсоединения к БД нужны логин и пароль, а хранить их в скрипте в открытом виде как то не секурно, а в интернете только безопасное хранение полученное от пользователя. Но у меня задача не чтобы при запуске скрипта самому вводить доступы (с таким раскладом я так же могу в веб интерфейсе все это вводить). А как то чтобы настройки соединения сами добавлялись, при этом логин/пароль не хранились в открытом виде в коде

Отслеживать

47.8k 17 17 золотых знаков 56 56 серебряных знаков 100 100 бронзовых знаков

задан 16 мар 2021 в 13:45

Юрий Лифанов Юрий Лифанов

57 7 7 бронзовых знаков

Как не продолбать пароли в Python скриптах

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

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

Как делать не надо

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

Чаще всего встречается вариант в стиле:

db_login = 'john.doe' password = 'password!' 

Проблема в том, что здесь пароль светится в открытом виде и достаточно просто обнаруживается среди залежей старых скриптов автоматическим поиском. Чуть более сложный вариант идет по пути security through obscurity, с хранением пароля в зашифрованном виде прямо в коде. При этом расшифровка обратно должна выполняться тут же, иначе клиент не сможет предъявить этот пароль серверной стороне. Такой способ спасет максимум от случайного взгляда, но любой серьезный разбор кода вручную позволит без проблем вытащить секретный ключ. Код ниже спасет только от таких «shoulder surfers»:

• KDE4 & KDE5 KWallet (требуется dbus)
• Freedesktop Secret Service — множество DE, включая GNOME (требуется secretstorage)
• Windows Credential Locker
• macOS Keychain

1. Похитить сам код (легко)
2. Деобфусцировать при необходимости (легко)

1. Похитить сам код (легко)
2. Деобфусцировать при необходимости (легко)
3. Скомпрометировать локальную машину, залогинившись под атакуемым пользователем (сложно)

Безопасный ввод пароля

Еще один частый вариант утечки секретных паролей — история командной строки. Использование стандартного input здесь недопустимо:

age = input("What is your age? ") print "Your age is: ", age type(age) >>output What is your age? 100 Your age is: 100 type 'int'> 

В примере выше я уже упоминал библиотеку getpass:

# Безопасно запрашиваем ввод пароля в CLI password = getpass.getpass(prompt="Enter secret password:") 

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

Немного о Powershell

Для Powershell правильным вариантом является использование штатного Windows Credential Locker.
Реализуется это модулем CredentialManager.

Install-Module CredentialManager -force New-StoredCredential -Target $url -Username $ENV:Username -Pass . Get-StoredCredential -Target . 

Безопасный питон. Осваиваем приемы защищенного кодинга на Python

Се­год­ня мы погово­рим о том, что дол­жно вол­новать каж­дого кру­того прог­раммис­та, — о безопас­ном коде. Ты дума­ешь, это скуч­но и слож­но? Ничуть! Я поделюсь с тобой сво­им опы­том и покажу, как научить­ся писать на Python код, за который потом не при­дет­ся крас­неть.

Ограничь область видимости переменных и функций

Об­ласть видимос­ти перемен­ной — это кон­текст, в котором перемен­ная опре­деле­на и дос­тупна. Если перемен­ная дос­тупна во всем коде, она называ­ется гло­баль­ной. Если перемен­ная дос­тупна толь­ко внут­ри фун­кции или метода, она называ­ется локаль­ной.

Смот­ри, что про­исхо­дит, если мы исполь­зуем гло­баль­ную перемен­ную:

secret = «my super secret data»
def print_secret () :
# Используем глобальную переменную
print ( secret )
print_secret ( )

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

По­это­му луч­ше исполь­зовать локаль­ные перемен­ные:

def print_secret () :
# Объявляем локальную переменную
secret = «my super secret data»
print ( secret )
print_secret ( )

Те­перь перемен­ная secret дос­тупна толь­ко внут­ри фун­кции print_secret( ) . Такой под­ход не толь­ко сде­лает код более безопас­ным, но и облегчит его чте­ние, а так­же упростит отладку и под­дер­жку.

Разделяй код на модули

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

Но как модуль­ность помога­ет обе­зопа­сить код? Дело в том, что чем мень­ше кусоч­ки, тем лег­че в них будет искать ошиб­ки и тем мень­ше шанс слу­чай­но что‑то сло­мать, ког­да вно­сишь изме­нения. Хорошо орга­низо­ван­ный код лег­ко менять, и если он раз­бит на изо­лиро­ван­ные час­ти, то изме­нения в одной не зат­ронут дру­гие.

Речь здесь не толь­ко о раз­делении боль­шого про­екта на пакеты, которые мож­но будет импорти­ровать, но и о дроб­лении кода на фун­кции и объ­екты.

Вот при­мер пло­хого кода:

def do_something () :
# Делаем много разных вещей здесь
# О, и тут мы делаем что-то еще
# И еще что-то здесь

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

А теперь пос­мотрим на хороший при­мер:

def do_something_1 () :
# Делаем что-то здесь
def do_something_2 () :
# Делаем что-то здесь
def do_something_3 () :
# Делаем что-то здесь

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

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

Вот при­мер хороше­го кода с исполь­зовани­ем клас­сов:

class MyAwesomeClass :
def __init__ ( self , some_data ) :
self . some_data = some_data
def do_something_1 ( self ) :
# Делаем что-то с some_data здесь
def do_something_2 ( self ) :
# Делаем что-то еще с some_data здесь

В этом при­мере мы соз­даем класс MyAwesomeClass , который содер­жит два метода: do_something_1 и do_something_2 . Каж­дый из этих методов работа­ет с дан­ными, которые мы переда­ем при соз­дании объ­екта клас­са. Это поз­воля­ет нам кон­тро­лиро­вать, как эти дан­ные исполь­зуют­ся и обра­баты­вают­ся. Безопас­ность сра­зу воз­растет!

Глав­ный вывод здесь: чем про­ще и понят­нее код и чем лег­че его под­держи­вать, тем он безопас­нее.

Защитись от инъекций кода

Что такое эти самые инъ­екции? Пред­ставь, что злой поль­зователь вво­дит в твое при­ложе­ние не дан­ные, которые от него зап­росили, а исполня­емый код, который при­ложе­ние по какой‑то при­чине возь­мет и выпол­нит. При­чем зачас­тую это не код на Python, а зап­росы к базе дан­ных на SQL или коман­ды опе­раци­онной сис­темы. Зву­чит страш­новато? Давай пос­мотрим, почему такое иног­да слу­чает­ся.

Плохой пример

Взгля­ни на этот кусок кода. Что здесь не так?

def get_user ( name ) :
query = «SELECT * FROM users WHERE name = ‘» + name + «‘»
return execute_query ( query )

Ты прос­то берешь имя поль­зовате­ля и сра­зу вты­каешь его в зап­рос SQL. А что, если поль­зователь вве­дет что‑то вро­де ‘John’; DROP TABLE users; — ? Поз­драв­ляю, ты толь­ко что потерял всех сво­их поль­зовате­лей! При­мер прос­то клас­сичес­кий.

Вот как выг­лядит безопас­ная вер­сия это­го кода:

def get_user ( name ) :
query = «SELECT * FROM users WHERE name = ?»
return execute_query ( query , ( name ,) )

Здесь мы исполь­зуем парамет­ризован­ный зап­рос, то есть переда­ем имя поль­зовате­ля отдель­но, и наша база дан­ных гаран­тирован­но его экра­ниру­ет. Это зна­чит, что, даже если поль­зователь попыта­ется ввес­ти SQL-код, тот будет вос­при­нят прос­то как стро­ка и ничего пло­хого не про­изой­дет.

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

Используй безопасные методы сериализации и десериализации

Что за страш­ные сло­ва — «сери­али­зация» и «десери­али­зация»? Не вызыва­ют ли они дере­али­зацию? Не пугай­ся! Сери­али­зация — это по сути прос­то прев­ращение вся­ких струк­тур вро­де спис­ков и сло­варей в стро­ку, которую лег­ко хра­нить на дис­ке или переда­вать по сети. Десери­али­зация — обратный про­цесс, то есть прев­ращение пос­ледова­тель­нос­ти сим­волов в струк­туру.

Здесь кро­ется целый класс уяз­вимос­тей. Если прев­ращать стро­ки в струк­туры неак­курат­но, то зло­умыш­ленник, манипу­лируя дан­ными, смо­жет перех­ватить управле­ние тво­ей прог­раммой.

При­мер опас­ного кода:

import pickle
# Никогда так не делай!
def unsafe_deserialization ( serialized_data ) :
return pickle . loads ( serialized_data )

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

import json
# Гораздо лучше!
def safe_deserialization ( serialized_data ) :
return json . loads ( serialized_data )

Здесь я исполь­зую для десери­али­зации модуль json. Он не поз­воля­ет выпол­нить про­изволь­ный код, так что он безопас­нее. Всег­да пом­ни о рис­ках и выбирай безопас­ные методы!

info

Уяз­вимос­ти, выз­ванные ошиб­ками в десери­али­зации, пери­оди­чес­ки находят в круп­ных про­дук­тах. Нап­ример, в 2023 году была най­дена уяз­вимость в GoAnywhere MFT. Она поз­воляла уда­лен­ным ата­кующим выпол­нять код без аутен­тифика­ции.

Используй принцип наименьших привилегий

Этот прин­цип гла­сит: дай прог­рамме толь­ко те при­виле­гии, которые ей дей­стви­тель­но нуж­ны для выпол­нения ее задачи.

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

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

def write_to_file ( file_path , data ) :
with open ( file_path , ‘w’ ) as f :
f . write ( data )

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

Всег­да давай сво­им фун­кци­ям и прог­раммам толь­ко те при­виле­гии, которые им дей­стви­тель­но нуж­ны, и ничего боль­ше.

Избегай уязвимостей, связанных с аутентификацией и авторизацией

Бе­зопас­ная авто­риза­ция поль­зовате­лей — это огромная тема, в которой есть мас­са под­водных кам­ней. Впро­чем, некото­рых из них избе­жать очень лег­ко.

Безопасное хранение паролей

Нач­нем с того, что абсо­лют­но недопус­тимо. Никог­да (никог­да!) не хра­ни пароли в откры­том виде. Нап­ример, вот так:

«alice» : «password123» ,
«bob» : «qwerty321»

Ес­ли эти дан­ные уте­кут (а веро­ятность это­го всег­да есть), то все пароли тво­их поль­зовате­лей ста­нут извес­тны.

Так как же делать пра­виль­но? Нуж­но исполь­зовать хеширо­вание паролей. Хеширо­вание — это про­цесс, при котором из пароля генери­рует­ся уни­каль­ная стро­ка фик­сирован­ной дли­ны. При этом уни­каль­ность хеша озна­чает, что даже нез­начитель­ное изме­нение в исходном пароле пол­ностью изме­нит его хеш.

В Python для хеширо­вания мож­но исполь­зовать модуль hashlib. Пос­мотрим, как это работа­ет, на при­мере:

import hashlib
password = «password123»
hashed_password = hashlib . sha256 ( password . encode ()) . hexdigest ( )
print ( hashed_password )

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

Соль для паролей

Присоединяйся к сообществу «Xakep.ru»!

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку! Подробнее