Un usuario final solo puede esperar que su contraseña esté hasheada, hasta que el sitio sea hackeado y las contraseñas (o, con suerte, sus versiones con sal y hash) sean filtradas al público.
Como gerente, tienes algunas opciones más. Puede preguntar dónde se almacenan las contraseñas y verificar que no estén almacenadas en texto sin formato.
Podría llevar esto un paso más allá y hacerlo parte de un proceso de prueba automatizado: cree un nuevo usuario, con una contraseña aleatoria. Verifique que la nueva contraseña no aparezca en la tabla de la base de datos que almacena los datos de autenticación del usuario. Incluso podría ir más allá y probar si la tabla que mira, realmente es la tabla que se usa para la autenticación del usuario, por ejemplo, eliminando por la fuerza al usuario en el nivel de la base de datos e intentando iniciar sesión nuevamente.
Desafortunadamente, los sistemas automatizados no pueden ofrecerle una garantía del 100% de que las contraseñas no se almacenan en texto simple en alguna parte en el código.
El proceso humano también es propenso al error y pasa por alto las cosas. Sin embargo, la combinación de buenas pruebas automatizadas y un buen proceso humano (por ejemplo, revisiones de código) debería darle la suficiente confianza de que los datos de su usuario están protegidos adecuadamente. O, si lo peor es lo peor, que al menos hizo un esfuerzo serio para proteger los datos.
Como Khajak Vahanyan señala en los comentarios, SSL / TLS no tiene nada que ver con eso. SSL / TLS trata sobre cómo se transportan los datos a de la aplicación, no sobre qué sucede después con los datos.