Le password di testo in chiaro non sono un problema. Il problema è con i rischi associati a quei dati. Qual è l'impatto sugli utenti e qual è l'impatto sull'azienda se questi dati vengono trapelati, divulgati, persi o danneggiati? E se fosse stato pubblicizzato che questi dati erano chiari, come descrivi?
Se non ci sono rischi, non ha senso implementare controlli costosi attorno ad esso.
Se ci sono rischi, allora i controlli devono essere ridimensionati con quei rischi.
So che è facile dire "OMG! Password di testo trasparente da un'app Web nel 2016?" Che tipo di azienda è questa? Ci sono numerose librerie che gli sviluppatori avrebbero potuto chiamare per occuparsi di questo da l'inizio!" So che l'ho fatto quando ho letto il tuo post.
Ma a questo punto, le modifiche all'ambiente devono avere senso in termini di rischi. Il tuo compito è non di fornire l'argomento tecnico o di sicurezza più convincente (se uno di questi argomenti avrebbe funzionato, il problema non esisterebbe). Invece, il tuo compito è quantificare i rischi per l'azienda e proporre un controllo appropriato a quei rischi per mitigarli. Ecco come procedi.
Se i rischi sono alti e costosi e non sono ancora interessati, chiedi loro se la loro assicurazione contro gli incendi è pagata. Piccoli investimenti possono evitare enormi perdite, proprio come le assicurazioni.
Se ancora non riesci a convincerli a far fronte a questo, allora ti rimane la sfortunata, ma valida, situazione di lasciare questa decisione aziendale nelle mani del business. Sopporta i rischi. Hai dato loro le informazioni necessarie per gestire tali rischi in modo appropriato. Non c'è molto altro che puoi fare.
Ma prima di arrivare alla fase fatalistica, fai una buona discussione sui rischi e su come puoi aiutarli a limitare l'esposizione dell'azienda.