Care este cel mai bun mod de stocare a șirului de conexiuni în .NET DLL-uri?

Aplicația pe care echipa mea o dezvoltă în prezent are un DLL care este folosit pentru a efectua accesul la toate bazele de date. Aplicația nu poate utiliza o conexiune de încredere deoarece baza de date se află în spatele unui paravan de protecție și serverul de domeniu nu este. Se pare că șirul de conectare trebuie să aibă un nume de utilizator DB și o parolă. DLL are în prezent șirul de coduri de bază de date codat greu, dar nu vreau să fac acest lucru când lansez ca asamblarea poate fi dezasamblată și numele de utilizator și parola ar fi chiar acolo în aer liber.

Una dintre cerințe este că parola trebuie schimbată o dată la fiecare câteva luni, așa că ar trebui să reintroducem baza de date internă.

Există o modalitate de a stoca parola criptată astfel încât să putem distribui cu ușurință întreaga bază de utilizatori fără a fi stocată în ansamblu?

UPDATE: Vă mulțumim tuturor celor care au răspuns. Voi încerca să răspund la câteva întrebări înapoi la mine ... DLL-ul de date este folosit de ambele ASP.NET WebForms și VB.NET WinForms. Înțeleg că aplicațiile pot avea propriile fișiere de configurare, dar nu am văzut nimic despre fișierele de configurare pentru DLL-uri. Din păcate, nu pot ajunge la postul Jon Galloway la locul de muncă, așa că nu pot să judec dacă acest lucru va funcționa. Din punctul de vedere al dezvoltării, nu vrem să folosim serviciile web inhouse, ci să le furnizăm unor terți cândva anul viitor. Nu cred că împodobirea va funcționa deoarece nu putem autentifica utilizatorul prin firewall. Ca un utilizator (sau fostul utilizator) poate fi un atacator, îl păstrăm de la toată lumea!

0
fr hi bn

7 răspunsuri

.NET acceptă criptarea valorilor config. Ai putea să o lăsați într-un fișier de configurare, dar criptat.

0
adăugat

Nu sunt sigur, dar cred că puteți să-l puneți într-un fișier de configurare și să criptați fișierul de configurare.

Update: See Jon Galloway's post here.

0
adăugat
@JasonSperske - Am actualizat linkul. Voi rezuma în scurt timp.
adăugat autor Adam V, sursa
Actualizarea nu indică nimic altceva, dacă puteți găsi informațiile pe care le-ați referit și le-ați pus în acest răspuns, atunci ar supraviețui pentru totdeauna (sau cât mai curând saturația stivei devine absorbită de soare)
adăugat autor Jason Sperske, sursa

Nu-mi place să spun asta, dar de îndată ce puneți ceva pe o mașină client, securitatea pentru acele date iese pe fereastră.

Dacă programul vostru va decripta șirul, trebuie să presupuiți că un atacator poate face același lucru. Atașarea unui program de depanare la programul dvs. ar fi într-un fel.

Stocarea șirului de conectare pe un server și obținerea acestuia printr-o conexiune Web sună bine până când îți dai seama că ai nevoie de securitate și pe acea conexiune web, altfel un atacator ar putea să-și imite programul și să vorbească cu conexiunea Web.

Permiteți-mi să pun o întrebare. Cui ascundeți șirul de conexiune? Utilizatorul sau un atacator? Și dacă utilizatorul, de ce?

0
adăugat

Există și alte idei. Puteți folosi întotdeauna uzurparea identității. De asemenea, puteți utiliza Biblioteca Enterprise (Biblioteca Comună).

0
adăugat

Dacă aplicația este o aplicație ASP.NET, atunci trebuie doar să criptați secțiunea de coduri de conectare din web.config .

Dacă aplicația este o aplicație client care rulează pe mai multe mașini, în loc să stocheze șirul de conectare local, luați în considerare utilizarea unui serviciu web sau a unui alt tip de mecanism securizat pentru ao stoca la nivel central. Acest lucru ar facilita actualizarea mai ușoară în viitor și nu stocați șirul de conexiune la nivel local.

Doar câteva gânduri.

Updated: @lassevk

"Stocarea șirului de conectare pe un server și obținerea acestuia printr-o conexiune web sună bine până când îți dai seama că ai nevoie și de securitate pe acea conexiune web, în ​​caz contrar un atacator ar putea să se imortalizeze la fel de bine în programul tău și să vorbească cu conectare web. "

Securitatea serviciului web a fost implicită. În funcție de tipul de implementare, există numeroase opțiuni ... de exemplu certificate de client.

0
adăugat

Doriți să fiți în măsură să distribuiți DLL-ul cu toate informațiile de configurare într-un loc configurabil, dar este adevărat că nu puteți avea unul din fișierele config nietate .NET pentru un DLL dacă nu faceți ceva personalizat.

Poate că trebuie să regândiți ce responsabilitate ar trebui să aibă DLL-ul dvs. Ar fi posibil sau este logic să cereți ca șirul de conexiune să fie transmis de utilizatorul bibliotecii dvs.? Are sens cu adevărat că DLL-ul dvs. citește un fișier de configurare?

0
adăugat

Doar presupuneți că băieții răi vor obține acreditările din dosarul dvs. de configurare. Acest lucru înseamnă că ei vor putea să se conecteze la baza de date și să facă ceea ce este capabil de acel utilizator. Deci, asigurați-vă că utilizatorul nu poate face nimic rău cum ar fi accesul la mese direct. Faceți acel utilizator capabil doar să execute anumite proceduri stocate și veți fi în formă mai bună. Acesta este un loc care straluceste.

0
adăugat
Întotdeauna încerc să limitez autentificarea SQL pentru aplicațiile web pe care am lucrat în cât mai multe moduri posibile.
adăugat autor Matt Blaine, sursa