
We don't allow users to pick passwords so we don't store your information - Bootvis
https://twitter.com/ppentestlabs/status/1202906268991664128
======
maxdamantus
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.

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

~~~
maxdamantus
> 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
> 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
> 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)

------
rasz
Reminds me of John McAfee "There is no RAM" tweet (while pushing some
cryptocurency scam)
[https://twitter.com/officialmcafee/status/102574361759866060...](https://twitter.com/officialmcafee/status/1025743617598660608)

longer explanation "DEF CON 27 IoT Village - Ken Munro - BITFI You Wouldnt
Steal My Cloins"
[https://www.youtube.com/watch?v=W8bTI7QZI3g](https://www.youtube.com/watch?v=W8bTI7QZI3g)

------
halkcyon
Quite an ironic thread from a security company. "We don't store _your_
password, it's _our_ randomly generated one!"

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

