Jump to content
php.lv forumi

Kanāla un paroļu drošība


none

Recommended Posts

Sveicināt.

Salasījos visādus topikus par paroļu drošībām. Visvairāk nācās aizdomāties par Alekseja (~ pirms 2.g. ievieto http://php.lv/f/index.php?showtopic=1508&hl= ) skaidrojumu par paroļu mehānismie kā klients nodot to serverim un salīdzina ar DB.

 

Izanalisēju visus viņa piedāvātos variantus un sapratu, ka tiem visiem nav pilnīgi nekādas jēgas, ja uzbrucējs var pārķert datus no kanāla. Tik labi es varu sūtīt pliku paroli, vai hašotu, vai 10x gašotu, likt salt vētības, nekas no tā jau nekļūst drošāks. Varbūt kļūdos?

 

Šobrīd man vajag pamatojumu kāpēc plikas paroles sūtīšana un salīdzināšana DB ar tādu pašu ir nedrošāk, par tiem variantiem kad tiek hašots un izmantotas salt vērtības???

 

Plus, cik reāli ir iespējams uzzināt DB tabulu un atrībūtu nosaukumus.

Link to comment
Share on other sites

ja izmanto kaut kaadu open source scriptu, tad db strukturu zinas visi kam vajadzes. ja kaut ko pashtaisitu, kludas neradi, servera admins neafishee db strukturu, nav publiski uzlikts phpmyadmin vai veel kads caurums atstaats, dbdumpu dc neshaareee utt, tad diezgan gruutu ir uzzinat kaada ir tiesi db struktura. protams vienmer var mineet ka userus glaba tabulaa users un usera id esi nosaucis par user_id..

Link to comment
Share on other sites

Nekļūdies. Tā ir - datus plikā HTTP protokolā var pārķert. Tāpēc jau lieto HTTPS = HTTP + SSL.

 

Cik viegli tas vispār ir izdarāms? Un vai vispār kāds no Jums to ir darījis?

Piem., to SSL/TLS kriptēšans protokolus, cik esmu novērojis, izmanto saitos kur darīšans ar naudām un tml.

Skatos, tie paši draugiem.lv, tīri labi iztiek bez šitā protokola. Acīm redzami pietiekami droši ir arī to datu kanālu neaizsargāt?

Edited by none
Link to comment
Share on other sites

Skatos, tie paši draugiem.lv, tīri labi iztiek bez šitā protokola. Acīm redzami pietiekami droši ir arī to datu kanālu neaizsargāt?

Visi papildpasākumi, arī SSL, prasa zināmus serveru resursus.

Link to comment
Share on other sites

Da figņa.. SSL nekodēs jau Mb failus... 100Kb texta bleķis šamam būs kā uzspļaut...

 

Un jā, kad runā par drošibu, tad nerunā par resursiem... Standarta ibankas - jsp/servlets + oracle + SSL.. tāpēc jamās nedaudz bremzē, bet toties uz visiem 1000% attaisnojās.

Link to comment
Share on other sites

Pārķert http? Elementāri, pilnīgi nekādu problēmu.

 

A kādu tad lai veidot pieteikšanās mehānismu, lai pārķerot datus nevarētu ielogoties sistēmā?

inbox.lv tak neizmanto SSL. Tad jau sanāk, ka mierīgi bubu var savāk manu paroli un čekot manus meilus?

Par ko es stipri šaubos, jo kuru gan tie varētu interesēt :D

Edited by none
Link to comment
Share on other sites

Par ko es stipri šaubos, jo kuru gan tie varētu interesēt :D

Par to arii ir shish skumjais staasts....

Viss ir atkariigs no pashiem datiem kas tiek aizsargaati :)

Jaaskataas vai ir veerts ieguuldiit darbu/finanses aizsargajot teiksim kautkaadus speeljuku rezultaatus...

cita lieta banku norekjinu sisteemas....

Link to comment
Share on other sites

Pārķert HTTP var tikai, ja ir pieeja pie servera galvenās drāts... Tā kā nekas tur tik viegli nesanāks.. citādi visi saiti būtu `uzkrakoti`...

 

Klez, ģenerēts keys neko nedod, jo tas ir tas pats kas kūkijs, kuru var nofeikot..

 

Izņēmums ir, ja keys ir uzģenerēts hašojot IP+Browser+SomethingElse, un pie pieprasījuma čekot pieprasītāja IP+... Vienīgi to pašu IP/MAC var mainīt, bet tas darbojās tikai ~viena provaidera robežās - to biš ~lokālajā tīklā...

 

Tā kā, HTTP/HTTPS ir pietiekami droši... galvenais ir pareizais security handlings...

Link to comment
Share on other sites

Pārķert HTTP var tikai, ja ir pieeja pie servera galvenās drāts... Tā kā nekas tur tik viegli nesanāks.. citādi visi saiti būtu `uzkrakoti`...

 

Paldies, tas bija tieši tas, ko gribēju zināt.

Link to comment
Share on other sites

×
×
  • Create New...