Filippo94
Certamente, ma sono comunque valori molto più alti di avere collisione usando una key derivation function h con output a tanti bit (almeno 256) con un'ottima weakly collision resistance (è computazionalmente difficile trovare, data una chiave x, una chiave y t.c. h(y) = h(x) ).
Anche trovare a caso due chiavi con la stessa derivazione, pur essendo più semplice del problema di sopra per il paradosso del compleanno, richiede molti più tentativi.
Tutto questo per dire che l'autenticazione biometrica è un compromesso efficace, così come lo è un password manager (abbiamo un singolo point of failure), così come lo è usare un pattern comune quando si inventano le password (del tipo "solitapassword.nomesito").
La sicurezza impiegata dipende dalle specifiche circostanze e dai rischi che siamo disposti a correre a fronte di maggiori comodità e immediatezza.
Per esempio, un pin di 10 cifre sullo smartphone è più sicuro dell'impronta (ed è il motivo per cui al primo avvio si richiede il codice stesso, addirittura Android con la FDE lo richiedeva prima di iniziare a caricare il SO se Avvio Sicuro era abilitato nelle impostazioni), ma è assurdo doverlo inserire almeno cinquanta volte al giorno. Quindi si va di impronte, di sblocco facciale, di iride.
Filippo94 parlo per i sistemi Apple: le impronte sono nel Secure Enclave che ad oggi è un sistema sicurissimo
Il chip T2 di OSX però sembra essere stato compromesso (https://ironpeak.be/blog/crouching-t2-hidden-danger/, https://9to5mac.com/2020/10/06/t2-security-chip-on-macs-can-be-hacked-to-plant-malware-cannot-be-patched/). Si trattano tuttavia di casi particolari e praticamente impossibili da riprodurre.
Però il mio commento non era riferito al "ricavo le impronte dal Secure Enclave", ma trovo un modo di ricreare le impronte in altre maniere. Non è quindi la tecnologia di Apple/Microsoft/Samsung ad essere intrinsecamente più vulnerabile, ma proprio l'autenticazione biometrica, che è basata sul tentativo di minimizzare l'errore che però rimane.