Jump to content

Paroļu glabātāji.


Fruzz
 Share

Recommended Posts

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 :D 

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 - TOoMoOT
  • Patīk 1
Link to comment
Share on other sites

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

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

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! :D 

Link to comment
Share on other sites

Vai piemēram - izdomā kādu vārdu un to pārvērt ciparos ar 3310 tehniku. 

Labots - Zoom
Link to comment
Share on other sites

@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

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

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

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

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

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.

 

  • Atbalstu 2
Link to comment
Share on other sites

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

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

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

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 kontu

Pierakstīties

Jums jau ir konts? Pierakstieties tajā šeit!

Pierakstīties tagad!
 Share

×
×
  • Izveidot jaunu...