b10ad65368d6d236fead37ff6c58980a.ppt
- Количество слайдов: 48
LEKSION 8 Integriteti dhe Siguria q. Domain Constraints(Kufizimet). q. Integriteti Referencial. q. Triggers. q. Siguria. q. Assertions q. Autorizimi ne SQL
Domain constraints Kufizimet e integritetit kujdesen per rreziqet aksidentale ne db, duke siguruar qe ndryshimet e autorizuara ne database nuk rezultojne ne nje humbje te qendrueshmerise se te dhenave. Kufizimet ne domain jane forma me elementare e kufizimeve te integritetit. Ato testojne vlerat e insertuara ne database si dhe testojne query-t per tu siguruar qe krahasimet te kene kuptim Domain-e te reja mund te krijohen nga tipe te dhenash ekzistuese ◦ P. sh create domain Dollars numeric(12, 2) create domain Pounds numeric(12, 2) Nuk mund ti japim ose krahasojme nje vlere te tipit Dollars me vleren e tipit Pounds. ◦ Megjithate mund te konvertojme tipin si me poshte: (cast r. A as Pounds) (gjithashtu duhet te shumezohet me kursin e kembimit dollarne-pound)
Domain constraints vazhd. . Kushti check ne SQL-92 lejon qe domain-et te jene te kufizuara ◦ Perdorim kushtin check per te siguruar qe nje domain paga-per-ore te lejoje vetem vlera me te medha se nje vlere specifike create domain hourly-wage numeric(5, 2) constraint value-test check(value > = 4. 00) ◦ Domain-I ka nje kufizim qe siguron qe paga-per-ore (hourly-wage) te jete me e madhe se 4. 00 ◦ Fjala constraint value-test eshte opsionale; e dobishme per te treguar cilin kufizim ka cenuar nje update Ne Domain check mund te kete kushte komplekse ◦ create domain Account. Type char(10) constraint account-type-test check (value in (‘Checking’, ‘Saving’)) ◦ check (branch-name in (select branch-name from branch))
Integriteti Referencial Siguron qe nje vlere qe shfaqet ne nje relacion per nje bashkesi te dhene atributesh gjithashtu shfaqet per nje bashkesi atributesh nje relacion tjeter. ◦ Shembull: Nqs “Perryridge” eshte nje emer dege qe shfaqet ne nje nga rreshtat ne relacionin account, atehere ekziston nje rresht ne relacionin branch per degen “Perryridge”. Percaktimi formal ◦ Le te jete r 1(R 1) dhe r 2(R 2) relacione me celesa primare K 1 dhe K 2 perkatesisht. ◦ Nenbashkesia e R 2 eshte nje foreign key qe referon K 1 ne relacionin r 1, nqs per cdo t 2 ne r 2 duhet te jete nje rresht t 1 ne r 1, ne menyre te tille qe t 1[K 1] = t 2[ ]. ◦ Kufizimi I integritetit referencial I quajtur ndryshe subset dependency ku mund te shkruhej (r 2) K 1 (r 1)
Integriteti Referencial ne modelin E-R Le te marrim parasysh bllokun e relacionit R ndermjet blloqeve te entiteteve E 1 dhe E 2. . Skema relacionale per R perfshin celesat primare K 1 te E 1 dhe K 2 te E 2. E 1 E 2 R Pastaj K 1 dhe K 2 formojne celesa te jashtem ne skemat relacionale per E 1 dhe E 2 perkatesisht. Blloqet e entiteve te dobet jane gjithashtu nje burim I kufizimeve te integriteti referencial ◦ Per skemen relacionale te nje blloku te dobet entitetesh duhet te perfshihen atributet e celesave primare te bllokut te entitetit nga I cili varet.
Check-imi i integritetit referencial ne modifikimin e database-it Testimet e meposhtme duhet te kryhen per te ruajtur kufizimet e integritetit referencial te meposhtme: (r 2) K (r 1) Insert. Nqs nje rresht t 2 insertohet ne r 2, sistemi duhet te siguroje qe ekziston nje rresht t 1 ne r 1 te tille qe: t 1[K] = t 2[ ]. Qe eshte: t 2 [ ] K (r 1) Delete. Nqs nje rresht t 1 fshihet nga r 1, sistemi duhet te llogarite bashkesine e rreshtave ne r 2 qe I referohen t 1: = t 1[K] (r 2) ◦ Nese kjo bashkesi nuk eshte boshe: Edhe komanda delete refuzohet nje error, ose Rreshtat qe referojne t 1 duhet te fshihen (fshirjet cascade jane te mundshme)
Modifikimi i database-it Update. Ekzistojne 2 raste: ◦ Nqs nje rresht t 2 update-het ne relacionin r 2 dhe update-mi modifikon vlerat per celesin e jashtem , atehere kryhet nje testim I ngashem me rastin e insertit. ◦ Le te shenojme t 2’ vleren e re te rreshtit t 2. Sistemi duhet te siguroje qe: t 2’[ ] K(r 1) Nqs nje rresht t 1 updatohet ne r 1, dhe update-I modifikon vlerat e celesin primar (K), atehere kryhet nje testim I ngjashem me rastin e delete-it: 1. Sistemi duhet te llogarite = t 1[K] (r 2) duke perdorur vleren e vjeter te t 1 (aplikohet vlera perpara update-it). 2. Nqs kjo bashkesi nuk eshte boshe: 1. update-i mund te refuzohet si nje error, ose 2. update-i mund te pershkallezohet ne rreshtat ne bashkesi, ose 3. rreshtat ne bashkesi mund te fshihen.
Integriteti Referencial ne SQL Celesat primare, kandidate dhe ato te jashtem mund te specifikohen si pjese e instruksionit SQL create table: ◦ Fjalia celes primar (primary key )liston atributet qe perbejne celesin primar ◦ Fjalia celes unik (unique key) liston atributet qe perbejne celesin kandidat ◦ Fjalia celesi i jashtem (foreign key) liston atributet qe perbejne celesin e jashtem dhe emrin e relacionit referues te celesit te jashtem Si default, nje celes I jashtem referon atributet e celesit primar te tabeles referuese foreign key (account-number) references account Nje forme e shkurtuar per te specifikuar nje kolone te vetme si celes te jashtem account-number char (10) references account Kolonat referuese ne tabelen referuese mund te specifikohen qarte ◦ por duhet te deklarohen si celesa primar/kandidat foreign key (account-number) references account(account-number)
Integriteti Referencial ne SQL shembull create table customer (customer-name char(20), customer-street char(30), customer-city char(30), primary key (customer-name)) create table branch (branch-name char(15), branch-city char(30), assets integer, primary key (branch-name))
Integriteti Referencial ne SQL – shembull vazhd. . create table account (account-number char(10), branch-name char(15), balance integer, primary key (account-number), foreign key (branch-name) references branch) create table depositor (customer-name char(20), account-number char(10), primary key (customer-name, account-number), foreign key (account-number) references account, foreign key (customer-name) references customer)
Veprimet cascade ne SQL create table account. . . foreign key(branch-name) references branch on delete cascade on update cascade . . . ) Ne saje te fjalise on delete cascade, nqs nje fshirje e nje rreshti ne branch rezulton ne nje cenim te kufizimit te integritetit-referencial, atehere fshirja “cascades” (pershkallezohet) ne relacionin account, duke fshire rreshtin qe I referohet deges qe u fshi. Update-t “cascade” jane te ngjashme
Veprimet cascade ne SQL vazhd. . Nqs ekziston nje varg varesish te celesave te jashtem ndermjet disa relacioneve, te specifikuar per cdo varesi me on delete cascade, nje fshirje ose update ne njerin fund te vargut mund te perhapet pergjate gjithe vargut ◦ Si rezultat, gjithe ndryshimet e shkaktuara nga transaksionet dhe veprimet ne cascade jane te paperfunduara. Integriteti referencial check-ohet ne fund te nje transaksioni ◦ Hapa te ndermjetem lejohet te cenojne integritetin referencial te arritur, hapat e mevonshem menjanojne cenimin
Integriteti Referencial ne SQL vazhd. . Menyra alternative per cascade: ◦ on delete set null ◦ on delete set default Vlerat null ne atributet e celesave te jashtem e komplikojne semantiken e integritetit referencial te SQL-se, dhe me mire te parandalohen duke perdorur not null ◦ Nqs ndonje atribut I nje celesi te jashtem eshte null, rreshti percaktohet per te kenaqur (plotesuar) kufizimin e celesit te jashtem!
Assertions Nje assertion (mbrojtje) eshte nje predikat qe shpreh nje kusht qe deshirojme qe database-I te plotesoje gjithmone Nje assertion ne SQL ka formen: create assertion
Assertions shembull Shuma e te gjithe vlerave te kredive per cdo dege duhet te jete me e vogel se shuma e te gjithe balancave te llogarive ne ate dege. create assertion sum-constraint check (not exists (select * from branch where (select sum(amount) from loan where loan. branch-name = branch-name) >= (select sum(balance) from account where account. . branch-name = branch-name)))
Assertions shembull Cdo kredi ka te pakten nje kredimarres qe miremban nje llogari me nje minimum balance ose $1000. create assertion balance-constraint check (not exists ( select * from loan where not exists ( select * from borrower, depositor, account where loan-number = borrower. loan-number and borrower. customer-name = depositor. customer-name and depositor. account-number = account-number and account. balance >= 1000)))
Triggers-at Nje trigger eshte nje instruksion(paraqitje) qe ekzekutohet automatikisht nga sistemi si nje efekt ne modifikimin e nje database. Per te dizenjuar nje mekanizem trigger, duhet: ◦ Specifikuar kushtet ne te cilat trigger-I do te ekzekutohet ◦ Specifikuar veprimet qe duhen ndermarre kur trigger-I ekzekutohet Trigger-at jane paraqitur ne standardin SQL: 99, por qe jane suportuar dhe me pare duke perdorur sintaksen jo-standarde nga shume database-e.
Trigger shembull Supozojme se ne vend qe te lejojme balanca negative te llogarive, banka merr masa me overdraft-e (mbiterheqje) duke: ◦ Vendosur balancen e llogarise ne 0 ◦ Krijuar nje kredi ne shumen e overdraft-it ◦ I dhene kesaj kredie nje numer kredie identike me numrin e llogarise te llogarise overdrawn(terhequr. . ) Kushti per ekzekutimin e trigger-it eshte nje update ne relacionin account qe rezulton ne nje vlere negative te balances.
Trigger shembull ne SQL create trigger overdraft-trigger after update on account referencing new row as nrow for each row when nrow. balance < 0 begin atomic insert into borrower (select customer-name, account-number from depositor where nrow. account-number = depositor. account-number); insert into loan values (nrow. account-number, nrow. branch-name, – nrow. balance); update account set balance = 0 where account-number = nrow. account-number end
Eventet e trigger-ve dhe veprimet ne SQL Eventet e trigger-ve mund te jene: insert, delete ose update Trigger-at ne update mund te kufizohen ne atribute specifike ◦ Psh. create trigger overdraft-trigger after update of balance on account Vlerat e atributeve perpara dhe pas nje update-I mund te referohen ◦ Duke referuar rreshtin e vjeter si: per fshirje dhe update ◦ Duke referuar rreshtin e ri si: per inserte dhe update Trigger-at mund te aktivizohen perpara nje event-I, e cila mund te sherbeje si kufizime shtese create trigger setnull-trigger before update on r referencing new row as nrow for each row when nrow. phone-number = ‘ ‘ set nrow. phone-number = null
Paraqitja e trigger-ve Ne vend qe te ekzekutojme nje veprim te ndare per cdo rresht te afektuar (prekur), nje veprim I vetem mund te ekzekutohet per gjithe rreshtat qe preken nga transaksioni ◦ Perdorim per cdo instruksion ne vend per cdo rresht ◦ Perdorim referencimi I tabeles se vjeter ose referencimi I tabeles se re per t’iu referuar tabelave te perkohshme (te ashtequajtura transition tables) qe permbajne rreshtat e prekur ◦ Mund te jene me eficent kur kemi te bejme me instruksione te SQL-se qe update-ne nje numer te madh rreshtash
Veprimet e botes-jashtme Ndonjehere kerkohet te kryhen veprime te botes se jashtme per nje update te database-it (nepermjet trigger-ve) ◦ Psh. Ri-porosotija e nje artikulli sasia e te cilit eshte zvogeluar ne nje magazine, ose ndezja e drites se nje alarmi, Trigger-at nuk mund te perdoren per te implementuar direkt veprimet e botes-jashtme, POR ◦ Ato mund te perdoren per te regjistruar veprimet-qe-duhen-ndermarre ne nje tabele te vecante ◦ Duke patur nje proces te jashtem qe skanon tabelen vazhdimisht, kryen veprimet e botes-jashtme dhe fshin veprime nga tabela Psh. Supozojme nje magazine ka tabelat e meposhtme: ◦ inventory(item, level): Sa eshte numri per cdo artikull ne magazine ◦ minlevel(item, level) : Cili eshte niveli mimimal I deshirueshem per cdo artikull ◦ reorder(item, amount): Sa eshte sasia qe duhet riporositur ne nje kohe ◦ orders(item, amount) : Porosite per t’u vendosur (te lexuar nga procesi I jashtem)
Veprimet e botes-jashtme vazhd. . create trigger reorder-trigger after update of amount on inventory referencing old row as orow, new row as nrow for each row when nrow. level < = (select level from minlevel where minlevel. item = orow. item) and orow. level > (select level from minlevel where minlevel. item = orow. item) begin insert into orders (select item, amount from reorder where reorder. item = orow. item) end
Trigger-at ne sintaksen MS-SQL server create trigger overdraft-trigger on account for update as if inserted. balance < 0 begin insert into borrower (select customer-name, account-number from depositor, inserted where inserted. account-number = depositor. account-number) insert into loan values (inserted. account-number, inserted. branch-name, – inserted. balance) update account set balance = 0 from account, inserted where account-number = inserted. account-number end
Kur nuk duhet te perdorim triggers Triggers jane perdorur me perpara per te kryer disa detyra si: ◦ Mirembajtur te dhenat permbledhese (p. sh paga totale per cdo departament) ◦ Replikimin e database-ve duke I regjistruar ndryshimet ne relacione speciale (te ashtequajtura relacione change ose delta) dhe duke patur nje proces te vecante qe aplikon ndryshimet ne nje replike(riprodhim) Ekzistojne menyra me te mira per te bere keto tani: ◦ Tani database-t sigurojne lehtesira ne view-t e krijuara per te mirembajtur te dhenat permbledhese ◦ Database-t sigurojne suport per replikim Lehtesirat e enkapsulimit mund te perdoren ne vend te trigger-ve ne shume raste: ◦ Duke percaktuar metodat per te update-ar fushat ◦ Duke kryer veprimet si pjese te metodave update ne vend te kryerjes nepermjet nje trigger-i
Siguria – mbrojtja nga perpjekje keqdashese per te vjellur ose modifikuar te dhena. ◦ Niveli I sistemit te database-it Mekanizmat e autentifikimit(vertetimi) dhe autorizimit(leje) per te lejuar perdorues specifik te aksesojne vetem te dhenat e kerkuara Do te perqendrohemi tek autorizimi ne pjesen tjeter te leksionit ◦ Niveli I sistemit operativ Super-perdoruesit e sistemit te operimit mund te bejne cfare deshirojne ne database! Kerkohet nivel sigurie e mire te sistemit te operimit ◦ Niveli network: duhet te perdoret kriptimi(maskimi) per te parandaluar: Pergjime (leximi I paautorizuar I mesazheve) Maskarade (duke pretenduar te jesh nje perdorues I autorizuar ose duke derguar mesazhe qe supozohen vijne nga perdorues te autorizuar )
Siguria vazhd. . ◦ Niveli fizik Aksesi fizik ne kompjutera lejon shkaterrimin e te dhenave nga njerez keqdashes; siguria tradicionale “kyc-celesin” eshte e nevojshme Kompjuterat duhet te mbrohen nga permbytjet, zjarri etj. ◦ Niveli human Perdoruesit duhet te jene te mbuluar (me parete portative) per t’u siguruar qe nje perdorues I autorizuar te mos i dorezoj akses njerezve “keqdashes”
Autorizimi Format e autorizimit ne pjesen e database-it: Autorizim per lexim – lejon perdoruesit te lexojne por jo te modifikojne te dhenat. Autorizim per insertim – lejon insertimin e te dhenave te reja, por jo modifikimin e te dhenave ekzistuese Autorizim per update – lejon modifikimin, por jo fshirjen e te dhenave
Autorizimi vazhd. . Format e autorizimit ne modifikimin e skemes se database-it: Autorizim I indekseve – lejon krijimin dhe fshirjen e indekseve (treguesve) Autorizim I resurseve – lejon krijimin e relacioneve te reja Autorizim I ndryshimeve – lejon shtimin ose fshirjen e atributeve ne nje relacion Autorizim I fshirjes (drop) – lejon fshirjen e relacioneve
Autorizimi dhe View-t Perdoruesve mund t’I jepet autorizim ne view-t, pa I dhene asnje autorizim ne relacionet e perdorura ne percaktimin e view-se. Aftesia e view-se per te fshehur te dhena ndikon si ne perdorimin e thjeshtezuar te sistemit ashtu dhe ne rritjen e sigurise duke lejuar perdoruesit te aksesojne vetem ato te dhena per te cilat kane nevoje gjate punes se tyre Nje kombinim ose siguria ne nivel-relacional dhe siguria ne nivel-view mund te perdoret per te limituar aksesin e nje perdoruesi per te percaktuar qarte te dhenat per te cilat ka nevoje perdoruesi
Shembull view Supozojme se nje nenpunes banke ka nevoje te dije rreth emrave te klientave kredimarres per cdo dege, por nuk eshte i autorizuar per te pare informacionin specifik te kredive. ◦ Metoda: mohimi i aksesit direkt ne relacionin loan, por ti lejoje akses ne view-ne cust-loan, e cila konsiston vetem ne emrat e klientave dhe degeve ne te cilen ato kane nje kredi. ◦ view cust-loan percaktohet ne SQL si meposhte: create view cust-loan as select branchname, customer-name from borrower, loan where borrower. loan-number = loan-number
Shembull view (vazhd. . ) Nenpunesi eshte i autorizuar per te pare rezultatin e query-t: ◦ select * from cust-loan Kur procesori query perkthen rezultatin ne nje query ne relacionet aktuale ne database, marrim nje query ne kredimarres dhe kredi Autorizimi duhet te check-het ne query-ne e nenpunesit perpara se procesimi query te zevendesoje nje view nga percaktimi i view-se.
Autorizimi ne view Krijimi i view-se nuk kerkon autorizim te resurseve deri kur nuk krijohet nje relacion real Krijuesi i view-se merr vetem ato privilegje qe nuk sigurojne autorizim shtese pertej asaj qe ai tashme ka. Psh. Nqs krijuesi i view-se cust-loan kishte vetem autorizim per te lexuar ne borrower dhe loan, ai do te kete vetem autorizim per te lexuar ne cust-loan
Dhenia e (granting) privilegjeve Lejekalimi per autorizim nga nje perdorues ne tjeter mund te perfaqesohet nga nje graf autorizimi Nyjet e ketij grafi jane perdoruesit Rrenja e ketij grafi eshte administratori i database-it Skaji Ui Uj tregon qe perdoruesi Ui i jepet autorizim per update ne kredi tek Uj U 1 DBA U 2 U 3 U 4 U 5
Grafi i dhenies se autorizimeve Kerkese: gjithe skajet ne nje graf autorizimi duhet te jene pjese e disa pathve me origjine administratorin e database-it Nqs DBA terheq (anullon) grantet nga U 1: ◦ Grant-et duhet te terhiqen nga U 4 deri ne momentin kur U 1 te mos kete me autorizim ◦ Grant-et nuk duhet te terhiqen nga U 5 deri ne momentin kur U 5 ka nje autorizim path-i nga DBA nepermjet U 2 Duhet te parandalohen ciklet e granteve qe nuk kane path (rrugekalim) nga rrenja: ◦ DBA jep autorizimin U 7 ◦ U 7 jep autorizimin U 8 ◦ U 8 jep autorizimin U 7 ◦ DBA terheq autorizimin nga U 7 Duhet te terhiqet granti U 7 ne U 8 dhe nga U 8 ne U 7 deri kur te mos kete me asnje path nga DBA ne U 7 ose ne U 8.
Specifikimet e sigurise ne SQL Instruksioni grant perdoret per te akorduar autorizimin grant
Privilegjet ne SQL select: lejon akses per lexim ne relacion, ose aftesia e query duke perdorur view-ne Shembull: dhenia e grant-ve perdoruesve U 1, U 2, and U 3 per autorizim select ne relacionin branch: grant select on branch to U 1, U 2, U 3 insert: aftesia per te insertuar tuples update: aftesia per te update-ar duke perdorur instruksionet update te SQL-se delete: aftesia per te fshire tuples. references: aftesia per te deklaruar celesat e jashtem kur krijojme relacionet usage: ne SQL-92; autorizon nje perdorues per te perdorur nje domain specifik all privileges: i perdorur si nje forme e shkurter per te gjithe privilegjet e lejuara.
Privilegji per te dhene (grant) privilegje with grant option: lejon nje perdorues te cilit i jepet nje privilegj per ta kaluar privilegjin ne perdorues te tjere. ◦ Shembull: grant select on branch to U 1 with grant option i jep privilegjet select U 1 ne branch dhe lejon qe U 1 t’i jap (dorezoje) kete privilegj te tjereve.
Rolet lejojne privilegjet e perbashketa per nje klase perdoruesish qe mund te specifikohen vetem njehere duke krijuar nje “rol” korrespondues Privilegjet mund te jepen ose te anullohen nga rolet, ashtu si dhe perdoruesit Rolet mund t’i caktohen perdoruesve, dhe madje dhe roleve te tjera SQL: 1999 suporton rolet: create role teller create role manager grant select on branch to teller grant update (balance) on account to teller grant all privileges on account to manager
Revokimi i autorizimit ne SQL Instruksioni revoke perdoret per te terhequr autorizimin. revoke
Revokimi i autorizimit ne SQL (vazhd. . )
Limitet e autorizimit te SQL-se SQL nuk suporton autorizimin ne nje nivel rreshti ◦ Psh. Nuk mund te kufizojme studentat per te pare vetem (ruajtjen e rreshtave) notat e tyre perkatese Me rritjen e aksesit ne Web te database-ve, akseset e database-ve vijne fillimisht nga server-t e aplikimit ◦ Perdoruesit fundore nuk kane db user ids, te gjithe ato jane te perfshire ne te njejtin db user id Detyra e autorizimit ne rastet e mesiperme bie ne programin aplikativ, pa suport nga SQL-ja ◦ Perfitim: autorizimi te mire-strukturuara, si rreshtave individual, mund te implementohen nga aplikimi ◦ Disavantazh: autorizimi duhet bere ne kodin e aplikacionit, dhe mund te shperndahet pergjate aplikacionit ◦ Kontrollimi per mungese te autorizimit behet shume i veshtire qekur kerkohet leximi i shumave te medha te kodit te aplikacionit
Gjurmet e auditimit Nje gjurme auditimi eshte nje log i gjithe ndryshimeve () ne database sebashku me gjithe info si psh cili perdorues ka kryer ndryshimin, dhe kur ndodhi ky ndryshim I perdorur per te gjurmuar ndryshimet e gabuara/mashtrimet Mund te implementohet duke perdorur triggers-at, por shume sisteme database-sh sigurojne suport direkt
Kriptimi Te dhenat mund te kriptohen kur masat per autorizim database-i nuk ofrojne mbrojtje te mjaftueshme Teknika e cilesive te kriptimit: ◦ Relativisht i thjeshte perdorues te autorizuar per te kriptuar dhe dekriptuar te dhenat ◦ Skema e kriptimit varet nga fshehtesia e algoritmit por ne fshehtesine e nje parametri te algoritmit qe quhet celes i kriptimit ◦ Jashtezakonisht i veshtire per nje person te paautorizuar per te percaktuar celesin e kriptimit
Kriptimi (vazhd. . ) Data Encryption Standard (DES) zevendeson karakteret dhe riorganizon renditjen e tyre ne baze te nje celesi kriptimi i cili i sigurohet personave te autorizuar nepermjet nje mekanizmi te sigurte Advanced Encryption Standard (AES) eshte nje standard i ri qe zevendeson DES, dhe bazohet ne algoritmin Rijndael, por gjithashtu eshte i varur ne celesat e perbashket sekret Public-key encryption bazohet ne cdo perdorues duke patur dy celesa: ◦ public key – celes publik i hapur perdoret per te kriptuar te dhenat, por nuk mund te perdoret per dekriptuar te dhenat ◦ private key – celes i njohur vetem nga perdorues individual dhe perdoret per dekriptuar te dhena Skema e kriptimit celes i haput RSA eshte bazuar ne fortesine e nje numri te madh ne komponente e tij prim
Autentifikimi i bazuar ne password perdoret gjeresisht, por eshte i ndjeshem per tu “nuhatur” ne nje rrjet Sistemet Challenge-response shmangin transmisionin e password-ve ◦ DB dergon nje kerkese (stringe) per fakte perdoruesit ◦ Perdoruesi kripton stringen dhe kthen rezultatin. ◦ DB verifikon identitetin duke dekriptuar rezultatin
Certifikatat dixhitale Digital certificates aperdoren per te verifikuar autentifikimin e celesave publik Problem: kur komunikoni me nje faqe web, si e kuptoni qe ju jeni duke “biseduar” me sitin web te vertete (genuine) apo nje mashtrues? ◦ Zgjidhje: perdorni celesin publik te nje web site ◦ Problem: si te verifikoni nese celesi publik ai vete eshte i vertete?
Certifikatat dixhitale (vazhd. . ) Zgjidhje : ◦ Cdo klient (p. sh browser) ka celesa publik te nje niveli-rrenje te autoriteteve te certifikimit ◦ Nje sit mund te marre emrin/URL e tij dhe celesin publik te nenshkruar nga nje autoritet certifikimi: dokumenti i nenshkruar quhet nje certificate


