Visu var atkost.
Neviens nekad nevarēs aizsargāties pret "brute force" jeb pilno pārlasi.
galvenā problēma ir nevis autentifikācijas mehānismu uzbūvē, bet gan tajā faktā, ka lietotāji izvēlas stulbas, viegli uzminamas paroles.
Drošība ir atkarīga no izvirzītajām prasībām.
Piemēram, šim forumam pilnīgi pietiek ar to, ka paroles tiek glabātas sahashotā veidā uz servera un nekādā citādākā veidā netiek aizsargātas pie pārsūtīšanas, turpretī, piemēram, bankas kontam vajag gan paroles aizsardzību uz servera, gan arī pārsūtīšanas laikā.
Būtībā izšķir 3 veidu autentifikāciju:
1) Ko tu zini (paroles)
2) Kas tev ir (atslēga, bankas kodu karte, lapa ar OPIA vienreizējajām parolēm)
3) Kas tu esi (pirkstu nospiedumi, radzenes attēli, rokas ģeometrija)
Visvienkāršāk ir ieviest pirmā veida autentifikāciju un vissarežģītāk trešā veida autentifikāciju (jo tā prasa gan ieguldījumus aparatūrā, gan to, lai visi iespējamie sistēmas lietotāji būtu iepriekš zināmi un kaut kādā drošā veidā būtu iesnieguši attiecīgos biometriskos parametrus).
Visdrīzāk, ka arī otrā veida autentifikācija ir par sarežģītu, lai ieviestu web aplikācijai. (Ja tas nav domāts intraneta lietošanai).
Tātad vairumā gadījumu paliek tikai pirmais variants.
Iespējamie paroļu mehānisma realizēšanas varianti:
1) Klients nosūta paroli Serverim pa neaizsargātu kanālu. S glabā paroles datubāzē P un pārbauda paroles pareizību salīdzinot p ar P.
Trūkumi:
p var "nosnifot" (Protams, pie noteikuma, ka Uzbrucējs spēj pārtvert nepieciešamo K trafika daļu).
Ja notiek ielaušanās S, tad iespējama situācija, kad U dabū visu P datubāzi.
Priekšrocības:
Nav nepieciešams izmantot jebkādas kriptogrāfiskās metodes autentifikācijas datu aizsardzībai ne K pusē, ne S pusē.
Jau pēc šī pirmā paroļu realizācijas mehānisma apskatīšanas var redzēt, ka pamatā jāveic aizsardzības pasākumi vismaz divās vietās - p pārsūtīšanas posmā no K uz S; un P glabāšanā uz S.
Patiesībā ir vēl trešais "ķēdes posms" - K sistēma. Jāizvērtē risks, ka uz K sistēmas ir tīši vai netīši uzinstalēts kāds "key logger" (tas būtu banālākais variants, bet jāpadomā arī par potenciālo iespēju nolasīt p, kad tā atrodas RAMā vai, ja tā tiek "noswapota" uz diska - protams, šāda veida programmu atrašanās uz datora vispārīgā gadījumā ir maz ticama, bet iespēja paliek iespēja...) vai līdzīgas dabas programmas. Piemēram iedomāsimies situāciju: "Jums steidzīgi vajag izdarīt pārskaitījumu bankā, bet vienīgā pieejamā vieta ir publiskā interneta kafejnīca". Kā var zināt, ka jūsu ierakstītā parole nenonāk pa taisno kādā "log" failā?
Tomēr vispārīgā gadījumā, lielākoties, ir jārūpējas par kanāla K<->S drošību un datubāzes P drošību.
Kanāla starp K un S aizsardzības veidi:
a) Izmantot ssl/tls. Ja ir tāda iespēja, tad tā ir jāizmanto - šīs metodes ir praksē pārbaudītas un vispār atzītas par labām esam.
Trūkumi: Gan S, gan K ir jāatbalsta ssl/tls protokols. Visi modernie web-serveri un pārlūki atbalsta šos standartus, tādēļ šis variants būtu jāizmanto ja vien nav kādi tiešām pamatoti iemesli, lai to nedarītu.
Tālākās metodes jāizmanto tikai tad, ja kaut kādu iemeslu dēļ nav pieejama metode a).
B) Izmantot "jaucējfunkciju" jeb hash funkciju h(x):
K nosūta S h(p).
S pārbauda, vai ar attiecīgo P kopas elementu p' sanāk tā, ka h(p')<==>h(p).
Trūkumi: Gan uz K, gan uz S ir jāvar izrēķināt h(x). Ja uz S tā vēl nebūtu problēma, tad uz K varētu būt problemātiski izpildīt programmu, kas realizē šo funkciju (web gadījumā, visdrīzāk, ka tā ir javaScript funkcia, kuras izmantošana var nebūtiespējama atsevišķos gadījumos).
Kaut gan U nevar vairs tik vienkārši uzzināt p, tomēr pilnībā pietiek ar h(p), lai sekmīgi autentificētos.
c)"Challenge-response" mehānisms. Vispārīgā gadījumā:
K pieprasa autentifikāciju S.
S noģenerē gadījumskaitli R1 un aizsūta to K.
K arī noģenerē gadījumskaitli R2, un aizsūta šādu pāri S: h(R1, p, R2), R1. Kur h(x) ir "vienvirziena jaucējfunkcija" jeb hash funkcija.
S, savukārt pārbauda, vai ar attiecīgo P kopas elementu p' sanāk tā, ka
h(R1, p' , R2) <==> h(R1, p, R2).
Trūkumi: Tieši tas pats, kas B) gadījumā, tikai nu vairs U nevar izmantot pārtvertos datus, lai nākamreiz autentificētos, jo nākamreiz S uzģenerēs pavisam citu R1.
P glabāšanas uz S drošības paaugstināšanas veidi:
I) uz S glabāt tikai paroļu hash attēlus h(p).
Trūkumi: Kaut gan U nevar vienkārši uzzināt p. Tomēr atkarībā no kanāla aizsardzības veida viņš var izmantot šo informāciju, lai veiksmīgi autentificētos.
U var izmantot iepriekšizveidotu hash vērtību sarakstu, lai ātri uzzinātu izmantotās paroles.
U var redzēt, kuriem lietotājiem paroles sakrīt.
II) Tas pats, kas I), bet pie paroles tiek pielikta, tā sauktā, "salt" jeb "sāls" vērtība. Respektīvi, datubāzē tiek glabāts pāris: S, h(S, p). Sāls vērtībai būtu jābūt unikālai visas autentifikācijas sistēmas ietvaros, tas ir, nevajadzētu būt tā, ka diviem vienādiem lietotājiem ir vienāda sāls vērtība.
Trūkumi: Tas pats, kas I), bet tiek minimizēta iespēja izmantot iepriekšizveidotu hash vērtību sarakstu, kā arī lietotājiem, kuri ir izvēlējušies vienādas paroles datubāzes ieraksti atšķirsies.
III) Tas pats, kas II), bet tabulā tiek glabāts paroles attēls pēc vairākkārtējas hash funkcijas pielietojuma: S, h(h(...h(S,p)...)). No K pienāk p attēls, kuram h(x) pielietota par vienu reizi mazāk, nekā tabulā P esošajām vērtībām. Pārbaude notiek šādi: S saņemtajai vērtībai vēlreiz pielieto h(x) un pārbauda, vai tā sakrīt ar P esošo vērtību.
Priekšrocības: Ja U dabū bāzi P, tad viņam ir ļoti sarežģīti kaut kādā veidā izmantot šo informāciju.
Tālāk, atkarībā no prasībām un riska novērtējuma, tiek izvēlēta viena no metodēm kanāla aizsardzībai un viena no metodēm P aizsardzībai un veidota autentifikācijas sistēma, kura izmantotu attiecīgās metodes.
Literatūra:
http://www.schneier.com/paper-low-entropy.pdf
http://www.ciphersbyritter.com/GLOSSARY.HTM
http://www.cacr.math.uwaterloo.ca/hac/
Lūdzu izteikt kādus komentārus!
P.S. kaut kā ļoti gari sanāca, bet cerams, ka kaut ko saprast arī var (-;
