I appreciate that there is at least one other person on earth who shares my skepticism of many popular MFA implementations. A lot of them add more inconvenience than security. "We sent a code to your email" is particularly heinous.
Other than the chance the email is delayed, and the generally subpar UX, what are your concerns with emailed codes? This is an honest question, as this is the primary login method I settled on for all my services after spending a good chunk of time thinking about this.
Why even let users set their own passwords?
351–360 of 392 posts
Re: Why even let users set their own passwords?
#352Here's why: the world is not able bodied Americans, so let us decide what password is best for us through our input methods
Re: Why even let users set their own passwords?
#353If you know what the user's password is, then you could potentially be liable for an improper access. This liability is is impossible if you have no way of knowing what that password might be, even if things you do know like 2FA codes are used with something only the user would know.
Re: Why even let users set their own passwords?
#354Earlier quoted context omitted.
Nobody gets to decide what's more or less sensitive. Younger generations can argue being rendered homeless due to mass housing affordability issues is also insensitive.
Calling such people “technological deadweight” and “free riders” is the insensitive thing, regardless of the veracity.
Yet akin to the article, because of the overly sensitive, everyone's expressive creativity must be dulled down. Who's the intolerant one?
Reminds me of this classic https://medium.com/incerto/the-most-intolerant-wins-the-dict...
Re: Why even let users set their own passwords?
#355Earlier quoted context omitted.
This is circling around Native File Access, which is absolutely something the web needs and if handled correctly would be a huge improvement for user privacy and user autonomy. It would open the door for fully offline webapps with no accounts or serverside components, with much better sandboxing than native apps, and with full user control over app data using just a file browser. And it would allow for app data that…
Is that what I'm talking about though? We are talking about tablet phone and laptop sharing a data store. Not multiple user agents on the same device sharing a data store. Though we have entered the era where the names of specs or initiatives have little to nothing to do with the actual meat of the thing.
Maybe you're right though and the UI would need to be different :shrug:
Re: Why even let users set their own passwords?
#356Earlier quoted context omitted.
That might be a very misleading statistic. What if more than 0.2% of people wanted to disable JavaScript, but in the end surrended to the fact that those pesky web devs never test their creations with JS disabled? I know I am one of those who would like to disable JS, but it's just not practical. So stats really are a dangerous tool, they sometimes can end up telling you just what you want to hear...
If anyone tests their web pages without JS, it would be gov.uk. I'm an American but I frequently reference their guidelines on accessibility and similar because they're so thorough and conscientious about it.
Re: Why even let users set their own passwords?
#357Nowadays, websites and apps force users to follow a certain pattern when setting their password. Since users have to comply in order to successfully proceede with setting their password, does it still count? (Count as in letting users set their own password)
Re: Why even let users set their own passwords?
#358Earlier quoted context omitted.
That might be a very misleading statistic. What if more than 0.2% of people wanted to disable JavaScript, but in the end surrended to the fact that those pesky web devs never test their creations with JS disabled? I know I am one of those who would like to disable JS, but it's just not practical. So stats really are a dangerous tool, they sometimes can end up telling you just what you want to hear...
> people...who would like to disable JS, but it's just not practical As I tell my kid when he "wants" something, I want a pony, and a million dollars. I don't see why the fact that some people might like that matters. I mean, given the choice for free sure I'd "like" it too. But it will never remotely be worth it to build two entirely separate web applications for every website to make that dream a reality, nor do I…
Some applications of the newer technologies merit their use.
Most use cases, however, don't.
Bad practices abound, the "art" of programming becomes a chore made by let's say not very skilled people. Luckily there are still lots of good managers and good devs that value adequately done products, but on average that's not the case and the Web gets more and more bloated as a whole.
One day you decide to disable JavaScript in your phone (which BTW is an incredible way to speed up modern webshit, as the sibling comment puts it, in under-powered mobile devices), and turns out that lots of f*ing blogs don't load their plain text and static pictures if JS is not enabled. That's an absurd situation we've collectively ended up in.
The mere thought of having a Word document with just text, images, and a couple tables, and not being able to open it if VB macros were disabled, sounds absurd. But that's exactly what large parts of the Web have become.
Re: Why even let users set their own passwords?
#359I appreciate that there is at least one other person on earth who shares my skepticism of many popular MFA implementations. A lot of them add more inconvenience than security. "We sent a code to your email" is particularly heinous.
Other than the chance the email is delayed, and the generally subpar UX, what are your concerns with emailed codes? This is an honest question, as this is the primary login method I settled on for all my services after spending a good chunk of time thinking about this.
Sure, you could say:
P[password X is compromised] * P[password Y is compromised]
...and thus you have increased the security of the account. By the same math, I say that you've barely moved the needle.If your password recovery flow only requires the user to enter their email, then you've done nothing to raise the security of the account. At that point, the only important password is the one for the email associated with the account- the password for your login system, and all others like it, can be considered mutable and temporary.
If you have "we sent you a code" MFA and email-based password recovery, you have probably de-incentivised hacking of your service. But, the approach also puts a target on the email service provider's back.
Re: Why even let users set their own passwords?
#360Earlier quoted context omitted.
It can, but it's very unlikely. Most randomly generated data doesn't have a memorable structure.
Please pay attention to the use of pass-PHRASE. Pass-phrases are well understood at this point as far as what they are and how to generate them securely. A key point is that they’re much longer so have plenty of entropy to resist cracking attempts.