none
maskování hesel pro připojení k DB

    Dotaz

  • Dobrý den,

    Máme aplikace v .NET 1.1 (migrujeme na 2.0) a přitom řešíme takový malý problém. Pokud na naší DBSingltonovou DLL pouzijene reflector a dessasemblujeme ji, tak lze přečíst naše připojovací údaje k DB.

    Máme je jako protected static string;

    Lze toto nejak maskovat?

    Zkoušeli jsme to naplnit v konstruktoru skladaním, ale efekt je stejný.

    Děkuji za odpověď,

    Ondřej EDA Šeda
    pondělí 10. září 2007 8:21

Odpovědi

  • Šifrování connection-stringu pomocí DPAPI je určitě věc dobrá, nicméně je určená pouze pro určité scénáře. K zašifrování connection-stringu musí dojít na stroji, kde bude connection-string používán a na stejném stroji může dojít i k jeho rozšifrování. Je to prakticky jen takové ztížení pozice.

     

    Úplné ochrany nedosáhnete, dokud bude vaše aplikace potřebovat pro přístup k DB své heslo, které bude mít někde uloženo. Jedinou šancí je ptát se na heslo uživatele, popř. používat pro připojení k DB integrated-security či podobné techniky.

     

    Hodně tedy záleží, čeho chcete dosáhnout. Šifrování connection-stringu je dobrým scénářem pro serverové části aplikací, např. webové servery a jejich web.configy, kdy máte server pod ochrannou a connection-string chráníte "v druhé linii". Pro tlusté klienty instralované na jednotlivých stanicicích to však není moc použitelné a tam se volí integrated-security a práva na úrovni jednotlivých uživatelů.

    pondělí 10. září 2007 20:57
    Moderátor
  • Dobrý den,

     

    binární serializace se nesnaží o nějaké šifrování, je to pouze lidsky nečitelné kódování. Obecně lze říci, že pokud je vaše aplikace schopna se k datům dostat, je toho schopen i uživatel (znalý problematiky), pod kterým aplikace beží. A je úplně jedno jak tato data schováte. Různá řešení se liší pouze tím, jak těžké je k datům se dostat.

     

    Jedním z řešení, které mi napadá, je aby vaše aplikace neběžela v kontextu koncového uživatele, ale v kontextu nějakého jiného účtu. Poté lze v prostředí Windows nastavit přístupová práva tak, aby uživatel nemohl číst data v paměti vaší aplikace. (Například, část, které komunikuje s databází by běžela jako systémová služba).

    Toto ale vyžaduje, aby koncový uživatel nebyl správce systému a aby jste naopak vy měl plnou kontrolu na systémem.

    Poté by vaše heslo mohlo být uloženo v souboru, ke kterému nemá bežný uživatel přístup, ale vaše služba ano.

     

    S pozdravem,

    středa 28. listopadu 2007 10:11
  • Doporučuji do vyhledávače zadat .NET Obfuscator OR Dotfuscator, není to ZCELA bezpečné, ale ono jde stejně vždy jen o přiměřenost obrany/ochrany.. A k ověření doporučuji Reflector. A aby jste to případnému čumílkovi ještě zněmpříjemnil, nebojte se nadělat tám nemálo fake proměnných, které nebudou nikdy použity, ale ve spojení s obfuscatorem vytvoří takový zmatek, že už se v tom nikdo nevyzná. Dále můžete použít i běžné šifrovací algoritmy (AES), obdobně "schovat" klíč... atd. atd. nezní to sice moc bezpečně, ale věřte mi, že tento způsob je mnohdy více než dostačující. Nakonec máte i možnost schovat to do nativní knihovny a volat ji přes PInvoke, ale i tak si o moc nepomůžete, decompilerům kódu kompilovaného z C/C++ to trvá jen o něco déle, ale za pár hodin dosáhnou podobného výsledku.
    čtvrtek 10. ledna 2008 8:52

Všechny reakce

  • Dobry den,

    resenim je urcite connection string zasifrovat. Otazkou je, jaky zpusob zvolit.
    Moznost je napriklad zasifrovany connection string ulozit v settings pri/po instalaci na stanici. Zkuste se podivat napr. na nasledujici odkazy:

    http://www.codeproject.com/useritems/Configuration_File.asp
    http://www.codeproject.com/csharp/encryptstrings.asp
    http://blogs.msdn.com/shawnfa/archive/2004/05/05/126825.aspx
    http://msdn2.microsoft.com/en-us/library/ms995355.aspx

    Lubos Hladik
    pondělí 10. září 2007 9:09
  • Šifrování connection-stringu pomocí DPAPI je určitě věc dobrá, nicméně je určená pouze pro určité scénáře. K zašifrování connection-stringu musí dojít na stroji, kde bude connection-string používán a na stejném stroji může dojít i k jeho rozšifrování. Je to prakticky jen takové ztížení pozice.

     

    Úplné ochrany nedosáhnete, dokud bude vaše aplikace potřebovat pro přístup k DB své heslo, které bude mít někde uloženo. Jedinou šancí je ptát se na heslo uživatele, popř. používat pro připojení k DB integrated-security či podobné techniky.

     

    Hodně tedy záleží, čeho chcete dosáhnout. Šifrování connection-stringu je dobrým scénářem pro serverové části aplikací, např. webové servery a jejich web.configy, kdy máte server pod ochrannou a connection-string chráníte "v druhé linii". Pro tlusté klienty instralované na jednotlivých stanicicích to však není moc použitelné a tam se volí integrated-security a práva na úrovni jednotlivých uživatelů.

    pondělí 10. září 2007 20:57
    Moderátor
  • Bohuzel z vlastni zkusenosti vim, ze ukladani hesel (resp. cele connection-stringy) primo na stanicich je pomerne casta praxe.

    Sifrovani cehokoliv pomoci DPAPI ma ale jeden velice dulezity aspekt, ktery jsme zde jeste nezmili. Text zasifrovany pomoci DPAPI sice jiny uzivatel (v pripade klice vazaneho na uzivatele, druhou moznosti je klic vazany na pocitac) ani stejny uzivatel na jine stanici nerozsifruje, ale uzivatel, pod kterym byl text zasifrovan, si ho pomerne snadno sam kdykoliv rozsifruje. Bezny uzivatel samozrejme ne, ale uzivatel znaly problematiky ano.

    Jak jiz nastinil Robert, ukladani hesel pro pristup do databaze na stanicich neni dobre.

    Samotneho by me ale zajimalo, jestli je nejaky cesta, jak ukladat podobne citlive informace primo na stanicich nejakym zarucene bezpecnym zpusobem. Napr. pokud se aplikace pripojuje k ruznym jinym sluzbam nebo systemum bez zasahu uzivatele.

    Lubos Hladik
    úterý 11. září 2007 11:24
  • DD,

    tato diskuze mne navádí na myšlenku užití privátního klíče, který si bude držet aplikace a public klíče pomocí kterého bude možné do konfiguračního souboru zašifrovat heslo (dalo by se to poté aplikovat na zašifrování licenčního klíče určující datum expirace atd.).

    Otázka je zda to není řešení cyklem (schování public klíče).

    Nevíte jak je provedena bezpečnost u binární serializace objektů?
    Napadlo mne si serializovat třídu obsahující informace pro připojení a tu při startu aplikace deserializovat.

    Děkuji za podněty

    Ondřej EDA Šeda
    středa 12. září 2007 9:03
  •  Robert Haken napsal:

    Úplné ochrany nedosáhnete, dokud bude vaše aplikace potřebovat pro přístup k DB své heslo, které bude mít někde uloženo. Jedinou šancí je ptát se na heslo uživatele, popř. používat pro připojení k DB integrated-security či podobné techniky.

    Aplikace je navržena tak, že se pro DB hlásí jako jeden uživatel. Bohužel tuto skutečnost nemohu nikterak ovlivnit, neboť na to nemám kompetence.

     Robert Haken napsal:

    Pro tlusté klienty instralované na jednotlivých stanicicích to však není moc použitelné a tam se volí integrated-security a práva na úrovni jednotlivých uživatelů.


    Model jednoho uživatele byl prý zvolen kvůli správě uživatelů a jednodušímu udělování práv, které z pohledu DB řešit pro naše akce nelze.
    středa 12. září 2007 9:11
  •  EDA Seda napsal:

    tato diskuze mne navádí na myšlenku užití privátního klíče, který si bude držet aplikace a public klíče pomocí kterého bude možné do konfiguračního souboru zašifrovat heslo (dalo by se to poté aplikovat na zašifrování licenčního klíče určující datum expirace atd.).


    Zase ale narazite na stejny problem - jak bezpecne ulozit privatni klic... Pokud ho "zna" Vase aplikace, pak bude pouzitelny i z jine aplikace a connection string tak je zase zjistitelny.
    pondělí 17. září 2007 8:51
  • DD,

    ano tuto myšlenku jsem zmínil, že to je řešení cyklem.

    Nevíte jak je to s tou binární serializací objektů? Ja tam nějaká ochrana proti rozkódování obsahu?

    Ondřej EDA Šeda
    čtvrtek 20. září 2007 7:08
  • Dobrý den,

     

    binární serializace se nesnaží o nějaké šifrování, je to pouze lidsky nečitelné kódování. Obecně lze říci, že pokud je vaše aplikace schopna se k datům dostat, je toho schopen i uživatel (znalý problematiky), pod kterým aplikace beží. A je úplně jedno jak tato data schováte. Různá řešení se liší pouze tím, jak těžké je k datům se dostat.

     

    Jedním z řešení, které mi napadá, je aby vaše aplikace neběžela v kontextu koncového uživatele, ale v kontextu nějakého jiného účtu. Poté lze v prostředí Windows nastavit přístupová práva tak, aby uživatel nemohl číst data v paměti vaší aplikace. (Například, část, které komunikuje s databází by běžela jako systémová služba).

    Toto ale vyžaduje, aby koncový uživatel nebyl správce systému a aby jste naopak vy měl plnou kontrolu na systémem.

    Poté by vaše heslo mohlo být uloženo v souboru, ke kterému nemá bežný uživatel přístup, ale vaše služba ano.

     

    S pozdravem,

    středa 28. listopadu 2007 10:11
  • Doporučuji do vyhledávače zadat .NET Obfuscator OR Dotfuscator, není to ZCELA bezpečné, ale ono jde stejně vždy jen o přiměřenost obrany/ochrany.. A k ověření doporučuji Reflector. A aby jste to případnému čumílkovi ještě zněmpříjemnil, nebojte se nadělat tám nemálo fake proměnných, které nebudou nikdy použity, ale ve spojení s obfuscatorem vytvoří takový zmatek, že už se v tom nikdo nevyzná. Dále můžete použít i běžné šifrovací algoritmy (AES), obdobně "schovat" klíč... atd. atd. nezní to sice moc bezpečně, ale věřte mi, že tento způsob je mnohdy více než dostačující. Nakonec máte i možnost schovat to do nativní knihovny a volat ji přes PInvoke, ale i tak si o moc nepomůžete, decompilerům kódu kompilovaného z C/C++ to trvá jen o něco déle, ale za pár hodin dosáhnou podobného výsledku.
    čtvrtek 10. ledna 2008 8:52