
We don't allow users to pick password. We generate it and store it in plaintext - vo2maxer
https://twitter.com/ppentestlabs/status/1202906268991664128
======
londons_explore
While this post might be trolling, I don't actually see many issues with this
scheme.

The weaknesses are that a password, once leaked, can't be changed. And sending
it over email pretty much constitutes a leak.

But on balance, password reuse is such a large problem that I suspect this
scheme will end up with fewer account compromises per year than a service
using regular password hashing without 2fa.

~~~
mindslight
What most sites call a "password" is really just a cached email challenge.
Tweak this so it generates a new token on every challenge, and it's actually
pretty slick. If the service is compromised such that the userdb is copied,
they can just wipe the whole cache.

The biggest sin here is inventing a new method, requiring actual analysis of
its properties. The indignation from the cargo cult is a bonus though. Most of
the upset is probably from people being prevented from setting their password
to the same one they use on every other site.

~~~
danShumway
Medium already got rid of passwords and uses email tokens for all logins. It's
really annoying as an end user, but it does work. Assuming they're not a
troll, I think their sin is trying to reinvent a method that already existed,
and reinventing it poorly.

------
imtringued
Sending the password over email still doesn't make any sense. It should still
work like every other password reset scheme. You click on a verification link
sent over email and then you can enter a new password on a https secured site
(or it will be randomly generated).

Whether the password is generated or user created doesn't matter. All the old
password handling rules still apply. Don't store passwords in plain text.
Don't send them over insecure channels. Always offer an option to reset
passwords instead of showing the stored password to the user.

The explanation against securing the passwords in the database is also
completely illogical.

>If a hacker was able to get into the system then that would mean he might
have other things to look at then decrypt or recover a string that we
generated when you signed up

If I were a hacker and I could covertly just dump your user/password table
then I wouldn't even bother writing a single update query. I would just sell
the accounts for $10 each. It would be very difficult to notice the data
breach. Who is going to reset e.g. 10 million user passwords just because
10000 were compromised without any evidence that it wasn't user error?

~~~
j-pb
So you put the accounts up for sale, and then what?

Who would buy access to somebody elses infosec homework. Because that's what
this site is.

They're essentially playing a low stakes game with low effort.

And I give them big KUDOS for that, cause the average web dev joe would follow
all the "best pratices" store user passwords and billing info, hashed, salted,
cursed, put in stakes that were never needed & get hacked.

------
danShumway
I was three tweets in before I realized what their username was.

I don't care if these tweets are real or just someone trolling. This is true
art.

~~~
byoung2
Definitely trolling, but there is someone out there reading this and saying
"hmmm, this makes sense"

~~~
j-pb
Is it tho? Show me the attack vector that makes this model dangerous. Not
inconvenient because somebody else messed with your highscore or marked some
of their tutorial videos as watched. But "oof I have to call my bank", "I have
to tell people that wasn't me", "let me make a photocopy of my id so that I
can proof its me" dangerous.

~~~
danShumway
The only reason it's less dangerous is their service isn't protecting or
offering anything of value.

If they had no password at all, and anyone could log into anyone's account
with just a username, you could still make the claim that their threat model
was only, "that's inconvenient, someone messed with my account." Heck, if
every third time you tried to log in, you were automatically logged in under
another person's account, you could still make the argument that their threat
model was low.

But that wouldn't mean their security policy was good.

Their decision not to store much data has nothing to do with the terrible way
they are storing and managing the data that they do collect. They're arguing
that hashing passwords would require them to store more sensitive information.
That's like arguing, "I can't lock my door, because then I would need to put
more valuables in my house." The two decisions aren't related.

~~~
j-pb
Yeah exactly, but for this particular usecase the "token based login" seems to
be the best tradeoff between complexity and requirements.

They seem to have put the effort elsewhere, e.g. keeping their system devoid
of billing and credit card info. Something a lot of shops that salt and do
multi round scrypt hashing probably don't, because even though they do follow
best practices, they don't actually think about security.

Would I have built it with hashing and automatic keygen on reset? sure! But
this thing seems good enough tm.

Security isn't something where one solution fits all, otherwise everything
thats low stakes like this (homework, guitar notes collection, my dogs
homepage) gets the same security best practices as the hight stakes stuff
(medical, financial, social).

I'd rather have this hacked together in php, but my bank run idris code, and
my kitchen robot run haskell, than everything using node with scrypt hashed
JWT.

------
nootropicat
Clever marketing.

------
jeffrallen
Seems legit.

