Utilizarea DPAPI/ProtectedData într-un mediu de exploatație web cu magazinul de utilizatori

Mă întrebam dacă cineva a folosit cu succes DPAPI cu un magazin de utilizatori într-un mediu de exploatare web?

Deoarece aplicația noastră este o aplicație ASP.NET de 1.1 - 2.0 convertită recent, folosim un pachet personalizat care apelează direct metodele CryptUnprotect . Dar aceasta ar trebui să fie aceeași cu metoda ProtectedData </​​code> disponibilă în cadrul 2.0.

Deoarece lucrăm într-un mediu web de fermă, nu putem garanta că mașina care a făcut criptarea va fi cea care o decriptează. (De asemenea, deoarece eșecurile mașinilor nu ar trebui să distrugă datele criptate).

Deci, ceea ce avem este o componentă deservită care rulează într-un serviciu sub un anumit cont de utilizator pe fiecare dintre casetele noastre web. Acest utilizator este configurat pentru a avea un profil de roaming, conform recomandării.

Problema pe care o avem este aceea că informația criptată pe o singură mașină nu poate fi decriptată pe alta, aceasta nu reușește cu eroarea win32:

'Cheia nu este valabilă pentru utilizarea în starea specificată'.

Suspectez că acest lucru se datorează faptului că am făcut o greșeală prin faptul că serviciul de criptare rulează ca utilizator pe mai multe mașini, prin urmare, menținând utilizatorul conectat la mai multe mașini în același timp.

Dacă aceasta este problema, cum sunt alte persoane care utilizează DPAPI cu Magazinul utilizator într-un mediu de exploatație web?

 3
adăugat editat
Vizualizări: 2
sursa
ru fr es pt de zh hi bn ar
Bună, ai primit răspunsul la asta? Am aceeași problemă.
adăugat autor user6535, sursa

3 răspunsuri

Într-un mediu de exploatație web, mai degrabă decât să utilizați DPAPI pentru criptarea/decriptarea datelor direct, l-ați folosi pentru a cripta cheia pe care o utilizați mai târziu pentru a decripta datele protejate.

Veți instala "cheia pe fiecare server ca parte a procesului de implementare. Scriptul de instalare ar trebui să ruleze sub identitatea AppPool și ar putea stoca cheia criptată fie într-un fișier app.config, fie în registru.

Datele criptate în sine pot fi stocate într-un depozit central/bază de date, astfel încât să poată fi accesate de către toate serverele din fermă. Pentru a decripta datele, aplicația web va prelua cheia criptată de unde a fost instalată, folosiți DPAPI pentru ao decripta, apoi utilizați rezultatul pentru a decripta datele care provin din depozitul central.

Dezavantajul este că cheia de text clar poate exista pe discul local pentru o perioadă scurtă de timp în timpul procesului inițial de instalare, unde ar putea fi expus la personalul de operațiuni. Ai putea adăuga un strat suplimentar de criptare, cum ar fi cu web.config machineKey, dacă asta eo problemă.

8
adăugat
sursa
Acest lucru este nefericit, deoarece unul dintre avantajele DPAPI este faptul că expiră automat cheia master la fiecare 3 luni, dar este capabil să decripteze datele criptate anterior. msdn.microsoft.com/en-us/library/ms995355.aspx Citat: "Această expirare împiedică un atacator să compromită un singur MasterKey și să acceseze toate datele protejate de utilizator". Utilizând propria cheie dacă este compromisă, toate datele sunt expuse.
adăugat autor ToddK, sursa
Acesta este un pic cam invechit, dar cred ca veti putea inca "vedea" cheia chiar daca este continut in web.config si criptat folosind aspnet_regiis . Abordarea dvs. este ceea ce majoritatea oamenilor caută, deoarece nu există un mecanism similar în afara ASP.NET sau BCL.
adăugat autor CodeMonkeyKing, sursa

Tocmai am văzut asta. Există o modalitate prin care puteți face acest lucru, și anume asigurați-vă că mașinile din fermă se află într-un domeniu și utilizați un cont de domeniu pentru a cripta și decripta datele (de exemplu, rulați aplicația în contul de domeniu)

Nu puteți utiliza DPAPI așa cum doriți cu conturile locale, deoarece materialul cheie nu este schimbat între servere.

speranța că ajută!

2
adăugat
sursa

The Microsoft poster is wrong. http://support.microsoft.com/default.aspx?scid=kb;en-us;309408#6

"Pentru ca DPAPI să funcționeze corect atunci când utilizează profiluri de roaming, utilizatorul domeniului trebuie să fie conectat la un singur computer din domeniu. Dacă utilizatorul dorește să se conecteze la alt computer aflat în domeniu, utilizatorul trebuie să se deconecteze primul computer înainte ca utilizatorul să se conecteze la cel de-al doilea calculator. Dacă utilizatorul este conectat la mai multe computere în același timp, probabil că DPAPI nu va putea să decripte corect datele criptate existente. "

Se pare că DPAPI nu va funcționa într-un cadru agricol. Cred că aceasta este o supraveghere destul de mare din partea Microsoft și face DPAPI aproape inutil pentru majoritatea aplicațiilor pentru întreprinderi.

1
adăugat
sursa