Jaký je nejlepší způsob, jak ukládat připojovací řetězec v .NET dll?

hlasů
14

Aplikace můj tým v současné době vyvíjí má DLL, který se používá k provádění veškeré přístup k databázi. Aplikace nelze použít důvěryhodné připojení, protože databáze je za firewallem a server domény není. Takže se zdá, že připojovací řetězec musí mít uživatelské jméno a heslo DB. DLL má v současné době připojovací řetězec databáze tvrdě kódované, ale nechci to udělat, když se spustí jako sestava může být demontována a uživatelské jméno a heslo by se tam pod širým nebem.

Jedním z požadavků je, že heslo je třeba změnit jednou za několik měsíců, takže bychom potřebovali vrátit, že se do naší vnitřní uživatelské základně.

Existuje způsob, jak ukládat hesla šifrované takovým způsobem můžeme snadno šířit do celé uživatelské základně, aniž by uložením do sestavy?

UPDATE: Díky všem, kdo odpověděl. Pokusím se odpovědět na některé otázky se zpátky ke mně ... Data DLL je používán jak ASP.NET WebForms a VB.NET WinForms. Chápu, že aplikace může mít vlastní konfigurační soubory, ale nemám nic na Konfigurační soubory DLL vidět. Bohužel, nemohu dostat na místo při práci Jon Galloway, takže nemohu posoudit, jestli to bude fungovat. Z vývojového hlediska nechceme používat webové služby inhouse, ale může být jejich poskytování třetím osobám někdy příští rok. Nemyslím, že zosobnění bude fungovat, protože nemůžeme ověřit uživatele přes firewall. Jako uživatel (nebo bývalý uživatel) může být útočník, budeme držet to od každého!

Položena 08/08/2008 v 17:32
zdroj uživatelem
V jiných jazycích...                            


8 odpovědí

hlasů
9

Nejsem si jistý, ale věřím, že si můžete dát do konfiguračního souboru a šifrování konfiguračního souboru.

Aktualizujte: Podívejte se Jon Galloway své místo zde.

Odpovězeno 08/08/2008 v 17:38
zdroj uživatelem

hlasů
3

Jen předpokládat, že protivníci dostanou pověření ze svého konfiguračního souboru. To znamená, že by bylo možné se přihlásit do databáze a dělat, co je uživatel schopen. Takže jen ujistit, že uživatel nemůže udělat nic špatného jako je přístup tabulky přímo. Dělat, že uživatel pouze schopna realizovat určité uložené procedury a budete v lepším stavu. To je jedno místo, které sprocs lesk.

Odpovězeno 25/08/2008 v 06:12
zdroj uživatelem

hlasů
1

Nerad to říkám, ale jakmile si dát něco na klientském počítači, zabezpečení těchto dat jde ven z okna.

Pokud váš program bude dešifrovat tento řetězec, je třeba předpokládat, že útočník může udělat totéž. Nasazení debugger pro váš program by být jedním ze způsobů.

Ukládání řetězec připojení k serveru a získat ho prostřednictvím webového připojení zní dobře, až si uvědomíte, že budete potřebovat bezpečnost na této webové připojení stejně, jinak by útočník mohl stejně dobře vydávat svůj program a mluvit na připojení k Internetu.

Dovolte mi, abych na něco zeptat. Kdo se schováváš řetězec připojení z? Uživatel nebo útočník? A je-li uživatel, proč?

Odpovězeno 08/08/2008 v 18:12
zdroj uživatelem

hlasů
0

Několik možností:

  1. Skladovat v web.config a šifrování
  2. Skladovat v dll a poplést (Dotfuscator)
  3. Uložení jeden v web.config (šifrované samozřejmě) a odpočinku v databázi (pokud budete muset použít vícenásobné a šifrování / dešifrování se stává bolest)
Odpovězeno 14/04/2009 v 15:20
zdroj uživatelem

hlasů
0

Chcete-li být schopni distribuovat DLL s veškerými informacemi o nastavení Být v konfigurovatelné místě, ale faktem je, že nemůžete mít jednu z NET konfigurační soubory handy-dandy pro DLL, pokud děláte něco vlastní.

Možná budete muset přehodnotit, co odpovědnost vaše DLL by měl mít. Bylo by to možné, nebo smysl požadovat, aby připojovací řetězec předán do uživatelem knihovny? Má to opravdu smysl, že vaše DLL přečte konfigurační soubor?

Odpovězeno 08/08/2008 v 18:40
zdroj uživatelem

hlasů
0

NET podporuje šifrování na konfigurační hodnoty, jako je tento. Dalo by se nechat v konfiguračním souboru, ale šifrována.

Odpovězeno 08/08/2008 v 18:30
zdroj uživatelem

hlasů
0

Existuje nějaký jiný nápad je také. Vždy se můžete použít zosobnění. Také můžete použít (společné knihovny) podnik knihovny.

<section name="enterpriseLibrary.ConfigurationSource" type="Microsoft.Practices.EnterpriseLibrary.Common.Configuration.ConfigurationSourceSection, Microsoft.Practices.EnterpriseLibrary.Common, Version=3.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
<enterpriseLibrary.ConfigurationSource selectedSource="Common">
<sources>
  <add name="Common" type="Microsoft.Practices.EnterpriseLibrary.Common.Configuration.FileConfigurationSource, Microsoft.Practices.EnterpriseLibrary.Common, Version=3.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
    filePath="Config\Exception.config" />
</sources>

Odpovězeno 08/08/2008 v 18:28
zdroj uživatelem

hlasů
0

Pokud aplikace je ASP.NET aplikací pak stačí zašifrovat část řetězce připojení vašeho web.config.

V případě, že aplikace je klientská aplikace běžící na více počítačích, místo ukládání řetězec připojení lokálně, zvažte použití webové služby, nebo nějaký jiný druh bezpečného mechanismu, který by jej uložit centrálně. To by usnadnilo jednodušší aktualizace v budoucnosti a nejste ukládání řetězec připojení lokálně.

Jen některé myšlenky.

Aktualizováno: @ lassevk

„Ukládání řetězec připojení k serveru a získat ho prostřednictvím webového připojení zní dobře, až si uvědomíte, že budete potřebovat bezpečnost na této webové připojení stejně, jinak by útočník mohl stejně dobře vydávat svůj program a mluvit na připojení k Internetu. "

Zabezpečení webové služby byl implicitní. V závislosti na typu nasazení existuje mnoho možností ... na boční certifikáty příklad klienta.

Odpovězeno 08/08/2008 v 17:44
zdroj uživatelem

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more