Требуется хранить пароль в базе — как?

Question

[iliyaisd]

Задача слегка нетривиальная, проект требует хранить на своей стороне пароль пользователя от определённого ресурса (т.к. ресурс не имеет API, и нам надо хранить credentials пользователя, чтобы вытаскивать с него постоянно информацию).
Вопрос, как это лучше делать, чтобы хотя бы не совсем в открытом виде? Как-то шифровать в БД, а ключ класть отдельно?
Спасибо.

Comments

[wiz]

Пароли в базе хранить нельзя. А знаете что ещё нельзя делать? Колхозить свою криптографию.

https://www.vaultproject.io/

Answer 1

[D']

Все варианты выше: не дают приемлемой защиты от кражи данных. Получив доступ к серверу, я смогу без проблем получить доступ ко всем паролям которые хранятся в "открытом" виде.

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

Тогда даже если я получу доступ к основному серверу, я физически не смогу достать открытые пароли пользователей. Максимум что я смогу - навредить, удалив эти данные. Но это я могу сделать и на основном сервере.

Comments

[iliyaisd]

Да, так действительно лучше всего.

[xmoonlight]

iliyaisd: Полностью согласен с D' Normalization !

[iliyaisd]

Посоветуйте, пож-та, ещё, на чём лучше всего писать API сервер? Любой фреймворк + REST архитектура, отдающая JSON/XML?

[D']

iliyaisd: можно использовать любой подходящий инструмент. Главно не наплодить там багов, иначе толку от него будет 0.

[D']

iliyaisd: главное чтобы этот сервер ни при каких обстоятельсвах не возвращал пары логин\пароль. Вся работа с внешним сервисом должна идти на этом сервере, и от него уже получать готовые ответы.

[Котик Антон]

Не понял, и что же это реально даёт: было нужно взломать один сервер, теперь - другой. Разница то в чём?

[iliyaisd]

27cm: найти уязвимость в основном сервере гораздо проще (баг в сайте, неосторожность пользователя). Плюс, надо взломать два сервера, т.к. для понимания, что их два, надо вначале взломать первый.

[Котик Антон]

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

[D']

27cm: пользователи вводят открытые данные только 1 раз (на сколько я понял), так что собрать данные активных пользователей не выйдет.
Возможно получится собрать данные новые пользователей, но к этому времени взломщика возможно заметят и ликвидируют. Угроза будет не так страшна.

Answer 2

[Stalker_RED]

Да, как-то шифровать, и ключ хранить отдельно. Можно еще соль добавить.

mcrypt или OpenSSL

Можно создать пару ключей, шифровать публичным ключом, а расшифровывать личным. Запуск крона из-по-другого ползователя, и доступ к ключу только у него. Таким образом, если злоумышленник добрался до базы - ключа у него нет. Если залил шеллскрипт и работает под www-data - тоже ключа нет. Точнее есть публичный, для зашифровки, но ключ для расшифровки под другим юзером. Но, конечно, если доберется до рута - всё.

Comments

[iliyaisd]

Спасибо!

Answer 3

[Androguide]

php.net/manual/ru/faq.passwords.php

Пользуйтесь тем что дает язык.
php.net/manual/ru/function.password-hash.php

Comments

[iliyaisd]

Хеширование мне не подходит, т.к. нужна двусторонняя операция.

Answer 4

[Дмитрий]

Вариант решения: шифруйте все данные для доступа к третьему ресурсу с помощью пароля пользователя для доступа к вашему сайту, а сам пароль в базе не храните.
При авторизации расшифровываем данные и кладём во временное хранилище в памяти.

Comments

[iliyaisd]

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

[iliyaisd]

Или Вы имеете в виду, что в самом пароле пользователя и зашит доступ к третьему ресурсу?

[Дмитрий]

вы что, храните пароль пользователя от сайта в открытом виде?

[iliyaisd]

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

[Дмитрий]

1. habrahabr.ru/post/139974
2. #oauth2 если внешний ресурс позволяет

[iliyaisd]

Дмитрий: пароль пользователя, конечно же, не храню в открытом виде. Oauth2 не подходит (как написал уже, ресурс не имеет подходящего API). Хранить нужно только пароли к третьему ресурсу, и использоваться они будут периодично (в cron скрипте).

[Дмитрий]

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

[iliyaisd]

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

[Дмитрий]

Используйте ключ, зависимый от пользователя. Составной, может быть. Вторая база - тоже вариант. Например основная база мускуль, вторая - редис/монго.

[iliyaisd]

Да, наверное что-то из этого стоит использовать.

[Stalker_RED]

iliyaisd: Про ключи добавил в свой ответ.

[Harbid Abu Marhamedoff]

Все закрытые данные хранить зашифрованными паролем пользователя, открытые хранить открытыми. Забыл чел пароль - его проблема, вводит новый пароль и все зашифрованные данные вводит заново :) Ну а если обратятся "компетентные органы" - вот вам данные, расшифровывайте! :)

Answer 5

[BorisIvanov]

можно шифровать пароли следующим образом

CREATE OR REPLACE FUNCTION el_encrypt
(
	value text
)
RETURNS bytea
AS $BODY$
BEGIN
	RETURN pgp_pub_encrypt(value, dearmor(pg_read_file('pgpkeys/pgp-pg-el-public.key')));  
END;
$BODY$ LANGUAGE plpgsql
SECURITY DEFINER;

расшифровывать

CREATE OR REPLACE FUNCTION el_decrypt
(
	value bytea
) RETURNS text AS 
$BODY$
BEGIN
 RETURN pgp_pub_decrypt(value, dearmor(pg_read_file('pgpkeys/pgp-pg-el-private.key')));
END;
$BODY$
LANGUAGE plpgsql
SECURITY DEFINER;

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

Answer 6

[akzhan]

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