2017-02-02 20 views
1

Итак, моя компания использует облако Bitbucket для SCM, и я использую ScourceTree на своей рабочей станции для ноутбука. Я работаю над проектом кода, который изначально был написан кем-то другим, и в настоящее время программное обеспечение, над которым я работаю, использует файл конфигурации с открытым текстом для передачи информации о имени пользователя и пароле в программу, используемую для подключения к службам необходимо.Насколько опасно совершать код с помощью текстовых паролей в общедоступной/незащищенной сети? Как правильно обрабатывать пароли в коде?

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

Я хотел зафиксировать изменения в файле конфигурации сегодня, но я был нерешительным, поскольку я работал над незащищенной сетью в кафе. Это заставило меня задуматься: насколько безопасны большинство этих облачных сервисов кода (например, Bitbucket/Github) и насколько опасно это совершать такой код в общедоступной сети?

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

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

Я надеялся, что это может быть общий ответ для начинающих, заинтересованных в том, как безопасно работать с паролями в коде (любого языка). Я тоже работаю на C++ и PHP, поэтому я был бы очень признателен за советы относительно того, как обрабатывать такие вещи на этих языках. Не нужны экстремальные особенности, просто ключевые слова для поиска. Являются ли библиотеки или утилит встроенными в языки?

Редактировать: Я знаю, что this SO question объясняет хороший способ обработки моей ситуации на Java, но a) вопрос о сетевой безопасности между Bitbucket/Github и SourceTree отличается и b) Я просил получить дополнительную информацию об общем лучшем практики на разных языках, а скорее JUST особенности java (хотя предоставленная ссылка была весьма полезна при обращении к конкретному Java-случаю).

+0

Публичная или частная сеть, сохраняющая пароли в текстовых файлах, является плохими идеями. –

+0

Почему пароли хранятся в контроле источника? Обычные текстовые пароли на самом деле не плохая идея _per se_, но разоблачение их всем, кто может получить доступ к вашему SCM. Вопрос кажется слишком широким, потому что вы не даете никакой информации о рассматриваемом приложении. –

+0

Ответ на этот вопрос просто: потому что я работаю в небольшой компании с одним сольным разработчиком за один раз, и парень передо мной настроил это так. Мне нравится идея наличия паролей в отдельном (не-scm) файле, как это было предложено @Mike Nakis. Но я на самом деле пытаюсь пересмотреть это программное обеспечение, и я думаю, что на самом деле я добавлю аутентификацию пользователя в программное обеспечение в целом, поэтому моя текущая ситуация должна стать нецелевой. Я просто задаюсь этим вопросом в будущем. –

ответ

1

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

Если вы хотите место для безопасного хранения паролей, есть keepass, со сборками для окон и linux и некоторые его производные. Он поддерживает список логинов, и для каждой записи в списке есть опция «копировать пароль в буфер обмена». Через минуту он даже вытирает пароль из буфера обмена. Но тогда пароли, хранящиеся там, недоступны из кода.

0
  1. Что касается сетевой проблемы, используйте VPN.

  2. Что касается паролей, то уже давно принято практиковать не хранить фактические пароли ANYWHERE. Сохраните таблицу имени пользователя/пароля. Когда пароль сначала создается, хеш его и сохраняйте хэш. Когда пользователь входит в систему и вводит свой пароль, присваивает хэш и сравнивает его с сохраненным хэшем. Это обычная практика на протяжении десятилетий.

+0

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

+2

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

+0

А, я пропустил это. –