password security

[jannis]

Kaads ir VIS VIS droshaakais veids lai veiktu lietotaaja autorizaaciju?

Saakumaa biju domaajis ka ar md5 hash pietiek parolju suutiishanai, bet tad naakas secinaat - to var nosniifot un nosuutiit serverim ar POST :/ SSH varot nosniifot un atkost...

[Aleksejs]

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 (-;

Edited September 15, 2004 by Aleksejs

[Venom]

NB> md5 hashi (lowercase latin, 0-9, ~!@#...) līdz 5 simb (ieskaitot) esmu lauzis laikā līdz 4 minutēm, tāpēc pats piespiežu lietotājus lietot min. 6 simb. paroles.

[jannis]

nu ko, jaaizmanto vien buus SSL2 un md5

[arnico]

Kaadas ir tautas domas par sha1 ?

Labaaks / sliktaaks par md5 ? vai kaa?

Edited September 15, 2004 by arnico

[Aleksejs]

Kaadas ir tautas domas par sha1 ?

Labaaks / sliktaaks par md5 ? vai kaa?

Uz šo brīdi sha1 labāks par md5, jo md5 ir matemātiski pierādīts, ka eksistē metode kolīziju atrašanai, kas ir ātrāka par pilno pārlasi.

http://www.cryptography.com/cnews/hash.html

Čena un Bihema neitālā bita metode

 

Tas, ka ir atrasta metode, kas ļauj veikt ātrāku pārlasi, nenozīmē, ka automātiski md5 ir kļuvis būtiski nedrošāks praktiskajos pielietojumos, jo kā jau agrāk gan es, gan Venom teica - galvenā problēma nav vis hash funkcijās vai autentificēšanās procedūrās, bet gan faktā, ka lietotāji izvēlas īsas, viegli uzminamas paroles.

 

Bet, ja ir iespēja, tad vajadzētu izvēlēties sha1.

Edited September 15, 2004 by Aleksejs