Пароль в репозитории на облачной службе

Question

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

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

Это плохой дизайн? Разумно ли никогда не хранить пароли в репозитории GIT и обеспечивать принудительное использование паролей? Мой единственный другой опыт - с Heroku, где пароли не включены в конфигурационные файлы (и мой пароль никогда не показывался в виде простого текста). Спасибо!

Answer 1

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

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

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

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

Итак, реальный вопрос не в том, как они его шифруют (на самом деле это не имеет значения). Реальный вопрос заключается в том, как они контролируют сайт в целом, чтобы убедиться, что он не был взломан. Это сводится к тому, используют ли они IDS / IPS (система обнаружения / защиты от вторжений). Если нет, перейдите к другому провайдеру, который его использует.

Answer 2

Ааа, старое "Не волнуйся, мы используем AES!"защита.Если я правильно понимаю ваше утверждение, может показаться, что они хранят пароли своих пользователей, не хэшированные в одном файле, а затем шифруют этот файл с помощью AES.Если так, то да, это вообще плохой дизайн.Стандартный метод, конечно, хранит хешированные и соленые пароли в незашифрованном файле.

Хранение паролей в зашифрованном файле сопряжено с рядом проблем:

1) Какой пароль к зашифрованному файлу?По причинам, связанным с черепахами, вы не можете зашифровать этот пароль.Его можно украсть / угадать.

2) У вас есть стандартная проблема с паролем в зашифрованном файле.Вы делаете это низкой энтропией и запоминаете это?Вы делаете это с высокой энтропией и сохраняете это где-то на диске.У обоих есть очевидные проблемы, и помните, что этот ключ является единственной точкой отказа для всей системы.

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

Что касается «Они используют мой один пароль как для моей общей учетной записи, так и для доступа к базе данных»."проблема, что более спорно, я думаю.С одной стороны, вы можете ограничить доступ к любому паролю.Но с другой стороны, необходимость создавать разные пароли для каждой мелочи приводит к неправильному созданию и повторному использованию пароля.