Está usted visitando una publicación en la hemeroteca de CSIRT-CV.
Para acceder al portal y contenido actual, visite https://www.csirtcv.gva.es
25/09/2013
En este article m’agradaria donar consells sobre com podem afrontar estos processos perquè deriven en un millor resultat.
Emmagatzematge de contrasenyes
Este és el punt en què més errors es cometen, en molts casos pel fet que hi ha molta informació antiga molt ben posicionada en Google on arriba la gent i l'usa com a referència.
Oblida i soterra la temptació de xifrar la base de dades amb una única contrasenya i emmagatzemar dins les contrasenyes en clar. No, este esquema no és segur, delegues tota la seguretat en una única contrasenya que resulta fàcil d’obtindre (per exemple, revisant el codi del programa que carrega eixa base de dades). No utilitzes mai criptografia reversible per a guardar contrasenyes.
Fonamental: OBVIA L’ALGORITME MD5. Sí, de segur que veuràs molts exemples en Google que parlen d'MD5, de fet es continua usant en altres tasques, però no és mai aconsellable per a esta. Fes servir XA-512. Penalitza el rendiment respecte a MD5, però és imperceptible.
Empra tècniques de 'salting' a l’hora d’emmagatzemar el hash de la contrasenya. Usar salt significa que, si la contrasenya és 123456, en compte de guardar la representació d'123456 en la forma amb hash, el que fas és introduir un altre element que impedisca a un atacant usar un llistat de hashos de contrasenyes ja precompilat. És a dir, el que guardes és salt+123456, que òbviament genera un hash diferent d'123456 (i que un atacant podria tindre ja amb hash i així s'estalviaria el procés criptogràfic). En un típic esquema d’usuari/contrasenya per a una aplicació web, és ideal usar el correu electrònic com a salt, ja que és una dada coneguda i accessible (normalment s’envien correus de confirmació d’altes) de manera que, en l’exemple descrit abans, al final el hash es faria contra ental@entalaltre.com+123456
De nota: Usa PBKDF2 sobre els hashes que guardes. PBKDF2 és un estàndard RSA per a derivació de claus. Sense entrar en les profunditats matemàtiques, el que fa PBKDF2 és fer més costós el temps de computació d’un hash. Els algoritmes de la branca SHA són algoritmes dissenyats per a ser ràpids, és a dir, perquè el cost computacional no siga elevat. Això, vist des de la nostra perspectiva, significa que els hashes que emmagatzemarem si usem únicament SHA es poden atacar per la força bruta a un cost molt baix. Si usem PBKDF2 el que farem és que “coste” prou més generar el hash. Com deia al començament, això és de nota i SÍ que tindrà un impacte notable a l’hora de processar peticions d'inici de sessió en la teua aplicació. Per a una aplicació xicoteta i que requerisca màxima seguretat, ideal. Per a un Facebook, probablement no. Hi ha implementacions de PBKDF2 en tots els llenguatges típics.
Xifrar dades
Tractarem la qüestió de xifrar dades, una pràctica molt desitjable a l’hora de treballar amb documents o amb dades.
Evita l’ús dels algoritmes DES i RC4. En el cas de DES principalment perquè hi ha alternatives molt millors quant a algoritmes d’encriptació “de bloc”. El temps que invertisques amb un altre millor serà idèntic a usar el desfasat DES. En el cas de RC4, la cosa canvia, és un algoritme “simpàtic”, molt fàcil d’implementar perquè és “de flux”. No requerix complicar-se i, per tant, resulta temptador usar-lo (la veritat, per a un desenrotllament amb un nivell de seguretat baix, pot ser una opció).
Quan uses un algoritme “de bloc”, com AES, GOST o Blowfish, usa sempre el mode CBC, que impedix que una mateixa dada tinga el mateix aspecte en diferents punts de les dades xifrades. Si uses, per exemple, el mode ECB, significa que la representació xifrada de ' securitybydefault' sempre tindrà el mateix aspecte una vegada xifrat, cosa que pot facilitar la criptoanàlisi.
Algoritmes recomanats: AES, Blowfish i, si et fies dels russos, GOST
Desplegar SSL
Anem a la manera més òptima de desplegar un servici davall SSL.