Newsgroup: it.comp.sicurezza.varie
Titolo: forzare il periodico cambio password non è sicuro

lo dice il nist. e non mi sento di dargli torto.
 
 
https://www.bleepingcomputer.com/news/security/aligning-your-password-
 
policy-enforcement-with-nist-guidelines/
 

 
https://www.bleepingcomputer.com/news/security/aligning-your-password-policy-enforcement-with-nist-guidelines/
 
 
Proprio stamani, usando lo SPID per entrare nel Fascicolo Sanitario, 
sono stato invitato a cambiare *obbligatoriamente* la pass.
 
L'ho fatto. Risposta: pass troppo simile, scegline un'altra con queste 
caratteristiche, le solite che già conosciamo. :-)
 
Quindi, un certo controllo viene comunque fatto.
Tuttavia è seccante essere obbligati a cambiare la pass anche se questa 
non è stata violata.
-- 
    * b *
  *   y   *
*   Pierо   *
#v+
-errare humanum est-
#v-
 
 

 
 
windows non è così sofisticato, ho un cliente che ogni volta incrementa il 
numero: recentemente era qualcosa tipo ginosarca17
quando vado a trovarlo la prima domanda, dopo i saluti, è "a che numero 
siamo arrivati?"
 
-- 
/-\ /\/\ /\/\ /-\ /\/\ /\/\ /-\ T /-\
-=- -=- -=- -=- -=- -=- -=- -=- - -=-
........... [ al lavoro ] ...........

 caratteristiche, le solite che già conosciamo. :-)
 
per curiosità, cosa aveva per essere troppo simile?
in teoria non può saperlo, anche se per alcune similitudini mi vengono in 
mente tecniche per individuarle.

 arrivati?"
 
beh non esiste su windows una policy di questo tipo, ne è possibile capire 
se a due hash corrispondono due payload "simili". per questo ho chiesto 
che similitudine aveva la nuova password con la vecchia: i casi sono due, 
o adottano una tecnica specifica (ma possono individuare solo un certo 
tipo di similitudine, come ad esempio un solo carattere cambiato) 
oppure... non oso dirlo.

 beh non esiste su windows una policy di questo tipo, ne è possibile
 
https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/enforce-password-history
 
 
 


Lo dice anche Troy Hunt e da un bel po' e mi fido.
Conviene monitorare i leak eventualmente, piuttosto che chiedere
periodicamente di cambiare delle password sicure.
Aggiungo che è ora di finirla con quei siti che obbligano a usare una
determinata forma (tipo: metti un numero, metti la minuscola) però hanno un
limite esiguo di caratteri tipo 16 max e parlo anche di istutuzioni
finanziarie.


A me vengono i brividi quando esce quel tipo di avviso, non sapendo appunto
cosa usino per il confronto e mi viene pure il dubbio su come vengano
registrate le password.

 vengano registrate le password.
 
ma che dubbio e dubbio, salvano la password precedente, e se non è in
chiaro, al massimo viene *codificata* in base64 (ma se lo chiedi ti
diranno che è "crittata") :P
 
 
 
 
 

 al massimo viene *codificata* in base64
 
Spero sia una battuta...

 in mente tecniche per individuarle.
 
Avevo cambiato due caratteri, all'inizio e alla fine della pass.
-- 
    * b *
  *   y   *
*   Pierо   *
#v+
Tutto il futuro è racchiuso nella sacra sillaba "bo!".
#v-
 
 

 Spero sia una battuta...
 
magari mi sbaglio, forse ad oggi la comprimono con zlib prima di
codificarla in base64
 
:P
 
 
 
 

 magari mi sbaglio,
 
 
Magari?
 
 
 


ma chi lo fa? fra l'altro salvarsi la password precedente vuol dire 
essersi salvato in precedenza la password corrente... 
 
in una discussione su twitter si parlava di tecniche per capire se una 
password differisce per uno o due caratteri. in pratica una soluzione 
poteva essere; data una password di n caratteri, salvarsi tutti gli hash 
della pwd a cui ciclicamente venivano tolti due caratteri. applicando lo 
stesso algoritmo alla nuova pwd e confrontando gli x hash, se uno 
corrispondeva voleva dire che la nuova pwd differiva dalla vecchia solo 
per uno dei due caratteri mancanti, o entrambi.
 
ovviamente per non dare informazioni aggiuntive sulla password (es. la sua 
lunghezza) il numero di hash salvati doveva essere un numero fisso, pari 
ad esempio alla lunghezza massima accettata. 

Il Thu, 4 Aug 2022 16:22:50 +0200, ObiWan ha scritto:
 

ah poi bisogna anche vedere il processo: in molti casi al cambio password 
chiedono la vecchia password oltre alla nuova, il che vuol dire che ce 
l'hanno bella lì in chiaro per fare tutti i confronti che vogliono :-)

 vogliono :-)
 
No, questo NON è necessario :)
 
Ti faccio un esempio; diciamo che una qualsiasi entità debba gestire
delle password, ora, la FESSERIA più grossa che ci possa essere è
quella di salvare la password crittata, specie poi se con un tipo di
crittografia reversibile, dato che questo da solo implica che possa
essere possibile, partendo dalla password crittata, riottenere quella
originale, il che a sua volta significa che se qualcuno ti "frega" il
DB delle password, è possibile che le stesse possano venire recuperate,
alla fine della fiera, se uno ha il tuo DB delle password, ha tutto il
tempo che vuole (ok, quasi) per cercare di craccarle
 
L'approccio corretto, invece, è quello di usare un hash, provo a farti
un esempio
 
supponiamo che io mi registri presso un qualche sito ed immetta come
password 
 
"Kr4cK.M3.f00l!"
 
il sito prende la mia password, genera un valore random, che in gergo
si chiama "salt", lo aggiunge alla stessa e quindi calcola l'hash della
mia password con l'aggiunta del "salt", supponendo che il "salt" sia,
ad esempio
 
"=hN`'RBQs -3yXx&"
 
la stringa risultante potrà essere qualcosa del tipo
 
 
"Kr4cK.M3.f00l!=hN`'RBQs -3yXx&"
 
a questo punto, il sito andrà a calcolarsi l'hash della stringa di cui
sopra, ottenendo (nel caso di SHA256) questo valore
 
"9e0625848653124f5510231342b000e8ee44b4d74678bd0999978d7a466a5b95"
 
fatto questo, il sito andrà a memorizzare da qualche parte (tipicamente
in un DB di backend) il valore del "salt" (che OCCHIO, NON deve essere
sempre lo stesso, ma essere generato ogni volta in modo casuale)
insieme al valore hash di cui sopra
 
ora... indovina come si fa a controllare se, al succesivo tentativo di
login, la password sia corretta :D
 
 

 login, la password sia corretta :D
 
dimenticavo...
 
1. quanto descritto permette anche di verificare la pass precedente
 
2. quanto descritto è corretto e funzionante, MA come ho spiegato in
   altro "ambiente" espone a vulnerabilità nel caso in cui qualcuno
   abbia accesso al DB che contiene gli hash
 
3. anche se non strettamente necessario, è possibile evitare di dover
   memorizzare i "salt" relativi alle varie utenze
 
ma lascio quanto sopra come "compitino a casa" :D
 

 No, questo NON è necessario :)
 
forse non mi sono spiegato. è chiaro come devono essere gestite le 
password quindi tutto il discorso degli hash, salt e quant'altro. mi 
riferivo alla possibilità di verificare se una nuova password sia *simile* 
alla vecchia, ovvero che differisca ad esempio solo di un carattere. è 
ovvio che con l'hash questo tipo di confronto non lo puoi fare.
se però nel processo di cambio password chiedi all'utente anche la vecchia 
password (e in molti casi questo viene fatto) al backend arriva sia la 
nuova password che la vecchia e quindi puoi fare tutti i confronti che 
vuoi.  


Infatti, per cambiare la pass dovevo inserire prima la vecchia, scrivere
la nuova e ripeterla... come sempre.
Poi interverrà un algoritmo, o forse uno script, per confrontarla.
-- 
    * b *
  *   y   *
*   Pierо   *
#v+
È un genio della scrittura, ha inventato il paragrafo senza fili.
#v-
 
 

 Poi interverrà un algoritmo, o forse uno script, per confrontarla.
 
Lo "script" a cui ti riferisci probabilmente è un pezzo di codice, per
il resto, il confronto NON viene fatto tra password, dato che queste
NON DEBBONO essere memorizzate.
 
 
 

 Poi interverrà un algoritmo, o forse uno script, per confrontarla.
 
Lo "script" a cui ti riferisci probabilmente è un pezzo di codice
eseguito lato server, per il resto, il confronto NON viene fatto tra


 Poi interverrà un algoritmo, o forse uno script, per confrontarla.
 
quindi il mistero è svelato :-)


Non mi torna quello che dici: il confronto NON viene fatto tra password.
 
Il confronto deve avvenire, perché non si spiega diversamente quello che
ho scritto precedentemente:
 
.............. _*Beginning of the citation*_ ..............
L'ho fatto. Risposta: pass troppo simile, scegline un'altra con queste
caratteristiche, le solite che già conosciamo.
............... _*The end of the citation*_ ...............
 
e non serve che le password vengano memorizzate, è sufficiente quella
che ho dovuto inserire prima di essere avvertito del cambio
obbligatorio.
 
Questo avviene nella stessa sessione, confronto e alert sul cambio.
Non mi spiego un modo diverso, per cambiare la vecchia pass con la
nuova.
-- 
    * b *
  *   y   *
*   Pierо   *
#v+
Assolto perché il fatto non costituisce dibattito.
#v-
 

 nuova.
 
Potrebbe il confronto vecchia/nuova essere fatto a monte di tutto, a 
livello di browser?
Del resto vecchia e nuova password in quel momento vengono scritte in 
chiaro nel browser...
 
Potrebbe essere che abbia detto una imbecillità... :/

 Potrebbe essere che abbia detto una imbecillità... :/
 
No, fino a prova contraria vale questa ipotesi. :-)
-- 
    * b *
  *   y   *
*   Pierо   *
#v+
-cogito ergo sum-
#v-
 
 

lo dice il nist. e non mi sento di dargli torto.
 
...ed è anche una discreta rottura di scatole.
 
Dal momento che una password di 8 cifre di sole lettere e numeri (62 caratteri)
prevede 62 ^8 combinazioni = 218.340.105.584.896, il bruteforce è improponibile
anche con password relativamente corte.
 
Per 8 cifre e 90 caratteri (tutti gi ASCII da "0" =32 a "z" =122) invece siamo a
90^8 = 4.304.672.100.000.000, un discreto lavoro anche per un computer
quantistico, e sono solo 8 cifre.
Con 9 cifre invece siamo a 387.420.489.000.000.000 combinazioni.
 
Quindi non è molto razionale la continua richiesta di cambiare la password,
perchè non è affatto detto che la successiva sia più sicura della precedente.
 
 
Il codice del mio bancomat ad esempio è lo stesso da sempre anche se ogni tanto
cambia la card, e non vorrei proprio sprecare dei neuroni per impararne un'altro
solo perchè a un burocrate del cavolo viene un'idea balzana.
 
 
-- 
ciao
  Stefano

 bruteforce è improponibile anche con password relativamente corte.
 
ma infatti se la password è sufficientemente strong e non è compromessa 
cosa aggiunge cambiarla dopo due/tre mesi?
di contro la rottura di scatole spinge gli utenti a creare password meno 
forti, o a una gestione meno sicura delle credenziali.
 

 forti, o a una gestione meno sicura delle credenziali.
 
Non credo che lo scopo sia quello della robustezza della password, ma penso
che il cambio forzato sia per proteggersi dalla possibile compromissione.
 
Tu un bel giorno cambi la password perchè il sistema te lo impone, ed il
"cattivo" viene tagliato fuori.
 
Palese che se il "cattivo" ha scoperto la prima password, potrebbe benissimo
soprire la nuova, ma questa è un'altra storia.
 
 
-- 
Ieri in piazza c'era un tale che affermava che la Terra è piatta!
Ma se lo sanno tutti che la Terra è a forma di triangolo asintotico inverso!
E che assieme alla Luna ed il Sole ha un'orbita cisoidale verso Marzo!

 ...in teoria...
 
in teoria dovrebbe essere così, vanificare gli attacchi. in pratica però 
se come dice l'articolo (e io sono d'accordo) forzare il cambio password 
spinge gli utenti (non tutti, ovviamente) ad usare password semplici, tipo 
una parola di dizionario con un progressivo, l'effetto è esattamente 
opposto. 



 è esattamente opposto. 
 
Beh, evitare che venga usata una parola di dizionario è possibile, si
tratta semplicemente di impostare delle regole di complessità della
password e rifiutare le pass che non soddisfano tali regole; il vero
problema è un altro, ossia il "riuso" delle password, in breve, c'è chi
per semplificarsi la vita usa la stessa identica password per l'accesso
a servizi diversi, a quel punto, se uno dei servizi viene violato, o
comunque la password per lo stesso viene "rubata", tutti gli account di
quell'utente diventano a rischio, ed il problema si aggrava nel caso in
cui i vari servizi per i quali la password è stata usata non richiedono
un cambio password periodico, mi spiego meglio
 
Supponiamo che "Mario Rossi" abbia un account (logon) aziendale con
tanto di email, un account email esterno, ... altri account... e magari
anche un account su una piattaforma di gaming online e che abbia usato
la stessa password per tutti gli account, ora, se la piattaforma di
gaming viene violata, e se viene "recuperata" la password, è probabile
che tra i vari dati del profilo utente ci sia anche l'indirizzo email
esterno (es. usato per l'iscrizione e per i contatti); a quel punto la
prima cosa che farà chi è entrato in possesso delle info sarà provare
la stessa password usata per la piattaforma di gaming per accedere alla
mail esterna e se in tale casella di posta fossero presenti delle email
che fanno riferimento a quella aziendale, il secondo passo sarebbe
quello di provare l'accesso anche al sistema aziendale...
 
Se invece l'azienda imponesse agli utenti un cambio periodico della
password, è probabile che la password usata per l'accesso alla
piattaforma di gaming sia, ad un certo punto, diversa da quella in uso
per l'accesso aziendale; ovvio che il problema NON viene risolto del
tutto, ma per lo meno viene attenuato almeno in parte