> Impersonate them on a service that has a compromised database? Maybe. I think in this particular case, users don't even really lose anything by having someone

> Impersonate them on a service that has a compromised database? Maybe. I think in this particular case, users don't even really lose anything by having someone else access their account. You could argue that the main reason for having any password in this particular case is so that attackers don't get free access to paid course material. This lets someone with readonly DB access (for instance, from compromising a backup) escalate to making changes in a user's account. That's significant. Maybe the account doesn't protect anything, but it's still a really bad look - and how much would you bet that they would have fixed this before expanding the site's functionality? > If we're looking for more realistic attacks, I can see that their site is vulnerable to CSRF logins. I mean, they already demonstrated incompetency. Finding more vulnerabilities at this point is very much expected.