TOoMoOT Septembris 17, 2019 Share Septembris 17, 2019 (labots) pirms 2 stundām , ImissimI teica: dictionary attack Ja latviešu valoda + nepareiza rakstība ir kaut kam derīga, tad tās ir paroles Parolēm izmanto hashing. Šifrēšana un hašošana nav tas pats. Šifrēšana ļauj ar pareizo atslēgu gan pārvērst sakarīgu simbolu virkni nesakarīgā, gan nesakarīgu sakarīgā (abi virzieni). Sakarīgo simbolu virkni vari mainīt kā gribi un turpināt izmantot to pašu atslēgu šifrēšanai/ atšifrēšanai.Tā trūkums parolēm būtu, ka ar atslēgu būtu iespējams uzzināt, kāda ir parole. Pirmkārt pašam sistēmas uzturētājam NAV jābūt iespējai uzzināt lietotāju plain text paroli. Otrkārt ja noplūst datubāze ar nohashotām parolēm, tad hakerim būtu katra parole atsevišķi jābrūtforso. Sarežģīts hashing algoritms padara bruteforsošanu neiespējamu pat salīdzinoši īsām simbolu virknēm. Atliek tikai dictionary attack ar populārākajām parolēm, bet arī to var izvērst par diezgan ilgu procesu. Varētu teikt, ka Hašošanā pati parole kļūst par atslēgu. Piemērs. parole: Jaabols76 --> [hashing algoritms] --> myHash2GA42gdfwE6ksv5@j^*.[+ vēl n-tie simboli]. Hashing algoritms nodrošina divas lietas 1) To izpildot, var iegūt precīzi 'myHash2GA42gdfwE6ksv5@j^*.[+ vēl n-tie simboli]' tikai un vienīgi, ja tam tiek padots kā arguments precīzi 'Jaabols76'. 2)Tas priekš sava veikuma pildās absurdi ilgi. Ja nav tupa parole, tad, manuprāt, jāuzmanās no sekojošām lietām: 1)Kāds apšaubāms portāls, kurā esi piereģistrējies ar savu vienīgo paroli, neizmanto hashing vai to piefiksē kaut kur pirms hašošanas. 2)Keyloggeri 3)Spoofing un gan jau vēl kaut kas Labots Septembris 17, 2019 - TOoMoOT 1 Link to comment Share on other sites More sharing options...
Raimonds1 Septembris 17, 2019 Share Septembris 17, 2019 Ir jāizdomā sistēma, ka, ja kādam ir pieejama viena konkrēta parole un tās paroles šifrēts pieraksts, tad tik un tā nevar atšifrēt citu šifrētu paroli. Jāsaglabā tikai pats šifrēšanas princips. Link to comment Share on other sites More sharing options...
TOoMoOT Septembris 17, 2019 Share Septembris 17, 2019 Pirms 1 minūtes , Raimonds1 teica: Ir jāizdomā sistēma, ka, ja kādam ir pieejama viena konkrēta parole un tās paroles šifrēts pieraksts, tad tik un tā nevar atšifrēt citu šifrētu paroli. Jāsaglabā tikai pats šifrēšanas princips. Nav jāizdomā. Ir jau izdomāt. Hashing. Ir tikai jāiemācās lietot jau gatavas bibliotēkas (kas ir elementāri) Link to comment Share on other sites More sharing options...
Ronalds Septembris 17, 2019 Share Septembris 17, 2019 Pirms 29 minūtēm , MIGs teica: Tāpēc, ka nevajag jaukt kopā DB userus un aplikācijas userus. Tā nav labā prakse. Vot par šo lūdzu sīkāk! Kas slikts, ja aplikācijas useris = db useris? Tiešām paštaisīts useru autentifikācijas mehānisms būs labāks kā tas ko piemērām mssql vai mysql piedāvā??? Vēl jo vairāk - 99% gadījumos useri un paroļu haši glabājas visiem lasāmā tabulā - līdz ar notiek šīs tabulas noplūdes... Dēļ SQL injection - takš slabo SQL parametrus lietot! Labāk sql pieprasījumus lipināt no stringiem! Link to comment Share on other sites More sharing options...
Zoom Septembris 17, 2019 Share Septembris 17, 2019 (labots) Vai piemēram - izdomā kādu vārdu un to pārvērt ciparos ar 3310 tehniku. Labots Septembris 17, 2019 - Zoom Link to comment Share on other sites More sharing options...
MIGs Septembris 17, 2019 Share Septembris 17, 2019 @Ronalds, paņem kaut vai Laravel iebūvēto OAuth mehānismu un dzīvo laimīgs. Piemērs - M$SQL var tikt licencēts arī pēc lietotājiem. Tad nu šāds softs mēreni iesūkās, kur katram web portāla apmeklētājam būs savs SQL useris. Otrkārt, esošās SQL permisijas būs daudz par mazu, vai vismaz risinājums būs ļoti caur pakaļu, ja Tev būs lietotāji kas vienlaicīgi var būt piesaistīti vairākām organizācijām ar dažādām tiesībām. Sarežģīti, bet reāli gadījumi. Šodien norma skaitās, ka tev katram lietotājam ir savs sāls(SALT) un parole tiek salikta kopā ar šo SALT un tad hašota(vēlams ne ar MD5). Tam visam klāt autorizācijas mēģinājumi, bloķēšanas, password recovery (Intereses pēc - kā Tu to ērti darīsi ar DB useri?) . Kā tu DB lietotājiem pieslēgsi LDAP/M$ Active Directory vai Google OAuth ? Link to comment Share on other sites More sharing options...
basic Septembris 17, 2019 Share Septembris 17, 2019 Pirms 31 minūtēm , Ronalds teica: Kas slikts, ja aplikācijas useris = db useris? Nu, viens no lielākajiem mīnusiem ir, ka tādā gadījumā lietotājs var tikt DB apejot aplikāciju, kas 99% gadījumu nav vēlams. Ja aplikācijas lietotājs ir nodalīts, tad DB lietotājs aplikācijas lietotājam nav zināms un datubāzē nekādas izmaiņas apejot aplikāciju nav iespējams veikt. Link to comment Share on other sites More sharing options...
Ronalds Septembris 17, 2019 Share Septembris 17, 2019 Pirms 17 minūtēm , basic teica: ka tādā gadījumā lietotājs var tikt DB apejot aplikāciju, Par firewall, kas ļauj pie db pieslēgties tikai no aplikāciju servera / admina hosta nav dzirdēts? Pirms 29 minūtēm , MIGs teica: Tam visam klāt autorizācijas mēģinājumi, bloķēšanas, password recovery (Intereses pēc - kā Tu to ērti darīsi ar DB useri?) Konkrēti mssql tas viss ir! Un mssql lieliski māk aktīvās direktorijas userus lietot! Maksas mysql arī. Bet nu piekrītu, ka situācijas ir dažādas. Tomēr tā kā useru autentifikācija ir izveidota vairumā web aplikāciju - sviests tas ir pilnīgs! Nu nedrīkst ļaut ierindas userim izpildīt komandu "select * from userdb" un nodumpot paroļu hešus!!!! Link to comment Share on other sites More sharing options...
basic Septembris 17, 2019 Share Septembris 17, 2019 Pirms 9 minūtēm , Ronalds teica: Nu nedrīkst ļaut ierindas userim izpildīt komandu "select ^ Nu, redzi, var, protams, uztaisīt appuser=dbuser un pēc tam likt klāt kruķus, lai viņš nevarētu izpildīt 'SELECT *'. Un var arī nodalīt tos lietotājus - tad, ja aplikācijā pats neuzrakstīsi 'SELECT *', tad arī nebūs viņam iespēja to izpildīt. Link to comment Share on other sites More sharing options...
Ronalds Septembris 17, 2019 Share Septembris 17, 2019 Ar ierindas useri es domāju to useri, ar kuru aplikācija pie db slēdzas! Tālāk php gadījumā parasti netiek izmantoti parametri tipa: query = 'select * from table where name = :p_name'; query.parameters('p_name') = ievades_lauks; Bet gan pieprasījums tiek lipināts no stringiem query = 'select * from table where name =' + ievades_lauks Tipiskā sql injekcija! Un sql injekcija ir iespējama dēļ kreisas arhitektūras.... Link to comment Share on other sites More sharing options...
MIGs Septembris 17, 2019 Share Septembris 17, 2019 Piedod, bet izklausās, ka Tu kā īsts vīrs kodē tikai pliku PHP tāpat, kā 15 gadus atpakaļ un neko jaunu neesi šajā tēmā skatījies. 2 Link to comment Share on other sites More sharing options...
itanium Septembris 17, 2019 Share Septembris 17, 2019 pirms 5 stundām , Ronalds teica: Kas slikts, ja aplikācijas useris = db useris? Tiešām drausmas :/ Ikdienā ar to nenodarbojos, bet "Frontam" dot pieeju pie DB liekas marazms. Link to comment Share on other sites More sharing options...
rubb Septembris 18, 2019 Share Septembris 18, 2019 Pirmkārt jau lipināt sqlu no teksta ir nepareizi - jālieto parametrizēti kveriji. Un tā arī visās normālās situācijās tiek darīts un jābūt darītam. Vienalga, vai runa ir par PHP, Pitonu, MySQL Oracle - vienalga. Link to comment Share on other sites More sharing options...
DjUbuntu Septembris 18, 2019 Share Septembris 18, 2019 Keepass. A lietot DB userus aplikācijai - tikpat oldschooliigi kā izmantot DB stored procedures visai biznesa loģikai. Problēmu pilna pēcpuse, nu un es arī paskatīšos kā tavs DB useru risinājums skeilosies uz 10k+ useriem Link to comment Share on other sites More sharing options...
Recommended Posts
Izveido kontu, vai pieraksties esošajā, lai komentētu
Jums ir jābūt šī foruma biedram, lai varētu komentēt tēmas
Izveidot jaunu kontu
Piereģistrējies un izveido jaunu kontu, tas būs viegli!
Reģistrēt jaunu kontuPierakstīties
Jums jau ir konts? Pierakstieties tajā šeit!
Pierakstīties tagad!