Buvo įsilaužta į KTU duomenų bazę, paviešinta informacija

Pasirašiau paprasta (ir ne efektyvia) programėlę kuri vis keičia simboliu iš eilės, kuria hešą ir tikrina ar jis sutampa su nurodytu hešu. Tai simbolių eilutę kuria sudaro iki 6 simbolių (A-Z, a-z, 0-9) peržiūrėjo per 2885.3 sekundės. Taigi per tiek laiko nulauščiau bet kuri pw iki 6 simbolių, sudarytu iš simbolių (A-Z, a-z, 0-9). 0895b8b08226828b293cbaab2d9d66ff hašą atspėjo per 0.5 sekundės iš trijų simbolių.

kur gauti tą sąrašą? rwc, saltas išsaugomas duombazėje, tad jei jau įsilaužia į duombazę, tai ir saltas žinomas... aišku galima sūdyti ir per php su unikaliom druskom ir kryptinti, kad ir penkis kartus.. arba pirma į vieną koduotę, o iš jos į kitą ir tik tada į db plius su random saltais... arba gali net saltas būti užkoduotas emailas.. o geriausiai visada emailus užkoduoti ir naudoti tik prisijungimams tą lentelę... va, tada tai niekas nieko nebepadarys, nes emailų tikrai neiškryptins...

kaip salt galima naudoti kad ir emailo pirmus 6 simbolius ar pan.

Paaiškinkit, kas yra salt'as paprastam mirtingajam?

O ką reiškia "kryptinti"?... Kažkaip nespėju paskui kalbininkus

Tai čia angliškai.

salt - simbolių eilutė, kuri sujungiama su slaptažodžiu, o tada hash'uojamas gautas rezultatas. Tarkim: "salt" + "somepass" = "saltsomepass". Tokiu būdu prailginama hashuojamų simbolių eilutė, o vaivorykštės "gali sulaužyti" hash'us tik riboto ilgio simbolių eilutėms nepriklausomai nuo to, kad dalis simbolių žinoma. Bruteforce'ui druska ne kliūtis, nes jo "gebėjimas laužyti" priklauso ne nuo bendro simbolių kiekio, o tik nuo nežinomų simbolių kiekio. Iš kitos pusės bruteforce'as užima nepalyginamai daugiau laiko: vienam passui vaivorykštės - mažiau sekundės, bruteforce'as - nuo poros valandų iki kelių savaičių su vidutiniu kompu. Tas tampa esmine kliūtimi, kada laužymas vyksta masiškai, t.y. reikia išgliaudyti tūkstančius hash'ų.

O, kodėl naudojamas būtent toks šifravimas? Juk mano skurdžiomis žiniomis yra ir kitų šifravimo metodų, kurie atsparesni laužimams.

Lietuviški angliški hibridai apgaulingai skamba, galvojau vėl koks tinkinimas atsirado... Passus hashinti prasminga, nes jie ne select'inami, o lyginami - grubiai tariant: SELECT IFNULL((SELECT CASE WHEN MD5Hash('somepass') = u.UserPassword THEN 'Authenticated' ELSE 'Access denied' END FROM SecurityTable u WHERE u.UserName = 'someusername'), 'Access denied'); Koks tolkas encryptinti email'us? Paskui ir pats nieko nebepadarysi tais duomenim...

In your face. Turbūt koks nors studentas išmestas už nelankomumą parodė dėstytojam, ką ištikro reiškia geras specialistas Salt - druskytė, įberi į slaptažodį ir skonis iškart pasikeičia Bet kad čia chebra atsilikus nuo gyvenimo tai ne tas žodis. Vieną kart md5 be salt encryptino ir galvoja užteks. Online milžiniškos md5 hashų duombazės, jau ir bruteforcint nebereikia, nors su šiuolaikiniais kompais netaip baisu kažką decryptint. Taip būna, kai dirba specialistai kurie mokėsi iš rusiškų vadovėlių.

Yra daug kitų, pavyzdžiui, santykinai plačiai naudojamas SHA256/512. Vaivorykščių klausimu reikšmingas algoritmo populiarumas, o ne sudėtingumas, t.y. kažkam turi kilti pagunda investuoti išteklius į terabaitinės hash'ų duombazės sukūrimą. Teko skaityti, kad kai kuriais atvejais siekiant to išvengti naudojami ypač egzotiniai ir mažai žinomi algoritmai, iš kitos pusės, pasaulyje keliasdešimt tūkstančių profesionalių matematikų nuolat ieško matematinių pažeidžiamumų algoritmuose, neatmestina galimybė tokiai egzotikai rasti vaistukų pasiknaisiojus matematikų darbuose. Taip pat yra problematika su egzotinių algoritmų atitikimu "hash'o standartams", pagrinde dėl generuojamo turinio atsparumo collisions. Kiek teko pasižiūrėti komercinius produktus, įskaitant buh apskaitos programas, visi naudoja arba MD5 arba kažkurią SHA atmainą. SHA ir panašaus sudėtingumo algoritmai turi vieną esminį trūkumą palyginus su MD5 - santykinai ilgą konvertavimo trukmę. Pavyzdžiui, SHA512 beveik trigubai lėtesnis už MD5. Daugelyje web sistemų autentifikacija (ir autorizacija) vykdoma po kiekvieno posto (priešingu atveju atsiranda MiM pažeidžiamumas ir galimybė santykinai nesunkiai klastoti siunčiamus paketus). Atitinkamai įvedus sudėtingesnį hash algoritmą pastebimai sulėtėja sistemos veikimas. Tiesa, bruteforce'ui galioja tas pats. Dar vienas svarbus momentas - paveldimumas. Teoriškai, negali dekoduoti hash'uotų pass'ų ir atitinkamai upgrade'inti algoritmo. Praktiškai, sudėtinga ir ne visada įmanoma 100 proc. Bus užsidėjęs koks useris pass'ą iš 30 simbolių ir kukuosi.

Druska, tai tiesiog belekokios informacijos iterpimas i slaptazodi issaugant duombazeje visa hasha, tiesiog turi tarsi sifra ir dekoderi, bei dar tame sifre ten primaklina kazka, ir kas butent ten primaklinta paprastai yra saugoma duombazeje, tai va ta makliava ir yra druska. Tiesiog daugiau krusliavos, kai bandai nukrakinti slaptazodi, kompiuteris tarsi turi ne tik slaptazodzio varianta nukoduoti, bet dar ir salta variantus kiekvienam slaptazodzio variantui, tai slaptazodziu variantai*salt'o variantai= daugiau krusliavos. Cia jau taip labai buitiskai viska suprimityvinau

Druskos vienintele paskirtis - kad vienodi slaptazodziai grazintu skirtingus hashus, 48 bitu (6 simboliu) druskos yra per akis. Dabar apie algoritmus: MD5 yra nesaugus del koliziju, sha seimos algoritmai yra per greiti. Geras slaptazodzio hashavimo algoritmas yra algoritmas. Jeigu yra realizuota, geriausia naudoti bcrypt funkcija. Pvz: jeigu hasho funckija vykdoma ~30ms, is vartotojo puses nebus labai didelio skirtumo, taciau net ir ataka naudojant zodyna uztruks pakankamai ilgai, jau nekalbant apie brute force, Jeigu autorizacija vykdoma po kiekvienos operacijos ir neprasoma vartotojo kiekviena karta ivedineti slaptazodzio (slaptazodis saugomas kazkur sistemoje) - buvo sukurta didziule saugumo skyle. Jeigu autorizacija nevykdoma per HTTPS (iskaitant ir "sausainiuku" perdavima) - buvo sukurta dar didesne saugumo skyle. Apibendrinant: pagrindine problema - absoliucios daugumos programuotoju zinios kriptografijos srityje yra lygios nuliui.

Visko žinoti negali

padaryti reikšmingą pauzę prieš grąžindamas rezultatą (nesvarbu, patvirtinimo ar atmetimo). Toliau turėtų būti naudojami tik unikalūs sesijos raktai su ribotu galiojimu, adresato patikrinimu ir t.t., geriausia - išvis vienkartiniai. Beje, dauguma algoritmų turi polinominį sudėtingumą priklausomai nuo rezultato ilgio (kvadratinį ar net kubinį), jei tikrai toks aktualus atsparumas vaivorykštėms. Tačiau vis tiek svarbiausia kuo ilgesnė, unikalesnė ir neatspėjamesnė "druskelė" (geriausia, kad jos net pats adminas nežinotų). Gal netgi, kad būtų skirtinga kiekvienam vartotojui - išskaičiuojama iš unikalių nekintamų vartotojo savybių. Apibendriinant - taip, dauguma programuotojų nieko nekerta apskritai apie sistemų saugumą. Dėl "senų" algoritmų, tai problema nėra tokia neišsprendžiama. Dažnai duomenų bazėse prie hašo prilipdomas ir algoritmo identifikatorius. Autorizavimo servisas taip pat gali būti atsakingas už hašo atnaujinimą prisijungiant.

, nedėčiau salt'o į DB, bent jau tą pačią, kurioje saugomi patys hashai. Ir į web aplikaciją nedėčiau, nes ji pažeidžiamiausia dalis. Dėčiau į vidinį servisų serverį, įkompiliuodamas atsitiktinę seką pirmo diegimo metu. O šiaip emailų nepakanka hešuoti, nes negarantuosi hešų unikalumo. Reikia šifruoti kokiu nors asimetriniu algoritmu, kurio dešifravimo raktas "pamirštas".

Palik darbą su tokia jautria vieta specialistui.

Saugiau nuo to nebus, tik nebūsi lengvas masalas (kam laužyti ilgą slaptažodį, jei per tą patį laiką gali nulaužti milijoną paprastų). O jei kažkam tikrai labai rūpės būtent tavo slaptažodis būtent toje sistemoje, tai ras lengvesnių būdų išvilioti nei nulaužinėt duombazę.

Kuriant didelį projektą ir turint atitinkamus išteklius - viskas teisingai. Deja, gyvenime daugelis projektų yra (santykinai) smulkūs, o ištekliai labai riboti... Būtų neprotinga iš forumo ar kokios įmonės reprezentacinio puslapio reikalauti aukštų saugumo standartų, labai jau brangiai tas atsieitų, bet būtent forumai yra pažeidžiamiausia sistemos vieta - useriai turi savybę naudoti tuos pačius pass'us visur, turi userio mail'ą, su didele tikimybe per google ir soc tinklus identifikuoji asmenį, turi slaptažodį, su didele tikimybe prisijungsi prie kur kas labiau apsaugotų servisų. Pagal tavo aptartus siekius, tos pačios technologijos.lt yra visiškai skylėtas daiktas. Aš pats atviru kodu rašinėju apskaitos programą ir smulkius VVS'us, toks socialiai naudingas hobis. Būčiau tikrai ne prieš, jei koks saugumo specas patobulintų mano parašytą data access layerį, bet vat savanorių neatsiranda, o investuoti savo lėšas į nemokamą daiktą motyvų neturiu. Į mano sistemą įsilaužti ko gero būtų paprasčiau, nei į kokį NAVISION'ą, bet tikrai ne per 15 min. Jei jau kažkam labai prireiks duomenų iš smulkios įmonės serverio, vis tiek įsilauš. Ir greičiausiai tą padarys ne per mano programą, reikalaujančią atskiros analizės, o per žinomus exploitus neatnaujinamame apache'yje.