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.
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.
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.
They're conflating a lot of things that don't need to be conflated.
You can generate a password for the user locally, when they create an account. You should still be hashing that password, not storing it in plain text. You should still give the user an automated option to generate a new password. You can still avoid sending the password over email, since that's almost guaranteed to be sent unencrypted over an open wire at some point.
The beauty of this Twitter thread is that it starts out with an idea that makes some very mild sense, and then immediately descends into madness for no reason. I absolutely love that they consider a password personally identifying information, but are fine collecting emails because, "the user could use an anonymous one if they wanted to."
I’m not sure what to make of the “infosec” company on the post. Are they trolling as a marketing ploy? Are they ahead of the curve in password management? Is it a philosophical statement on the state of security in the world at large? Do we laugh? Do we cry? Do we shrug? Do we give up in disgust? Are they that incompetent? Rarely have I had so many mixed feelings ;-) This is how I came upon the Twitter thread: https://twitter.com/jeremyphoward/status/1203167252691898368
It all depends on what the user can do now, and what can they do with the future releases. It's an accident waiting to happen. Maybe it will be ok. Every time I ran with scissors I've been ok.
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?
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.
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.
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.
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.
The main weakness I see is that they're still showing the user the generated password. That means the user could reuse that generated password on another site. /s
I expect a followup thread:
"It is for this reason why we neither send you the password, nor ask for it during login."
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.