Come hai detto, quando si utilizza una funzione di confronto delle stringhe che non è stata progettata per resistere agli attacchi temporali, potrebbe essere sfruttata per indovinare la stringa con cui si confronta.
Il confronto tra stringhe non criptate e non alterate in effetti perde la stringa originale, sia essa una password (memorizzata in un database o codificata), un ID di sessione, un indirizzo email o un token di autenticazione a più fattori, ovvero questo attacco è non limitato al senso comune di "password".
Se le stringhe sono crittografate e la funzione di crittografia è nota all'attaccante (con le chiavi associate), allora potrebbe indovinare la stringa crittografata, quindi decrittografarla per ottenere la stringa originale.
Se le stringhe sono hash e la funzione hash è nota all'attaccante (e il sale associato, se ce n'è uno), allora l'hash sarà sempre più difficile ogni byte (a causa di l'effetto valanga ), rendendo molto difficile indovinare più dei primi byte dell'hash, ma questo potrebbe essere sufficiente per la forza bruta se la stringa originale non ha abbastanza entropia.
Questo consiglio è vero quando stai confrontando qualsiasi stringa fornita dall'utente (o lo hai cancellato o meno) con qualsiasi tipo di dati sensibili (vedi sopra, personalmente ritengo che qualsiasi informazione relativa a un utente sia sensibile).