Puncte:0

Protejați PII în tranzit prin comparație hash

drapel us

Mi se cere să ofer o soluție pentru clientul meu intern. Toată comunicarea în rețea este internă și nicio aplicație și nici serverele acestora nu sunt accesibile prin internet.

  • Aplicația SOLICITANT va avea o listă de SSN-uri pentru peste 1000 de persoane pentru care au nevoie de informații (listă diferită de peste 1000 în fiecare zi).
  • Aplicația REPORTER poate rula interogări SQL și poate oferi rezultate formatate.
  • Aplicația DATAOWNER are informațiile necesare, stocate într-un RDBS, inclusiv o coloană SSN cu text simplu.

Solicitantul nu poate solicita direct informațiile de la DATAOWNER. Singura modalitate pe care o are SOLICITARUL de a solicita informații este prin intermediul unei adrese URL către REPORTER. Acolo intru eu.

Nu am capacitatea de a schimba capacitățile/configurarea aplicațiilor SOLICITĂTORULUI sau PROPRIETĂTORUL DE DATE, în afară de a oferi informații către SOLICITANT, despre cum să pregătesc și să formateze adresa URL.

Pot crea un raport și pot configura REPORTER să accepte o adresă URL similară https://REPORTER/TheReport?argument1=123456789 Totuși, nu vreau SSN-ul de pe URL în text simplu, deoarece va fi autentificat în jurnalele web ale REPORTER și cine știe unde altundeva.

Ideea mea pentru o soluție este ca REQUESTOR să facă un hash SHA256 al unei concatenări a SSN-ului și o valoare secretă care se schimbă periodic și să folosească acel digest pe URL. Când REPORTER primește cererea, efectuează o interogare SQL împotriva DATAOWNER ca (pseudocod):

selectați [DesiredFields] din tabel

unde SHA256FUNCTION(CONCATENATE([SSNcolumn],<TheSecretValue>)) = $argument1.

Cred că acest lucru nu adaugă niciun risc de expunere a SSN-urilor, deoarece toate procesările care utilizează valorile text clar au loc pe servere care au deja acces la acestea în text simplu. Aplicația REPORTER nu vede niciodată SSN-ul text simplu în mod direct, deși trebuie să transmită rezultatul interogării SQL, care poate include sau nu SSN-ul. Cu toate acestea, datorită designului software al REPORTER, nu sunt stocate rezultate ale interogării sau rezultate formatate.

Deși sunt familiarizat cu unele aspecte ale cripto, cu siguranță nu sunt un expert. Aș aprecia orice comentarii despre această abordare, fie bune, fie rele. Mulțumesc

fgrieu avatar
drapel ng
Este ușor să găsești un SSN din hash-ul lui SHA-256, deoarece SSN-urile sunt atât de puține.
drapel us
Am avut același gând. Un tabel de căutare numai împotriva SSN-urilor ar fi ușor de făcut pentru un atacator. Concatenarea acestuia cu o valoare secretă înainte de a efectua hash-ul a fost gândul meu despre cum să atenuez acest risc.
bk2204 avatar
drapel fr
Dacă aveți nevoie de o componentă secretă, este mult mai bine să utilizați HMAC-SHA-256 decât să concatenați un secret, deoarece există o varietate de modalități de a crea abordări nesigure cu concatenarea cu SHA-256.
drapel in
Privind asta. Mulțumesc pentru sugestie, bk.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.