We don't allow users to pick passwords so we don't store your information

Re:We don't allow users to pick passwords so we don't store ... by DuskStar on Friday December 06, 2019 @08:06PM (#21727726)

> 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.

[ Parent | on HN ]

Re:We don't allow users to pick passwords so we don't store ... by maxdamantus on Friday December 06, 2019 @08:26PM (#21727812)

> I mean, they already demonstrated incompetency. Finding more vulnerabilities at this point is very much expected.

You mean they've demonstrated that their security model is non-traditional? The point is that the CSRF login is probably a more significant attack vector, and many sites are vulnerable to such an attack.

Did you know the website you're using right now is vulnerable to a CSRF login attack? [0]

[0] https://maxdamantus.github.io/yccsrf.html

[ Parent | on HN ]