Il giorno lun, 29/10/2007 alle 10.50 +0100, Raffaele ha scritto:

> Visti i numerosi tentativi di "phishing" che girano, telefono subito al
> numero verde per avere delucidazioni. Dopo aver fornito il mio codice
> utente, l'operatore mi chiede se la precedente password conteneva dei
> caratteri non alfanumerici. Rispondo affermativamente e lui dice che
> sono cambiate le procedure per aumentare la sicurezza e ora il sistema
> accetta solo caratteri alfanumerici (!?!). In sostanza la password deve
> essere di questo tipo:
> 
> - deve essere diversa da quella precedente
> - deve essere lunga almeno 8 caratteri
> - deve contenere sia lettere che numeri
> - non deve avere più di 2 caratteri consecutivi identici (es.: bbb, 111)
> - non deve avere più di 2 caratteri consecutivi in sequenza
> crescente/decrescente (ad es.: abc, 987, …)
> - non deve contenere caratteri speciali (ad es.: ‘ , “ , < , < , ; , \ ,
> / , @ , & , % , …)
> - non deve essere vuota
> - non deve contenere l'Identificativo Utente.

Sono d'accordo con tutti, o quasi! :)

Giusto qualche punto da sottolineare.
In particolare, le best practice in termini di gestione di password
dovrebbero:
1. non usare la password in chiaro dal secondo layer in poi - Questo
permette in teoria di usare qualuque carattere. Il XSS non lo vedo
assolutamente come problema cosi' come la metti-un-layer-a-piacere
Injection. Infatti ci pensa il
SHA-256/BLOWFISH/metti-un-algoritmo-di-strong-hashing-a-piacere a
ridurre lo spazio di caratteri a-z-0-9 su N Bit

2. imporre almeno un numero minimo di caratteri secondo il cogente
(vigenti leggi) - se fosse possibile andrei sulle pass phrase cosi' di
moda oggi.

3. Il resto delle regole di costruzione della password e' buona prassi -
aumenta l'entropia.

4. Nessuno, tranne te, deve avere accesso alla password in chiaro! Il
discorso della scelta dei caratteri mi sembra mooolto fuori da ogni
logica. Persino quando dimentichi la password, si sa che non va
reinviata la stessa, saremmo altrimenti di fronte un problema _serio_ di
esposizione di dati sensibili.

5. IMHO 

6. Owasp Guidelines


Stefano

-- 
...oOOo...oOOo....
Stefano Di Paola
Software & Security Engineer

Owasp Italy R&D Director

Web: www.wisec.it
..................

Attachment: signature.asc
Description: Questa è una parte del messaggio firmata digitalmente

________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List

Rispondere a