The advantage of this is that they don't even see your password in memory as you log in. They only see their randomly generated one. Forcing users to use unique passwords (that is, not allowing the user to pick one) seems like a pretty good idea to me.
Fundamentally, I don't see anything wrong with this. People are already encouraged to use "password managers", which is essentially a workaround for the fact that most sites should not be using traditional password authentication. This system is basically forcing a similar level of security offered by password managers by enforcing the use of autogenerated (and therefore non-shared) passwords.
The main reason you hash passwords is so that if your database is compromised, it's difficult for an attacker to use that information to authenticate to another system. If your system is just an application that manipulates the database, it doesn't make much sense to protect the data from someone who has access to the database.
The main improvement I would make is instead of including the password directly in the email, include a time-limited link that can be used to view the password. This way, a single leak of the user's inbox doesn't provide access to their account on this system.
> The main reason you hash passwords is so that if your database is compromised, it's difficult for an attacker to use that information to authenticate to another system. If your system is just an application that manipulates the database, it doesn't make much sense to protect the data from someone who has access to the database.
The SECOND reason is so that the attacker can't now login as the user and impersonate them.
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.
> 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.
> 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.
> 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]
8 comments
[ 2.5 ms ] story [ 30.5 ms ] threadThe main reason you hash passwords is so that if your database is compromised, it's difficult for an attacker to use that information to authenticate to another system. If your system is just an application that manipulates the database, it doesn't make much sense to protect the data from someone who has access to the database.
The main improvement I would make is instead of including the password directly in the email, include a time-limited link that can be used to view the password. This way, a single leak of the user's inbox doesn't provide access to their account on this system.
The SECOND reason is so that the attacker can't now login as the user and impersonate them.
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.
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.
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.
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
longer explanation "DEF CON 27 IoT Village - Ken Munro - BITFI You Wouldnt Steal My Cloins" https://www.youtube.com/watch?v=W8bTI7QZI3g