4 ms·

> The SECOND reason is so that the attacker can't now login as the user and impersonate them. Impersonate them on a service that has a compromised database? Ma

> The SECOND reason is so that the attacker can't now login as the user and impersonate them. 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. As usual with security, you need to make tradeoffs. They decided that users shouldn't have to deal with having to reset passwords (which is something I personally find quite annoying), and the tradeoff for that is not allowing people to specify their own password. As a bonus, this means it's impossible for the information stored in this database to be used to access another service (since a hashed shared password is still more useful than a non-shared password). > Also, with this setup it looks like it's impossible for the user to ever change the password, so one accident with that password and it's time to get a new account. That does indeed seem to be the case, so another improvement would be allowing users to generate a new password. If we're looking for more realistic attacks, I can see that their site is vulnerable to CSRF logins.

DuskStar 7y ago
> 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.
- maxdamantus 7y ago
  > 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 https://maxdamantus.github.io/yccsrf.html

DuskStar 7y ago

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

maxdamantus 7y ago
> 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 https://maxdamantus.github.io/yccsrf.html