In che modo questo meccanismo è considerato vulnerabilità?

L'articolo semplicemente non contiene informazioni sufficienti per valutare la situazione. L'invio di una password (senza ulteriore crittografia / hashing) su SSL / HTTPS è sicuro, se SSL viene utilizzato correttamente.

Forse la convalida del certificato era insufficiente, consentendo un MitM su SSL. (Uno dei commenti afferma che questo era il caso del tuo esempio.) Se non convalidi il certificato che il server ti invia, un utente malintenzionato può impersonare il server. In tale scenario le informazioni vengono comunque crittografate, ma con una chiave scelta dall'attaccante.

Contro gli attaccanti attivi, SSL è sicuro quanto la convalida del certificato.

Secondo l'articolo, le credenziali di accesso sono state inviate in chiaro dopo l'invio. Questa è sicuramente una vulnerabilità critica in quanto un utente malintenzionato non ha realmente bisogno di altre informazioni per assumere il controllo dell'account utente e fare ciò che gli pare.

Una vulnerabilità si riferisce semplicemente al fatto che password e nome utente vengono inviati in chiaro. I dati importanti devono sempre essere crittografati.

Con le informazioni in chiaro, l'uomo nell'attacco centrale può essere usato per annusare il traffico e modificarlo per il proprio scopo.

Forse l'app fa il suo login tls tramite una funzione iPhone imperfetta; quel difetto sarebbe che è bypassabile configurando le impostazioni di rete del sistema operativo del tuo telefono. (Alcuni datori di lavoro / governo potrebbero dire / costringere i dipendenti a configurare i propri telefoni / browser.)

Altrimenti, sarebbe come hai detto - il 750 USD non ha senso se l'app non ha nemmeno provato a usare tls in primo luogo (a meno che non sia per PR / marketing), che è lo stato di zillions di app sul mercato.