SQL Server har muligheten til å kryptere forbindelsen mellom applikasjon og database. Når du bruker SQL-server i et ikke-klarert miljø, anbefales det at du aktiverer den. Når du gjør det, er det unødvendig å hashe passordene før du sender dem til databasen så lenge du stoler på DB-administratoren.

I tillegg vil de fleste distribusjoner av SQL-server ha en applikasjonsserver i en DMZ og SQL-serveren på LAN, noe som betyr at du opererer i et pålitelig miljø. Med mindre du har en veldig høy sikkerhetsstandard, ville det ikke være en stor sikkerhetsrisiko å ha ingen kryptering.

Stol ikke på noen. Bruk sikre strenger for å holde passord for ren tekst og has dem umiddelbart. Tiden er borte da du kan håpe systemet ditt er sikkert. Det er ikke. Det er bare spørsmål om tid / penger til en bestemt angriper kan få tilgang til systemet ditt.

Selv når trafikken blir kryptert med SSL / TLS, kan jeg komme med flere scenarier, som hver fører til passordlekkasje, for eksempel

• Regjeringen fanger SSL-trafikk og "spør pent "for en privat nøkkel for å dekryptere den. Er alt i et privat nettverk? Er du sikker på at det ikke er konfigurert noen replikering utenfor stedet?
• Organisasjonen din installerer maskinvare som utfører mann-i-midten-SSL-dekryptering for å snuse den SSL-trafikken som går gjennom nettverket. Plutselig er flere mennesker, maskinvare og programvare involvert - stoler du på dem? Har den ikke blitt installert eller kanskje ikke ennå?
• Server som har private SSL-nøkler blir hacket og nøkkelen lekker. Privat. Stille.
• En misfornøyd ansatt får betalt for å kopiere den private nøkkelen og selge den til konkurrenten

Ja, det er en rekke risikoer eller risikoøkninger her.

Først og fremst, uansett om DBA-ene dine kan stole på eller ikke, bør de være i stand til å fortelle enhver revisor (eller forskningsetterforsker, eller advokat) nei, det er ikke mulig at de utgav seg for å være bruker X, fordi de aldri, aldri kunne se brukerens passord, selv om de ønsket det, og selv om de brukte kopien av serverens private nøkkel og en pakkesniffer .

For det andre, hvis du hashing passord på serveren, bør du:

• Les det kanoniske Hvordan sikre hash-passord? svar av Thomas Pornin, som koker ned til "Bruk BCrypt, SCrypt eller PBDF2".
  • Med så stort antall iterasjoner som du kan håndtere under toppbelastning.
  • Med en utgangslengde ikke lenger enn basen som hash primitiv utgangslengde.
• Siden dette er SQL Server, se mitt eget rene T-SQL PBKDF2 implementering svar.
  • Merk at det er forferdelig tregt sammenlignet med reell implementering s, spesielt angrepsimplementeringer som oclHashcat.
• Se oclHashcat for nåværende angrepshastigheter for én maskin, multi-GPU offline. Dette er hva angripere, forskere og konkurransedeltakere vil bruke når de tar tak i en kopi av de hashede passordene dine fra et frontend-sårbarhet, eller en bærbar PC med databasesikkerhetskopi på, eller (velg ditt favorittscenario her). li>
• Innse, basert på det ovennevnte, at uansett hva applikasjonen din er, kan den bruke langt flere runder med BCrypt, SCrypt eller PBKDF2 for å hash passordet enn SQL Server-databasen kan ha i samme mengde beregningstid.
  • og det er nesten alltid enklere og billigere å legge til mer frontendkraft ved å skalere ut enn det er å legge til mer SQL Server-kraft.

Vær oppmerksom på at en rekke PBKDF2-implementeringer er på mitt Github-arkiv, inkludert en C # -variant basert på Jitters arbeid, som Jither ga ut under MIT-lisensen.

Så det avhenger av miljøets tillitsverdighet. Hvis du ikke har tillit til det, vil kanskje kryptering være bra. I tillegg vil konfigurasjonen med lave grener trolig være å begrense bare verter som krever SQL-tilkobling, selv om det er mange forskjellige grunner til at du vil åpne den for tilgang.

TLDR : Så lenge nettverkstilkoblingen til DB er sikker, og så lenge saltede hashes er lagret i tabellene dine, er det greit å ringe en lagret prosedyre med vanlig tekstpassord. Jeg tror tid og krefter blir brukt på å beskytte databasen mot uautorisert tilgang av den typen som gjør det mulig å få spor av lagrede prosedyreanrop.

Først forstår jeg scenariet det er snakk om angriper kan gjenopprette passordet for ren tekst ved å gå gjennom parameterverdier som er sendt til den lagrede prosedyren, hvorav den ene er ren tekstpassord, og deretter bruke passordet til å kompromittere en brukerkonto i applikasjonen.

Hvis det er riktig da er den eneste rent tekniske løsningen jeg ser å implementere en PK-ordning innenfor omfanget av den lagrede prosedyren, slik at passordet må krypteres med den lagrede prosedyrens offentlige nøkkel, krypteringsteksten sendes til den lagrede prosedyren, og parameterverdien deretter dekrypteres av den lagrede proc selv med en privat nøkkel før den brukes. (Eller bedre, som TLS selv, kan du forhandle om en Diffie-Hellman-utveksling ved hjelp av andre lagrede procs, og bruke en øktnøkkel.) Med mindre du kan finne noen åpen kildekode-implementering av dette der ute, som du stoler på, og bruker den, dette blir et veldig tungt løft. Og du må beskytte den private nøkkelen nå.

Men vurder hva du virkelig prøver å beskytte deg mot. I dette scenariet kan angriperen lese dine lagrede prosedyreanrop og få verdiene som er sendt inn. Ville noen brukere med dette privilegiet også ha lesetilgang til den private nøkkelen du bruker, eller velge / sette inn / oppdatere tilgang til tabellene dine? I så fall, selv om du går gjennom arbeidet med å implementere PKI på lagret prosedyrenivå, blir innsatsen din umiddelbart beseiret.

La meg også svare spesifikt på ideen om å hashe passordet, med salt selvfølgelig, og overføre den hashverdien til den lagrede prosedyren. Hvis du gjør dette, er den hashverdien nå passordet. Alt en angriper må gjøre, hvis han virkelig kan lese de lagrede proc-parametrene dine, er å gjenta disse parametrene nøyaktig slik han ser at de kompromitterer systemet. Han trenger faktisk ikke å reversere hasjen og lære hva det "vanlige" passordet er; hashverdien er passordet for ren tekst nå. Så denne ordningen har ingen effekt.