Ikea effect. People are more likely to complete the new user funnel if they felt they had a role in building it.
This made me chuckle, and it honestly might be true.
Why even let users set their own passwords?
151–160 of 392 posts
Re: Why even let users set their own passwords?
#152I wonder if “true multi factor” security requires exclusivity between each factor. So, you cannot “know” anything about the “thing you have”. It should be more like a yubikey that you plug into your computer and which is secure enough that you cannot get the information out of it to “know” it. That’s a little harder to do for the “thing you are” factor because we can’t design a system to use a feature we can’t unders…
100%. Storing your "2FA" TOTP tokens in your password manager is asking for trouble, in my opinion. Why put all your bags in one basket? The moment your PC gets owned your are pretty much permanently locked out of all your accounts.
I agree, but I'd point out one thing just in case you're using "PC" in a restrictive sense.
There's no difference between using a big Personal Computer (PC) like a desktop computer, or a small Personal Computer (PC) like a smartphone. Both are something you have.
The problem is not that a bigger computer that never leaves your home is more insecure and that the small computer with a touch screen that actually leaves your home is more secure.
The problem is also not storing TOTP in a password manager. Because a password manager can also be used from a smartphone and a TOTP authenticator can also be used from a desktop computer.
The problem is using the same device ("factor", if we're being fancy) for storing and reading both secrets, because that means if the device is compromised it'll be able to read both types of secrets.
So using a desktop computer for passwords and a smartphone for TOTP, should be just as fine as using a laptop 1 for passwords and a laptop 2 for TOTP.
Re: Why even let users set their own passwords?
#153> Often this will be combined with fallacious notions such as “remember this device”, the idea being you only have to go through all this the first time when logging in from a particular device. This idea is fallacious because the web has no notion of a “device”, and this is a very intentional design choice made for privacy purposes. We are literally living through the gradual phase-out of third-party cookies, amongs…
> My own browser erases all cookies from an origin immediately after the last tab from that origin is closed,
Sounds like a you problem, dude. You have to go out of your way to force this behavior with any mainstream browser.
Re: Why even let users set their own passwords?
#154Honestly, unless you're a major cloud/OS provider like Google/FB/MS/Apple, you shouldn't be managing passwords at all. Let the pros do that. You just use an authentication standard via a 3rd party. If you aren't big enough to maintain your own operating system and web browser, you shouldn't be storing passwords.
I agree social SSO is the gold standard in terms of UX, but it's also a privacy disaster. What we really need is for someone to make a Let's Encrypt for login. A nonprofit that provides SSO in a privacy respecting manner.
Re: Why even let users set their own passwords?
#155Earlier quoted context omitted.
Are you aware that iOS supports PWAs, and recently implemented notifications for them?
Only 8 years late: https://developer.chrome.com/blog/push-notifications-on-the-... Besides - there are plenty of other things Apple can do to ensure PWA's don't take off. For example, there is no ability for a web-app to have a "click here to install to desktop" button - the website must try to guide the user into clicking the share button and then creating a desktop icon - which most users don't associate with 'inst…
Fascinating how to keep moving the goalposts.
Firefox refuses to implement pwa. Chrome has pwas but they're not isolated.
Apple is the only one with sane pwa but somehow they're the worst and are totally sabotaging PWAs because something something walled garden?
Re: Why even let users set their own passwords?
#156Earlier quoted context omitted.
I kinda wish there was something like cookies, but even more persistent. Lets call them permacookies. I want to "remember my device", and have that keep me logged in forever with a permacookie. I don't even want to have a username and password. I want to create an account and be forever logged in. There would be mechanisms to backup my permacookies, or transfer them to other devices. I'd have control of which sites c…
What you're looking for is client certificates. This has existed for years but webby people think users are too stupid to use them, so we get the menagerie of half baked trash we have now instead.
Client cert handing at the load balancer level and reverse proxy level are stupid hard to get right.
I would burn client certs to the ground if I could.
Re: Why even let users set their own passwords?
#157There is an overwhelming amount of superfluous text in this article. The author's solution: > Rather than allowing a user to set their own password, passwords can be issued in exactly the same way as API keys are now: a high-entropy password is randomly generated by the issuing website, and the user is shown the password once only and asked to record it. If the password is lost, a new password must be generated using…
This is basically what passkeys are, right? Except the autogenerated password isn't even shown to the user, just stored immediately in the user’s password manager. (I recognize that it’s a bit more involved, eg if i get it right, passkeys add some public key encryption to the mix to avoid sending the “password” over the wire needlessly often etc, but those are just icing on the cake as far as I’m concerned)
There isn’t encryption nor a generated password involved with passkeys. Rather, your device generates a private key and stores it in your password manager - and only the public key is sent to the server.
When you log in later, the server uses an API to give your client a random unique challenge (just some bytes), you unlock and approve and the pwm signs some stuff including the challenge and sends the signature back. The server verifies with the public key, and is satisfied because only your private key could’ve generated that signature.
But you are exactly right - this is detail and the UX is essentially the same as having the pwm generate random passwords that you never get to see or copy.
Re: Why even let users set their own passwords?
#158Earlier quoted context omitted.
A randomly generated pass-phrase can be both secure and easy to remember/write down.
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.
Re: Why even let users set their own passwords?
#159[deleted]
Re: Why even let users set their own passwords?
#160We probably will stop one day, but that day isn't yet for many services. There are people who would be unable to use those services if that can't set the password to either the same or a variant of one they always use. In the tech wold we often forget that there is a wide disparity in people's ability to use tech. Take my father, there is no way he could use a password manager, or two factor, it's just never going to…
[flagged]
> There's a cost to society to carrying over such a technological deadweight loss and these people are free riders.
The same capitalistic analysis can be said for fetuses, infants, and children up to working age.
Is your proposal for infanticide the same as your gerontocide?