Live data from Hacker News

Why even let users set their own passwords?

devever.net

351–360 of 392 posts

Re: Why even let users set their own passwords?

#351

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.

The first two reasons are enough to disqualify it

Re: Why even let users set their own passwords?

#353

If 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.

You don't know, you just generate it

Re: Why even let users set their own passwords?

#354
post #34

Earlier 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.

That's your opinion. As a New Yorker my personal opinion is that people are, if anything, too sensitive in interpersonal communication.

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?

#355

Earlier 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.

I don't know, I use filesystem sync for all of that. All that really means is that on iOS/iPad you'd have a file portal sitting in front of your browser. And on Android, it's already filesystems anyway.

Maybe you're right though and the UI would need to be different :shrug:

Re: Why even let users set their own passwords?

#356
post #329

Earlier 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.

Yeah but I am afraid every other website on the Internet is not done with the care and good craftsmanship that the gov.uk applies to its website. I wish, though! But then so many web devs (and so many of their managers, too!) would be lost without knowing what to do without a JS framework that weights several MBs worth of bloat...

Re: Why even let users set their own passwords?

#357
I am thinking loudly now.

Nowadays, 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?

#358
post #335
post #329

Earlier 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…

Look. I agree with you, in the core idea. There have really been advances in technology, but for each step made with brilliance and prowess, there have been 3 steps back with laziness and carelessness.

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?

#359

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.

If the assumption is that users set bad passwords, hence the need for MFA, then why should the MFA implementation assume their email account is any less compromised than the account we're trying to protect?

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?

#360
post #158

Earlier 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.

Sadly you still have many sites that have stupid password rules like requiring numbers and "special characters" -- but no spaces, and no, periods don't count as special characters, and blah blah blah. Point being, the ideal of a simple phrase that's easy to remember gets thrown out the window when you have to deal with all the different rules.
Post reply on HN