Приветствую всех,

Возник вопрос. Есть некий класс который является фабрикой DB подключений(DbContext).
В нем сейчас захаркодены имена пользователей и пароли к базам данных. Для всех баз разные имя пользователя и пароль. Интегрированную авторизацию использовать неполучится.
Возник вопрос шифрования этой части строк. Мы можем зашифровать и записать, например, в конфиг, но чтобы восстановить данные опять придется хранить ключ для дешифрации в коде... что в общем то ни отчего не защищает...
Что можно сделать в этой ситуации?

Заранее спасибо.

Здравствуйте, Аноним, Вы писали:

А>Приветствую всех,

А>Возник вопрос. Есть некий класс который является фабрикой DB подключений(DbContext).
А>В нем сейчас захаркодены имена пользователей и пароли к базам данных. Для всех баз разные имя пользователя и пароль. Интегрированную авторизацию использовать неполучится.
А>Возник вопрос шифрования этой части строк. Мы можем зашифровать и записать, например, в конфиг, но чтобы восстановить данные опять придется хранить ключ для дешифрации в коде... что в общем то ни отчего не защищает...
А>Что можно сделать в этой ситуации?

А>Заранее спасибо.


http://msdn.microsoft.com/en-us/library/system.configuration.sectioninformation.protectsection.aspx

оно?

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Аноним, Вы писали:

А>>Приветствую всех,

А>>Возник вопрос. Есть некий класс который является фабрикой DB подключений(DbContext).
А>>В нем сейчас захаркодены имена пользователей и пароли к базам данных. Для всех баз разные имя пользователя и пароль. Интегрированную авторизацию использовать неполучится.
А>>Возник вопрос шифрования этой части строк. Мы можем зашифровать и записать, например, в конфиг, но чтобы восстановить данные опять придется хранить ключ для дешифрации в коде... что в общем то ни отчего не защищает...
А>>Что можно сделать в этой ситуации?

А>>Заранее спасибо.


А>http://msdn.microsoft.com/en-us/library/system.configuration.sectioninformation.protectsection.aspx

А>оно?

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

Здравствуйте, ZloeBablo, Вы писали:



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

не совсем так

http://msdn.microsoft.com/en-us/library/53tyfkaw.aspx

А>Что можно сделать в этой ситуации?
Описанную архитектуру можно захачить десятком способов и без рефлектора. Тупо отладчик на методы вашего DbContext повесить, и будет начхать на метод шифрования, то хранили ли вы ключи в программе, использовали какой-нить hard-lock, или кинули их plaintext в конфиг.

Здравствуйте, hi_octane, Вы писали:

А>>Что можно сделать в этой ситуации?
_>Описанную архитектуру можно захачить десятком способов и без рефлектора. Тупо отладчик на методы вашего DbContext повесить, и будет начхать на метод шифрования, то хранили ли вы ключи в программе, использовали какой-нить hard-lock, или кинули их plaintext в конфиг.

Нет проблем. Я тоже вижу эту проблему. т.е. фабрику никак не защитить получается?

А>Нет проблем. Я тоже вижу эту проблему. т.е. фабрику никак не защитить получается?

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