LINUX.ORG.RU
ФорумAdmin

как держать пароли от системных «юзеров»

 , ,


0

2

Небольшое вступление. Я сейчас поднимаю небольшую инфраструктуру, есть приложение, для которого был сделан юзер, который пишет в базу в postgresql. Потом может добавиться еще что-нибудь: самба или nextcloud – всем надо раздать по юзеру и каждому надо создать пароль, а создать одного юзера, который работает во все БД мне кажется как-то неправильно. Думаю на локальной машине держать отдельный менеджер паролей для того, чтобы держать все пароли для админских вещей, либо делать пароль по имени приложения, но это звучит небезопасно.

В общем, как правильно контролировать весь этот объем паролей, которые приходиться иногда выкапывать? Извините, если вопрос глупый, я только вкатываюсь в админство и прочие devops-ы.

★★★

Последнее исправление: snake266 (всего исправлений: 1)

Вариантов больше одного.
1. Создаете централизованное хранилище из которого ваши сервисы и будут авторизоваться.
2. Создаете централизованное хранилище в котором будут записаны эти данные для «потомков» и вас в том числе.
Но самое важное бэкапы и ещё раз бэкапы этих хранилищ, даже если они на тетрадном листочке записаны.

anc ★★★★★
()

Использовать менеджер паролей. Например keepasscx. Файл с паролями можно синхронизировать, например тем же nextcloud. Для nextcloud есть gui для keepass. Через некстклауд открываю файл с паролями на телефоне через. Файл шифруется по умолчанию.

Для небольшой инфраструктуры самое то. Для более крупных компаний есть чисто web решения с разделением доступа и так далее.

einhander ★★★★★
()
Ответ на: комментарий от mky

Создавать в СУБД пользователя без пароля?

Ну это смотря для чего, кто с ней и как работает. Для хоста 127.0.0.1 всегда без пароля у меня, есть пользователь с правами только read, есть с write. Что база то прям голой Ж.. в инет выставлена?!?! В инет смотрит наверное апач или (непроизносимое) а уж они с базой работают, у меня так и даже краснокожий не выставлен наружу, так для локального пользования. Поэтому не парюсь.

alex_sim ★★★★
()
Ответ на: комментарий от einhander

Использовать менеджер паролей. Например keepasscx

Лет 20 уже использую базу данных с паролями собственного приготовления :)) поля логина и пароль зашифрованы с помошью соли, раньше совал записи прям с консоли, смотрел с помощью php скрипта, потом обленился немного его подрихтовал и стал совать с помошью него же. Пароли не особо секретные, для всякой моей личной бытовухи конференции, личные кабинеты, куда ни сунься везде логин и пароль. Можно для многих пользователей, каждый посолит по своему и раскрутит только то что надо, примечание тоже можно засолить.

use pass;
insert into  users (prim,username,password) values ('Пароль Дом ру (к примеру)',ENCODE('login','salt'),ENCODE('passwird','salt'));

Можно по вкусу добавить поле пользователя и по нему фильтровать, вообщем есть над чем разгуляться.

alex_sim ★★★★
()
Последнее исправление: alex_sim (всего исправлений: 1)
Ответ на: комментарий от alex_sim

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

emorozov
()
Ответ на: комментарий от emorozov

Налицо непонимание того, что такое соль, и для чего она нужна.

НУ растолкуте в двух словах, или в понятной доке отправьте (только не к первой строке гугла :)), для моих архисекретных задач, этого достаточно.

alex_sim ★★★★
()
Последнее исправление: alex_sim (всего исправлений: 1)
Ответ на: комментарий от alex_sim

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

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

emorozov
()
Ответ на: комментарий от alex_sim

Для хоста 127.0.0.1 всегда без пароля у меня
В инет смотрит наверное апач или (непроизносимое) а уж они с базой работают, у меня так и даже краснокожий не выставлен наружу, так для локального пользования.

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

anc ★★★★★
()
Ответ на: комментарий от anc

@anc я вас умоляю! Пользователи на моем линуксе, да в консоли?!?! даст ист фантастиш! Я один реальный пользователь, и шифруюсь (солю) исключительно от себя, пользователи на хосте у меня apache, dovecot, postfix, mysql и тд к тому же nologin

У меня бегунок 40 летний аля itшник картриджи поменять, корды воткнуть, базы 1С подключить и тот про линукс только слышал. Я уже 29 лет жду когда же придет грамотный пользователь, ведь должно же вырости уже поколение, которое с молоком матери…. мне кажется они все тупее и тупее приходят со своими гаджетами, бабушки 25 лет назад и то старательнее пытались понять и запомнить.

alex_sim ★★★★
()
Ответ на: комментарий от anc

«Ваша система» может быть уже давно «не ваша». Я на это намекаю.

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

alex_sim ★★★★
()
Ответ на: комментарий от emorozov

Используется не как секрет (она не секретная)

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

soomrack ★★★★★
()
Ответ на: комментарий от alex_sim

Лет 20 уже использую базу данных с паролями собственного приготовления :))

ИМХО, текстовые файлы с именем сервиса удобнее. Ну а файлы держать на зашифрованном разделе созданном на файле.

Файлы с именем сервиса дают больше гибкости: гибкий поиск утилитой find, возможность как угодно и что угодно писать в них, организация в дерево директорий и пр.пр.пр. Опять же не требуется СУБД, а бекап осуществляется просто копированием файла.

soomrack ★★★★★
()
Ответ на: комментарий от anc

@anc по моему ваша фраза «Ваша система» может быть уже давно «не ваша». это уже ваш мем или штамп, я не силен в терминах, но многим вы это уже слово в слово говорили.

ORLY ?

Что это значит? не постесняюсь спросить пусть даже помидорами закидают.

И как вы себе предполагаете это «заметил»?

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

Теперь можно я спрошу? А как кто то может использовать мою систему, если наружу выставлена одна почта, даже забрать почту можно только локальным сеткам и моим белым IP все остальное в локалке работает внутри VPN WG. Ну такой я вот админ локалхоста или мамкин админ.

по моему страшилок и паранои больше чем реальных опасностей, вчера приходил анекдот:

Новые анекдоты
Все байки о могуществе русских хакеров сильно преувеличены, ещё ни одному их них не удалось взломать базу данных ЖКО, чтобы не платить квартплату.
alex_sim ★★★★
()
Ответ на: комментарий от soomrack

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

Поэтому радужные таблицы не составить - как их составишь, если соль у каждого пароля уникальная и случайная?

emorozov
()
Ответ на: комментарий от soomrack

Ну светить ее на весь мир все же не стоит,

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

alex_sim ★★★★
()
Ответ на: комментарий от soomrack

ИМХО, текстовые файлы с именем сервиса удобнее. Ну а файлы держать на зашифрованном разделе созданном на файле.

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

Опять же не требуется СУБД, а бекап осуществляется просто копированием файла

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

alex_sim ★★★★
()
Ответ на: комментарий от anc

А причём здесь «наружу» ?

Ну хорошо пусть внутренний враг завелся, хотя про своих пользователей я рассказал. Трояна могут зацепить и начать спамить не замечая того. Еще варианты? Апач? SSH только по ключу с парольной фразой.

alex_sim ★★★★
()
Ответ на: комментарий от emorozov

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

Если так, то да, это лучше всего.

Просто я часто встречал, что делают просто одну соль на все пароли, которая прописана в скрипте, а в бд только хэши.

soomrack ★★★★★
()
Ответ на: комментарий от soomrack

Просто я часто встречал, что делают просто одну соль на все пароли, которая прописана в скрипте, а в бд только хэши.

У меня именно так, соль одна на все записи, чтоб не забыть, правда я давно скриптом не пользуюсь, PHP на апаче заносит в базу, я завожу одну и ту же соль и одной солью я раскручиваю все записи сразу. Но еще раз повторюсь все это только в локалке, и только для меня.

alex_sim ★★★★
()
Ответ на: комментарий от alex_sim

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

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

В целом это очень просто.

truncate -s 1G my.keys
cryptsetup luksFormat my.keys
cryptsetup luksDump my.keys | less  # убедиться что все правильно, что chiper aes-xts-plain64
cryptsetup open my.keys keys
cryptsetup status keys
mkfs.ext4 /dev/mapper/keys
mount /dev/mapper/keys ~/my.keys

soomrack ★★★★★
()
Ответ на: комментарий от alex_sim

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

Ещё раз повторяю. Ты явно говоришь не о соли. Если мы говорим о безопасности, криптографии, то важно использовать правильные термины и понимать, что они значат.

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

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

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

emorozov
()

Зачем тебе вообще создавать пароли для этих пользователей? Пароли для людей создают (да и то спорно), а не для приложений.

vbr ★★★★
()