Silke

Ne. Jei nurodyta, kad duomenys yra tam tikruose rėžiuose ar tam tikras kiekis, tai taip ir būna. Niekad niekad mūsų nemokė dar patiems dėti tikrinimų.

Iš tavo temos panašiau, kad tiesiog trūksta valios mokytis teorijos, o ne, pavyzdžiui, resursų :) Nepritarsiu nei tiems, kurie sako, kad „kiekvienam būtina viską mokėt iki pat metalo“, nei „nesvarbu, kad nemoki paaiškinti, svarbu, kad veikia“. Nėra blogai pradėti nuo high-levelio ir turint to pagrindą kapstytis giliau.
 
Sakai, tarkim:
 
Na, aišku, keista, kaip tada pavyko su PHP programuoti. Juk vis tiek žinai, kas yra cookies, kas yra GET (ne, ne asociatyvus masyvas). O jei ne, tai prašom raktiniai žodžiai: HTTP, TCP, IP. (būtent to „lindimo giliau“ tvarka). :)
 
Arba, pavyzdžiui, tas įsivaizdavimas, kad OOP – kažkoks jau kitas kosmosas, kad jį išmokti prireikė poros metų. Viena pagrindinių paradigmų ir kitur, ir PHP. Beveik jokie didesni PHP projektai nebus kuriami be OOP.
 
Nori sužinoti, kaip implementuota PHP ar kita interpretuojama kalba? Nagrinėk jų variklius, mokykis C (kuria dažniausiai tokie kuriami). Kartu platformų, OS specifiką, ir t.t.
 
O bendras patarimas dėl domėjimosi, kas naujo nutinka, ar tiesiog kur rasti gerų blog postų, naujienų, ir pan.: Hacker News, /r/programming, ir pan.
 
Kodėl staiga „mesti“? Nebėra „metimo“, nebent padarysi "rm -rf" daliai savo smegenų. Jei jau turi pagrindą, jis tau išliks. Nebent, kaip sakai, atsiliksi nuo updeitų :) Kitą kalbą imk, bet tik tada, jei pasidomėsi ir žinosi kodėl (o ne kažkas sušuko, kad Java cool, tai imi). Tikrai neblogai būtų išmokti Ruby (nors iš kažkiek panašaus tipažo į PHP, bet bent labiau vykus). O po to jau taikyti į kiek skirtingesnes kalbas, nes mokytis, tarkim PHP, Ruby, Python, Perl ir Javascript nelabai yra tolko. Geriau imti tokias, kurios yra skirtingos visa savo esybe. Nuo Ruby peršok į C. Tada gal į Haskell. Tada galbūt C#. Čia tik vienas iš galimų kelių – jokiu būdu nepatariu būtent taip :)

Šiuo atveju tu neteisus, tiek java tiek php+html+js galima padaryti abu žaidimus.

Iš tavo temos panašiau, kad tiesiog trūksta valios mokytis teorijos, o ne, pavyzdžiui, resursų :) Nepritarsiu nei tiems, kurie sako, kad „kiekvienam būtina viską mokėt iki pat metalo“, nei „nesvarbu, kad nemoki paaiškinti, svarbu, kad veikia“. Nėra blogai pradėti nuo high-levelio ir turint to pagrindą kapstytis giliau.
 
Sakai, tarkim:
 
Na, aišku, keista, kaip tada pavyko su PHP programuoti. Juk vis tiek žinai, kas yra cookies, kas yra GET (ne, ne asociatyvus masyvas). O jei ne, tai prašom raktiniai žodžiai: HTTP, TCP, IP. (būtent to „lindimo giliau“ tvarka). :)
 
Arba, pavyzdžiui, tas įsivaizdavimas, kad OOP – kažkoks jau kitas kosmosas, kad jį išmokti prireikė poros metų. Viena pagrindinių paradigmų ir kitur, ir PHP. Beveik jokie didesni PHP projektai nebus kuriami be OOP.
 
Nori sužinoti, kaip implementuota PHP ar kita interpretuojama kalba? Nagrinėk jų variklius, mokykis C (kuria dažniausiai tokie kuriami). Kartu platformų, OS specifiką, ir t.t.
 
O bendras patarimas dėl domėjimosi, kas naujo nutinka, ar tiesiog kur rasti gerų blog postų, naujienų, ir pan.: Hacker News, /r/programming, ir pan.
 
Kodėl staiga „mesti“? Nebėra „metimo“, nebent padarysi "rm -rf" daliai savo smegenų. Jei jau turi pagrindą, jis tau išliks. Nebent, kaip sakai, atsiliksi nuo updeitų :) Kitą kalbą imk, bet tik tada, jei pasidomėsi ir žinosi kodėl (o ne kažkas sušuko, kad Java cool, tai imi). Tikrai neblogai būtų išmokti Ruby (nors iš kažkiek panašaus tipažo į PHP, bet bent labiau vykus). O po to jau taikyti į kiek skirtingesnes kalbas, nes mokytis, tarkim PHP, Ruby, Python, Perl ir Javascript nelabai yra tolko. Geriau imti tokias, kurios yra skirtingos visa savo esybe. Nuo Ruby peršok į C. Tada gal į Haskell. Tada galbūt C#. Čia tik vienas iš galimų kelių – jokiu būdu nepatariu būtent taip :)

Turima omenyje, kad ir nuoroda http://www.domenas.lt/kazkas/kazka/ ir nuoroda http://www.domenas.lt/failas?id=456 gali vesti į failus be jokių redirektų. Todėl reikia tikrinti response'o header'ius.

Sveiki, atsirado laisvesnio laiko ir noras papildyti nedidelį atliktų darbų sąrašą, tai sugalvojau padaryti akcija, t.y. sukursiu 1(galbūt 2) tinklalapį nemokamai. Naudosiu Ruby on Rails + Bootstrap, todėl laukiu įdomių pasiūlymų. :) Taip pat jeigu kyla kokių klausimų, galit rašyti šioje temoje.

Ką? O tai kur saugosi druską, unikalią kiekvienam vartotojui, vienaragio urve? :) Vis tiek pakelia slaptažodžio crackinimo trumę n kartų, kur n – vartotojų skaičius. Nesvarbu, kad lengvai prieinama.
 
Ne-unikalus salt yra beveik tas pats, kas jokio salt, nes beveik neprailgina crackinimo laiko (tik tiek, kol pamodifikuosi žodyną), apsaugo tik nuo rainbow tables.
 
Kiek žinau, nėra stebuklingų vietų, kur tavo aplikacija galėtų pasiekti salt, o įsilaužėlis – ne.
 
SHA1 apskritai nėra slaptažodžiams skirta hešavimo funkcija. Geriau naudoti autoriaus minimą bcrypt ar kitą daug laiko trunkantį algoritmą, apie ką ir buvo klausta.
 
password_hash() saugią druską sugeneruoja pats.
 
--
 
Donatai, cost turėtų būti konstanta ar parametras kur nors klasėje – nori galėti ją nesunkiai pakeisti. Tuo labiau, kad 10 nėra jau toks didelis sunkumas.
 
Šiaip dar baisokai atrodo primaišytos PHP normali sintaksė ir alternatyvi... Ne vien dėl to, kad alternatyvi dažniausiai nenaudojama (išskyrus kai kurias templeitų „sistemas“, kur grynas PHP), bet dar ir dėl to, kad jos abi vienoj vietoj... Gal geriau pasilik prie įprastos?
 
Dar su bcrypt būtų gerai turėti rate limitingą. Kai nėra jo, su tokia intensyvia funkcija piktavalis gali išsunkti serverio CPU resursus :) Ai, berods tą turi su SUSPENDED.
 
Rehash yra reikalingas tik tada, kai pasikeičia algoritmas (bcrypt) ar jo parametrai (pvz., cost). Kitokiu atveju tavo rehash tik pakeis saltą, ir tiek.

counter yra funkcijos lokalus kintamasis, tad natūralu, kad jis sukuriamas iš naujo kiekvieną kartą kviečiant metodą.
 
Vietoj to padaryk instance variable @counter, jį nustatyk į 3 konstruktoriuje, o mažink tame metode :)

Išmok gitą. Sublime yra teksto redaktorius, o ne IDE.

Sudalyvausiu :)

Daug kalbi ir nieko nepasiūlai. Sakai, kad encryptionas yra super easy, bet esmė, kad negali pasiūlyti efektyvaus modelio, nes yra ta problema, kurią jau keliskart minėjau. O encryptinus ir šalia laikant raktą tai encryptioną įveikti reiks tiek pat laiko, kiek kokį nors ROT13...
 
Palyginimai labai negeri. DB apsaugoti slaptažodžiais reikia, nes, pirmiausiai, ginamės nuo kitų vartotojų tame pačiame serveryje (ar tai būtų kiti sharedo/cloudo vartotojai, ar webshellas su `www-data`).
 
HTTPS pats yra saugus, o Heartbleed yra vienos TLS implementacijos side-effectas. Bugas kuris net neatsirado dėl HTTPS protokolo spragos, o pačių susikurto papildymo jam (ir dar visiškai bukos klaidos su atminties valdymu).
 
Žodžiu, primygtinai siūlai šifravimą, kuris neefektyvus, nes raktas yra pasiekiamas įsilaužėliui. Tai tas pats, kaip uždėti tavo minėtą spyną, o raktą padėti šalia jos.
 
Iš esmės šiaudinę baidyklę / slidžią nuokalnę darai su mano argumentais. Aš nesakau, kad reikia nesisaugoti akivaizdžiai tinkamais ir efektyviais būdais. Bet, dar kart, tokio šifravimo, kaip siūlai, dar nežinai, kaip padaryti efektyvaus. Galiausiai, galėdamas redaguoti failus, įsilaužėlis tiesiog įkiš naujas užklausas į jau esamos aplikacijos kodą (kuri kažkaip stebuklingai bus saugiai iššifravusi duomenis).

Trolis.

Trolis.

Nes MD5 (kaip bet kuri hash funkcija) yra one way. Ar tavo tekstas bus 1 baito, ar 10 GB, iš jo paskaičiuojama 16 baitų reikšmė. Kaip tokią žadi atkoduoti?
 
Todėl saugiai hash funkcijai įveikti galima tik spėlioti (rainbow tables, dictionary, bruteforce). MD5 nebėra saugi, todėl yra kitų būdų (pvz. kolizijų gaminimas). Bet, darkart, hash funkcijos yra į vieną pusę. Duomenų, paduodamų į funkciją kiekis yra neribotas, o rezultatų kiekis - ribotas. n bitų funkcijai 2 n-tuoju laipsniu galimų reikšmių. T.y. MD5 turi 2^128 galimų reikšmių, SHA-512 - 2^512 :) Jei hash funkcija nėra nulaužta, o hešuotus duomenis nėra lengva atspėti (pvz. žodis, esantis žodyne), tai "atkodavimas" ir bus bukas bruteforce (arba kolizijos ieškojimas) ir truks mažų mažiausiai tūkstančius metų :)

Daug kalbi ir nieko nepasiūlai. Sakai, kad encryptionas yra super easy, bet esmė, kad negali pasiūlyti efektyvaus modelio, nes yra ta problema, kurią jau keliskart minėjau. O encryptinus ir šalia laikant raktą tai encryptioną įveikti reiks tiek pat laiko, kiek kokį nors ROT13...
 
Palyginimai labai negeri. DB apsaugoti slaptažodžiais reikia, nes, pirmiausiai, ginamės nuo kitų vartotojų tame pačiame serveryje (ar tai būtų kiti sharedo/cloudo vartotojai, ar webshellas su `www-data`).
 
HTTPS pats yra saugus, o Heartbleed yra vienos TLS implementacijos side-effectas. Bugas kuris net neatsirado dėl HTTPS protokolo spragos, o pačių susikurto papildymo jam (ir dar visiškai bukos klaidos su atminties valdymu).
 
Žodžiu, primygtinai siūlai šifravimą, kuris neefektyvus, nes raktas yra pasiekiamas įsilaužėliui. Tai tas pats, kaip uždėti tavo minėtą spyną, o raktą padėti šalia jos.
 
Iš esmės šiaudinę baidyklę / slidžią nuokalnę darai su mano argumentais. Aš nesakau, kad reikia nesisaugoti akivaizdžiai tinkamais ir efektyviais būdais. Bet, dar kart, tokio šifravimo, kaip siūlai, dar nežinai, kaip padaryti efektyvaus. Galiausiai, galėdamas redaguoti failus, įsilaužėlis tiesiog įkiš naujas užklausas į jau esamos aplikacijos kodą (kuri kažkaip stebuklingai bus saugiai iššifravusi duomenis).

Trolis.

Trolis.

Daug kalbi ir nieko nepasiūlai. Sakai, kad encryptionas yra super easy, bet esmė, kad negali pasiūlyti efektyvaus modelio, nes yra ta problema, kurią jau keliskart minėjau. O encryptinus ir šalia laikant raktą tai encryptioną įveikti reiks tiek pat laiko, kiek kokį nors ROT13...
 
Palyginimai labai negeri. DB apsaugoti slaptažodžiais reikia, nes, pirmiausiai, ginamės nuo kitų vartotojų tame pačiame serveryje (ar tai būtų kiti sharedo/cloudo vartotojai, ar webshellas su `www-data`).
 
HTTPS pats yra saugus, o Heartbleed yra vienos TLS implementacijos side-effectas. Bugas kuris net neatsirado dėl HTTPS protokolo spragos, o pačių susikurto papildymo jam (ir dar visiškai bukos klaidos su atminties valdymu).
 
Žodžiu, primygtinai siūlai šifravimą, kuris neefektyvus, nes raktas yra pasiekiamas įsilaužėliui. Tai tas pats, kaip uždėti tavo minėtą spyną, o raktą padėti šalia jos.
 
Iš esmės šiaudinę baidyklę / slidžią nuokalnę darai su mano argumentais. Aš nesakau, kad reikia nesisaugoti akivaizdžiai tinkamais ir efektyviais būdais. Bet, dar kart, tokio šifravimo, kaip siūlai, dar nežinai, kaip padaryti efektyvaus. Galiausiai, galėdamas redaguoti failus, įsilaužėlis tiesiog įkiš naujas užklausas į jau esamos aplikacijos kodą (kuri kažkaip stebuklingai bus saugiai iššifravusi duomenis).

Daug kalbi ir nieko nepasiūlai. Sakai, kad encryptionas yra super easy, bet esmė, kad negali pasiūlyti efektyvaus modelio, nes yra ta problema, kurią jau keliskart minėjau. O encryptinus ir šalia laikant raktą tai encryptioną įveikti reiks tiek pat laiko, kiek kokį nors ROT13...
 
Palyginimai labai negeri. DB apsaugoti slaptažodžiais reikia, nes, pirmiausiai, ginamės nuo kitų vartotojų tame pačiame serveryje (ar tai būtų kiti sharedo/cloudo vartotojai, ar webshellas su `www-data`).
 
HTTPS pats yra saugus, o Heartbleed yra vienos TLS implementacijos side-effectas. Bugas kuris net neatsirado dėl HTTPS protokolo spragos, o pačių susikurto papildymo jam (ir dar visiškai bukos klaidos su atminties valdymu).
 
Žodžiu, primygtinai siūlai šifravimą, kuris neefektyvus, nes raktas yra pasiekiamas įsilaužėliui. Tai tas pats, kaip uždėti tavo minėtą spyną, o raktą padėti šalia jos.
 
Iš esmės šiaudinę baidyklę / slidžią nuokalnę darai su mano argumentais. Aš nesakau, kad reikia nesisaugoti akivaizdžiai tinkamais ir efektyviais būdais. Bet, dar kart, tokio šifravimo, kaip siūlai, dar nežinai, kaip padaryti efektyvaus. Galiausiai, galėdamas redaguoti failus, įsilaužėlis tiesiog įkiš naujas užklausas į jau esamos aplikacijos kodą (kuri kažkaip stebuklingai bus saugiai iššifravusi duomenis).

Daug kalbi ir nieko nepasiūlai. Sakai, kad encryptionas yra super easy, bet esmė, kad negali pasiūlyti efektyvaus modelio, nes yra ta problema, kurią jau keliskart minėjau. O encryptinus ir šalia laikant raktą tai encryptioną įveikti reiks tiek pat laiko, kiek kokį nors ROT13...
 
Palyginimai labai negeri. DB apsaugoti slaptažodžiais reikia, nes, pirmiausiai, ginamės nuo kitų vartotojų tame pačiame serveryje (ar tai būtų kiti sharedo/cloudo vartotojai, ar webshellas su `www-data`).
 
HTTPS pats yra saugus, o Heartbleed yra vienos TLS implementacijos side-effectas. Bugas kuris net neatsirado dėl HTTPS protokolo spragos, o pačių susikurto papildymo jam (ir dar visiškai bukos klaidos su atminties valdymu).
 
Žodžiu, primygtinai siūlai šifravimą, kuris neefektyvus, nes raktas yra pasiekiamas įsilaužėliui. Tai tas pats, kaip uždėti tavo minėtą spyną, o raktą padėti šalia jos.
 
Iš esmės šiaudinę baidyklę / slidžią nuokalnę darai su mano argumentais. Aš nesakau, kad reikia nesisaugoti akivaizdžiai tinkamais ir efektyviais būdais. Bet, dar kart, tokio šifravimo, kaip siūlai, dar nežinai, kaip padaryti efektyvaus. Galiausiai, galėdamas redaguoti failus, įsilaužėlis tiesiog įkiš naujas užklausas į jau esamos aplikacijos kodą (kuri kažkaip stebuklingai bus saugiai iššifravusi duomenis).

Daug kalbi ir nieko nepasiūlai. Sakai, kad encryptionas yra super easy, bet esmė, kad negali pasiūlyti efektyvaus modelio, nes yra ta problema, kurią jau keliskart minėjau. O encryptinus ir šalia laikant raktą tai encryptioną įveikti reiks tiek pat laiko, kiek kokį nors ROT13...
 
Palyginimai labai negeri. DB apsaugoti slaptažodžiais reikia, nes, pirmiausiai, ginamės nuo kitų vartotojų tame pačiame serveryje (ar tai būtų kiti sharedo/cloudo vartotojai, ar webshellas su `www-data`).
 
HTTPS pats yra saugus, o Heartbleed yra vienos TLS implementacijos side-effectas. Bugas kuris net neatsirado dėl HTTPS protokolo spragos, o pačių susikurto papildymo jam (ir dar visiškai bukos klaidos su atminties valdymu).
 
Žodžiu, primygtinai siūlai šifravimą, kuris neefektyvus, nes raktas yra pasiekiamas įsilaužėliui. Tai tas pats, kaip uždėti tavo minėtą spyną, o raktą padėti šalia jos.
 
Iš esmės šiaudinę baidyklę / slidžią nuokalnę darai su mano argumentais. Aš nesakau, kad reikia nesisaugoti akivaizdžiai tinkamais ir efektyviais būdais. Bet, dar kart, tokio šifravimo, kaip siūlai, dar nežinai, kaip padaryti efektyvaus. Galiausiai, galėdamas redaguoti failus, įsilaužėlis tiesiog įkiš naujas užklausas į jau esamos aplikacijos kodą (kuri kažkaip stebuklingai bus saugiai iššifravusi duomenis).

Neįsivaizduoju saugios vietos raktams. Pateik konkrečių pavyzdžių, kaip tą įgyvendinti web app. :)

Na vat, net ir failų checksumams netinka. :D
 
Omeny turėjau ne security sensitive checksums, o pasitikrinti, ar failas parsisiųstas nekoruptintas ir pan.

Čia cpp? Daugelyje kalbų ^ reiškia XOR.
Kelti laipsniu gali su pow(double x, double y), reikia includinti "cmath", gali tekti nurodyti -lm flagą kompiliatoriui (ant C reikia, nežinau kaip su C++).
 
Laipsnio kėlimo funkcija dažniausiai būna pow (gali būti Math namespace), arba ** operatorius ( x ** y ).

Labai teisinga pastaba - reikia nuolat sekti tai kas vyksta ir virti tame reikale, tada nesunkiai susigaudysi kur geros praktikos ir kur kokia info naudinga. Bet mes kalbame apie tuos, kurie nėra (dar) profesionalūs programuotojai, jie nedalyvauja dar bendruomenėse, o pradėti nuo kažko nori. Jie nežino kas yra PHP "The right way", nes nežino jokio "way" apskritai :)
 
O tie, kurie pasiekė tokį lygį, kad patys atskiria grūdus nuo pelų, tai šitoje bendruomenėje ras kitą privalumą - pvz, sakykim, negi nebūtų smagu kartu su 20 bendraminčių lietuvių pasimokyti Laravel ir dar vieniems su kitais pasikonsultuoti? Papildoma grupinė motyvacija o ne tiesiog tutorialų skaitymas. Na, čia jau aišku priklauso kaip visas tas mokymasis bus suorganizuotas, tai kol kas iki mano projekto alfa-versijos detales pasilaikysiu paslaptyje.