Înainte să scrii cod…

Cred că o mare parte dintre problemele cu care se confrunta un proiect, în ceea ce privește implementarea, ar putea fi prevăzute și evitate înainte de a scrie vreo linie de cod, dacă s-ar parcurge, cu calm și poate o doză de detașament următorii pași:

Clarifică scopul proiectului

E un pas mare și important, însă tot pe atât de ignorat și ”pus la colț” când vine vorba de detalii tehnice. Eu vin din câmpul dezvoltării și programării de sait-uri  web, și uneori se întâmplă ca clientul să fie foarte încântat de design-ul prezentat și să semneze contractul pe loc. Însă peste câteva săptămâni, aproape de lansare să realizeze că design-ul saitului e total ”afon” de scopul acelui sait. Da da, putem discuta zile în șir și să ajungem la concluzia că scopul unui sait e ”să vândă”, dar chiar ai nevoie de un design plin de briz-briz-uri pentru asta? – vezi Amazon

Așadar, ca programator e esențial să înțelegi scopul proiectului la care lucrezi. Asta te va ajuta să împarți cerințele clientului în versiuni să-ți programezi milestone-urile și desigur data când o versiune stabilă va ieși pe poarta ”laboratorului”.

Eh, da o să fie și proiecte al căror scop va suna așa: ”Sait nou pentru compania X”, ”re-branding pentru agenția Y” – dar dacă proiectul nu are un scop bine definit, poate că nici nu merită investiția de timp. Deci un pont pentru managerii de proiecte: faceți tot posibilul să vă convingeți programatorii că lucrează la ceva important.

Vezi ce au făcut și alții

De multe ori poți avea impresia că ești pus în fața unei probleme unice. Și în 1% din cazuri așa e. Deci pentru o mare parte din cazuri există posibilitatea ca cineva să fi abordat deja aceeași problemă și chiar să o fi rezolvat. Poate cu mici nuanțe dar în definitiv, a găsit o soluție. Acuma nu mă refer aici la chestii ca trimiterea unui newsletter sau crearea unui slideshow. Acesta nu sunt probleme, ci sunt task-uri. Dacă ai înțeles bine scopul proiectului, atunci înseamnă că ai o imagine a formei lui finale, deci de ce să nu vezi cum au abordat alții acest tip de proiecte?

Citește documentația

O mare parte dintre bug-urile cu care se confruntă programatorii, sunt un rezultat al faptului că nu au citit toată documentația. Sau uneori chiar nu au citit-o deloc. De fapt uneori ajung să re-implementeze o funcție care era deja într-o librărie standard. Deci revizuirea documentației, chiar dacă plicticoasă e vitală, înainte de a scrie cod.

Supune design-ul la use-cases

Acest task ar trebui executat de un tester, sau o personană responsabilă de QA, dar dacă nu e nici un ins cu asemenea etichetă prin preajmă, tu ca programator ar trebui să o faci, înainte de a scrie cod. Sfatul meu ar e să o faci oricum.
Când programezi pentru web, un buton în plus sau în minus nu e așa de greu de adăugat, dar ce te faci dacă butonul respectiv trebuie să aibă text în 4 limbi, și cuvântul corespondent din estoniană are 24 de litere :P .  Da, se întâmplă așa des ca design-ul să ignore complet utilizatorul și să se axeze exclusiv pe a ”arăta bine”.

În consecință dacă nu-ți place să re-modelezi HTML și CSS (și mie îmi place tetrisul, dar uneori devine enervant :P ), supune design-ul la use-cases și dacă ceva ”dă cu virgulă” un project manager ar trebui să știe, înainte să începi să scrii cod.

10 Filme care ți-ar putea schimba atitudinea despre viață

Am strâns o listă de 10 filme, pe care le recomand oricui pregătit să-și deschidă mintea și să pună în balanță atitudinea sa asupra vieții și a altor întrebări mai mult sau mai puțin existențiale.

Unele dintre ele (Primer, Sublime, Ghost in the Shell) pot fi mai greu de „digerat” dar sunt sigur că vă vor trezi interesul pentru o a doua vizionare.

Sfaturi pentru un web mai sigur (I)

Cred că ați observat de o vreme la mine pe blog că a apărut o categorie nouă – Jurnalul de securitate, unde postez mai ales avertizări și notificări de securitate.

Dar m-am gândit să postez și câteva sfaturi și șmecherii din experiența proprie pentru utilizatorii și dezvoltatorii de aplicații și saituri web. Așa că am început seria asta de articole, care sper să contribuie măcar cu cu 0, (mulți de 0) 1 la sută la un web mai sigur și mai bun.

Ahoi, MD5!

Care ar fi problemele cu MD5? Păi cei care fac aplicații pe web, știu probabil că e o funcție de hashing. Nu, nu e funcție de criptare cum zic unii, pentru că o funcție de criptare are o funcție complementară de decriptare, iar md5 nu poate fi decriptată. Tocmai de aceea este modalitatea preferată de multe aplicații web, și nu numai de a stoca parolele în baza de date.

Problema cu md5 e că e că e ”bătrân” .  A fost inventat în 1991 și de atunci au început să se facă dicționare pentru el. Dicționarele sunt cuvinte și combinații de cuvinte gata trecute printr-un md5() pe care un hacker le poate folosi într-un brute force attack.

Acum 10 ani să execuți un astfel de atac cu câteva zeci de mii ce cuvinte, date fiind limitările în puterea de procesare ar fi durat câteva luni, dar în ziua de azi, cu tehnologiile disponibile (enumăr aici cloud computing, remote code execution) și puterea de procesare a calculatoarelor acelaș atac se poate executa în câteva ore. Și vă mai informez că dicționarele de azi au milioane de combinații. NB: limba română are aproximativ 180 de mii de cuvinte, deci probabilitatea ca un cuvânt să se găsească deja într-un dicționar de md5 e de 1000% sau mai mare.

Alte neajunsuri ale md5

Alte neajunsuri în materie de securitate ale md5 sunt coliziunile. Adică două combinații diferite de caractere au acelaș hash. Sunt destul de rare, însă pot ușura clonarea sesiunilor și mai departe controlul asupra unei mașini sau a unui cont de utilizator. Sau chiar un atac de tip DoS, care să țintească direct compilatorul, interpretorul sau mașina virtuală din spatele unei aplicații web.

Un MD5 mai bun

Cred că e clar că md5 direct pentru a cripta parolele nu mai e o alternativă fiabilă. Dar îl putem face mai eficace folosind câteva artificii ușor de aplicat:

MD5 la pătrat

Sau md5 aplicat de 2 ori, sau de 3 ori. Așa în loc de un singur md5, facem md5 la parolă de mai multe ori. În majoritatea cazurilor md5 se execută foarte rapid, așa că nu se va observa diferența:

Acest mod nu evită însă și coliziunile.

MD5 cu o cheie

Alt mod de a îmbunătăți MD5 este folosind o cheie e specifică aplicației noastre. De ex:

În acest mod se evită și coliziunile, iar dacă cheia poate fi personalizată de utilizator, sau se generează automat la instalarea aplicației oferă și mai multă securitate.

Combinarea metodelor

Pentru și mai multă securitate putem combina metodele de mai sus, sau chiar adăuga generatoare de chei pornind de la parolă și cheia originală. Câteva exemple de funcții, în Python:

Un md5 și mai bun

O soluție și mai bună de criptare a parolelor este renunțarea la md5, și folosirea unui algoritm cu mai puține vulnerabilități: SHA-256, SHA-512, RIPEMD, HAVAL, GOST, bcrypt sau PBKDF2.

PHP de la versiunea 5 încoace oferă cu funcția hash() o varietate mare de algoritme.

O idee pentru o criptare mai puternică este să utilizam un algoritm aleatoriu pentru criptarea parolei, la care îi putem asocia un nume intern specific aplicației noastre, stocat și în baza de date. Folosind combinații de chei sau funcții mai avansate personalizate per-aplicație putem asigura un nivel foarte înalt de securizare a parolelor.

Concluzie, cu gândul la viitor

Încă nu s-a inventat un algoritm 100% sigur care să nu poată fi spart printr-o metodă sau alta. Dar prima regulă de securitate este să-ți sfătuiești utilizatorii cum să-și protejeze datele. Mai ales să-i îndemni să-și schimbe parolele măcar o dată pe an.