Un utente finale può solo sperare che la sua password sia sottoposta a hash, fino a quando il sito non viene violato e le password (o, si spera, le versioni salate e con hash) vengono divulgate al pubblico.
Come manager, hai altre opzioni. È possibile chiedere dove sono archiviate le password e verificare che non siano archiviate in testo normale.
Potresti fare un ulteriore passo avanti e renderlo parte di un processo di test automatizzato - creare un nuovo utente, con una password randomizzata. Verificare che la nuova password non compaia nella tabella del database che memorizza i dati di autenticazione dell'utente. Potresti anche andare oltre e testare se la tabella che stai guardando, in realtà è la tabella utilizzata per l'autenticazione dell'utente, ad esempio rimuovendo con forza l'utente a livello di database e cercando di accedere di nuovo.
I sistemi automatici, sfortunatamente, non possono darti una garanzia al 100% che le password non siano memorizzate in testo da qualche parte nel codice.
Anche il processo umano è incline all'errore e trascura le cose. Tuttavia, la combinazione di buoni test automatizzati e un buon processo umano (ad esempio recensioni di codici) dovrebbe darti sufficiente sicurezza che i dati dell'utente siano protetti in modo appropriato. Oppure, se il peggio arriva al peggio, almeno hai fatto uno sforzo serio per proteggere i dati.
Poiché Khajak Vahanyan indica nei commenti, SSL / TLS non ha nulla a che fare con questo. SSL / TLS riguarda il modo in cui i dati vengono trasferiti a nell'applicazione, non in merito a ciò che accade ai dati in seguito.