I'll ask, in the corporate world. Why even allow them to know their password. To login to their device a Yubi Key or Door key could be used (or similar) then once logged into their laptop they have an app the works like 1password or lastpass that inserts their passwords, updates their passowrds etc. for everything the company uses. (If they have a reddit account that is non corporate they could use their own pw manager.) This would also solve the "shared password" issue where a company that has a corporate Twitter account, they control access to the credentials and the credentials. Also gives you a paper trail in that you now know who used the credentials at the time of a post.
Why even let users set their own passwords?
321–330 of 392 posts
Re: Why even let users set their own passwords?
#322I'll ask, in the corporate world. Why even allow them to know their password. To login to their device a Yubi Key or Door key could be used (or similar) then once logged into their laptop they have an app the works like 1password or lastpass that inserts their passwords, updates their passowrds etc. for everything the company uses. (If they have a reddit account that is non corporate they could use their own pw manag…
What happens when that key is stolen or lost? Would it be acceptable risk in your model to allow anyone to use it?
I'm not saying you're wrong, but it would be a definitive trade off.
Re: Why even let users set their own passwords?
#323Earlier quoted context omitted.
Thank you for teaching me the word hair-shirt. These kind of blog posts come up often on HN and it's good to have a word to describe them.
Imagine if these people made posts like "I edited user32.dll to dummy out random functions I deem unnecessary like RegisterClass or CreateWindowEx and now nothing works! This is proof that Windows is broken!" It will forever be a mystery for me why people deliberately make their browsers work in ways that contradict the standards the web is built on and then manage to find blame in others when stuff doesn't work. It'…
or the entitled "I've disabled Javascript, all web developers should make their site work without JS" when even in 2013 only 0.2% of all users to gov.uk had JS disabled*
https://gds.blog.gov.uk/2013/10/21/how-many-people-are-missi...
Re: Why even let users set their own passwords?
#324Earlier quoted context omitted.
This is what HTTP auth headers are for, but the UX for using header authentication on modern browsers is utter garbage. There's no way to present a themed login form, no way to log the user out at all , and all sorts of weird papercut bugs[0] in between. [0] My favorite: opening DevTools triggers a second credential prompt because the DevTools session wants to download some mapfiles or something. No infrastructure ex…
I wish there was better browser support for this but I still use it for pet projects. Last year I wrote about why I’m still using HTTP Basic Auth. https://joeldare.com/why-im-using-http-basic-auth-in-2022
There was a time that I can remember practically every site that needed a login using basic auth, before people switched to textboxes.
Re: Why even let users set their own passwords?
#325Earlier quoted context omitted.
Some games are zero sum and some aren't. Everyone is more secure if a large bank replaces 2FA over unencrypted SMS, even though some may be inconvenienced. Leveling down on everyone's security in exchange for usability for a segment of the population is not a realistic long-term strategy.
As opposed to encrypted SMS? I'm genuinely intrigued at the idea that's a thing. As for the rest, is there any actual evidence of widespread interception of SMS 2fa actually being a problem?
Not sure if you're arguing that it's a great idea to run 2FA over SMS or if you're just acting up
Re: Why even let users set their own passwords?
#326Usernames and passwords are effectively obsolete in China.
It's a combo of:
* All accounts need to be tied to an identity, generally in the form of a Mainland Chinese phone number which is linked in the backend to a Government ID/Foreign Passport
* Mobile first development where mobile is assumed to be the primary or only way to interact with most services.
* Overwhelming dominance of two 3rd party identity providers (WeChat and Alipay)
* WeChat mini-apps taking over most of the small use cases where authentication is baked in.
The usual flow is that you sign up with a phone number as your username and authenticate with SMS 2FA. Because it's a mobile app, it doesn't have to deal with web bullshit and actually remembers you across sessions spanning months. To reauthenticate on a different device, you just enter your phone number and use the same SMS 2FA to login.
The web flow for a lot of sites is that they require you to open the logged in mobile app and scan a QR code to login on the web.
A few legacy sites like Taobao still support password login but they're by far not the majority.
Re: Why even let users set their own passwords?
#327Earlier quoted context omitted.
This isn't just the limit for css/js... It's the limit for user data too. Ie. if you share some videos with a PWA app, then all the videos have to fit inside 50MB unless you want to fetch them from a server each time you play them. Or consider a PWA music player - 50MB of music is all you can play offline. Or a photo editor - 50MB is the limit for all your saved files unless you want to save them to a cloud server.
> Or consider a PWA music player - 50MB of music is all you can play offline. > Or a photo editor - 50MB is the limit for all your saved files unless you want to save them to a cloud server. Why should either of these be saving files in an app-specific private datastore? Music, photos, videos, etc. should be in the standard system locations. The app's data storage should be solely used for settings, cache, and other…
Because you might not have unrestricted rights to the files. The Netflix app allows me to download movies to watch offline but they're DRMed and rented to me by Netflix, not owned by me. A Netflix PWA would not allow for such feature.
Re: Why even let users set their own passwords?
#328The author has enough knowledge to be dangerous and shouldn't be allowed anywhere near an authentication system.
The first diatribe against 'nondeterminstic' logins demonstrates a naivety to both account takeover and botting mitigations.
Passwords have to be assumed to be low entropy long lived credentials which are horrible from nearly every standpoint.
API keys at least have a high entropy but are long lived and difficult to secure. (How many times do we need to see apikeys accidently leaked in a pull request?). They also do nothing from a phishing perspective.
OTP is a high entropy and the authenticated credential exchanged has a very short lifetime. The exchanged credential may also be much shorter. It is still susceptible to phishing mitm attacks.
Thankfully it's 2023 and webauthn is here for the browser. We can keep long lived secrets in a secured environment, be resistant to phishing and if the risk model includes physical loss of device utilize pins / passwords even if they are low entropy.
Re: Why even let users set their own passwords?
#329Earlier quoted context omitted.
Imagine if these people made posts like "I edited user32.dll to dummy out random functions I deem unnecessary like RegisterClass or CreateWindowEx and now nothing works! This is proof that Windows is broken!" It will forever be a mystery for me why people deliberately make their browsers work in ways that contradict the standards the web is built on and then manage to find blame in others when stuff doesn't work. It'…
or the entitled "I've disabled Javascript, all web developers should make their site work without JS" when even in 2013 only 0.2% of all users to gov.uk had JS disabled* https://gds.blog.gov.uk/2013/10/21/how-many-people-are-missi...
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...
Re: Why even let users set their own passwords?
#330Earlier quoted context omitted.
or the entitled "I've disabled Javascript, all web developers should make their site work without JS" when even in 2013 only 0.2% of all users to gov.uk had JS disabled* https://gds.blog.gov.uk/2013/10/21/how-many-people-are-missi...
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.