Как не хранить логин и пароль в коде в открытом виде?

Добрый день.
Не могу сразу сориентироваться, очень много разной информации.
Попробую сформулировать свою конкретную "боль". Есть класс, в котором есть методы для подключения к конкретной БД и возврате нужного значения.
Пользователь уже создан во всех БД с одинаковыми логином и паролем, например test/qwerty
вот обрезанный фрагмент:
Всё отлично работает.
Вопрос: как правильно реализовать хранение логина/пароля при такой реализации? Интересует конкретный пример или толковое описание.
Заранее благодарен.

0

в пропертях или в енвайронменте

1

KMA7, чем мешает что пароль записан в коде?

0

KMA7, хранить в коде уже зашифрованную строку))

0

Сообщение от Aviz__ уже зашифрованную строк

и пароль, чтобы расшифровывать?

0

Сообщение от xoraxax чтобы расшифровывать?

как ты догадался?

0

Мне мнавится идея на счет проперти, хотя тоже есть минусы.
Зачем вообще хранить пароль? Можно просто запрашивать у пользователя.

0

Сообщение от xoraxax в пропертях

И он сразу перестанет быть открытым? =)

0

Где хранить пароли и как с ними работать зависит от конечной цели. Для каких-то целей можно в коде хранить, для других в пропертях, в некоторых случаях лучше хранить пароль как char[] а не как String (т.к строки немутабельные объекты и следовательно пароль будет доступен для дампа памяти пока его не соберет GC).
Так же помнится был какой-то специальный класс javax.security вроде для паролей, но я хз как он работает с разными фреймворками.
Вобщем вопрос в отрыве от контекста не имеет смысла.

0

KEKCoGEN, javax.security вроде как отвечает именно за разрешения, предоставляемые программе, а с паролями никаких дел не имеет

0

Сообщение от KEKCoGEN в некоторых случаях лучше хранить пароль как char[] а не как String (т.к строки немутабельные объекты и следовательно пароль будет доступен для дампа памяти пока его не соберет GC).

В каких случаях? И что мешает сдампить память с char[]?

Добавлено через 1 минуту

Сообщение от ViktorFX Зачем вообще хранить пароль? Можно просто запрашивать у пользователя.

This.[/thread]

0

Сообщение от korvin_ This.

ага...пароль от БД сервера запрашивать каждый раз на старте =)))

Добавлено через 49 секунд

Сообщение от korvin_ В каких случаях? И что мешает сдампить память с char[]?

массив можно перезаписать сразу же после использования. String будет оставаться дольше.

0

А чем не прямое хранение логина/пароля спасет от той же декомпиляции и вытаскивания данных из кода? Если его из кода не вытащить или памяти, то можно используя например java agent перехватить запрос на сервер и вытащить оттуда.

0

Подскажите, пожалуйста, а как тогда правильно организовывать хранение паролей?
У меня такая ситуация - пусть есть анонимный пользователь, для него есть read-only УЗ в БД, по которой он может делать селекты к некоторым таблицам. У меня используется в автотестах, но пример с пользователем, который запрашивает наличие товара на складе в интернет-магазине - очень похож. Т.е. какой-то набор дефолтных действий, доступный всем.
Просто хранить в коде - разрабы (PHP) закидали какахами, после того, как я запушился :black_eye.:
Сейчас, я, скорее всего, использую хранение в config.properties, доступ к которому будет ограничиваться средствами ОС.
Но теперь даже интересно становится, кто как в продакшн среде это делает (чтобы и от декомпиляции, и от вытаскивания данных из кода или памяти, и от перехвата запроса на сервер). Хранение распечаток в ящике стола не предлагать

0

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

0

Сообщение от KEKCoGEN ага...пароль от БД сервера запрашивать каждый раз на старте =)))

Я не понял что имел ввиду korvin_, и сейчас не понимаю что смешного в том чтобы запрашивать пароль (например на время сессии) при доступе к БД или какому либо сервису
Логика такая : если опасно хранить в коде потому что можно его "прочитать" с дампа памяти на этом компьютере, то на этом комьютере также можно прочитать проперти файл, путь обращения, прописаный тут же, к какому либо файлу (где хранится ключ), или сам ключ с дампа памяти (мы же будем его "читать" на предмет того подходит ли он нам, откуда бы он к нам не попал).
Практика : комп можно взламать (рас дамп кто-то читает), или я с открытой сети (ноут, телефон), или вообще в интернет-кафе с чужого компа хочу купить билет и мне надо доступ к счету. Я же не буду там хранить пароль?!

Добавлено через 14 минут

Сообщение от alecss131 А чем не прямое хранение логина/пароля спасет от той же декомпиляции и вытаскивания данных из кода? Если его из кода не вытащить или памяти, то можно используя например java agent перехватить запрос на сервер и вытащить оттуда.

А что если я не буду у себя хранить пароль, а например буду вводить его при запросе к серверу? Типа сервер мне посылает один сгенерированый ключ с вопросом я ему отвечаю другим ключем (по сети комбинация из "каши" ключей), сервер то что сгенерировал помнит и таким обарзом "вытаскивает" мой ключ и если он валидный то либо удовлетворяет мой запрос на доступ либо шлет мне временный сгенерированый ключ с которым я временно работаю.

0

Сообщение от ViktorFX не понимаю что смешного в том чтобы запрашивать пароль

Представь что сервер этого форума написан на джава. У кого и когда надо спрашивать пароль к БД?

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

В реальности все несколько сложнее. Обычно "взломать компьютер" нельзя. Вместо этого используются другие векторы атаки.

Приведу простой пример. Ты написал сервер и задеплоил его на удаленную виртуалку. Доступ к ней защищен, все как надо. Однако ты используешь спринг бут и у тебя есть actuator. Это очень удобная штука чтобы решать разные проблемы. И ты по запарке или по незнанию забыл закрыть апи актуатора паролем. Или дал какой-то простой пароль.

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

Смысл в том, что чем сложнее система и чем больше модулей она включает (а особенно если её разрабатывает команда или несколько команд), тем больше вероятность получить где-то дыру в защите или много мелких дырочек, по одиночке ни на что не влияющих, но вместе позволяющий провести атаку на сервер.
В данном случае речь идет о 2х вобщем то не критчиных вещах.
1. Нет пароля на актуатор
2. БД не сидит за VPN (но имеет сложный пароль)

По отдельности это серьезные, но не критичные проблемы, однако вместе они дают полный доступ к твоему серверу.

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

3

А разве java не позволяет хранить хэш MD5 и сверять хэш пароля с ним?

0

rvs_dk, как это должно помочь мне подключиться к бд?

0

Сообщение от ViktorFX А что если я не буду у себя хранить пароль, а например буду вводить его при запросе к серверу? Типа сервер мне посылает один сгенерированый ключ с вопросом я ему отвечаю другим ключем (по сети комбинация из "каши" ключей), сервер то что сгенерировал помнит и таким обарзом "вытаскивает" мой ключ и если он валидный то либо удовлетворяет мой запрос на доступ либо шлет мне временный сгенерированый ключ с которым я временно работаю.

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

0