3 ms·
Every system that relies on passwords also provides a password reset facility. The facility typically sends a token to your email address and allows you to set
by squiggleblaz 6y ago
Every system that relies on passwords also provides a password reset facility. The facility typically sends a token to your email address and allows you to set your password that way.
Doesn't this mean that a system which relies on an token sent to you is no worse that a system with a password? With a password, you can guess that GTP used the same password on Hacker News and BigBank, and if that fails, you can try and have their token redirected to you. Without a password, you have to rely on getting that token. So if your argument is that email and SMS are insecure channels, I mean yeah okay; but it doesn't make a system more secure if you can get in with a password _or_ an email/SMS vs the only option is an email/SMS.
I hate passwords; my password manager (the one built into Firefox) will generate passwords on my desktop, but most of the time I need to generate a password it's on my phone (where, oddly, they have not included the capacity to generate a password). So my password is crap, perhaps not stored, and I forget it. I rely entirely on the password reset facility. But most of the time if you tell me "please just sign up, think of a unique username and a secure password" I'm just not going to bother.
- hnlmorg 6y agoI'm not going to defend passwords, they are a usability nightmare. But I'm yet to see a solution that consistently works better. Regarding your problems, it sounds like you're in need of a better password manager. I personally use LastPass. I'm not saying it's the best out there but I've been using it for a few years and haven't felt the need to jump ship yet. The advantage of having a 3rd party password manage is that it can run on your phone, tablet, laptop and any browsers you want.
- squiggleblaz 6y agoI can run the builtin Firefox password manager on my phone, tablet, laptop and any browsers I want :p It would just be nice if it supported password generation where I need it most.
- hnlmorg 6y agoWhich just emphasises my point that you need a better password manager which does support password generation on every device. LastPass being one such example.
- squiggleblaz 6y agoI meant my first comment in jest. I will consider your advice, but I imagine switching from one password manager to another will only certify me as a genuine and eternal password hater. (Also, a password stored in a password manager is something you have, not something you know, so it's completely inconsistent with the principle of MFA. I mean, the reasons to hate passwords just increase as long as I think about it. That probably only hurts the theory of passwords though, not the practice of them.)
- hnlmorg 6y agoThere is another option if you wish to adhere to the principle of "something I know" and that's to generate a base64 key. eg SITE="www.example.com" SALT="passphrase" printf "${SALT}${SITE}" | shasum -a 512 | base64 | cut -c -25 (Though you're better off using some online tool that converts SHA 512 to base64 directly since the example above converts the ASCII string of a hex representation of the SHA 512 hash into base 64. So use that example above more as a visual representation) This will generate a non-reversible password with an entropy of 25^64 but it is re-creatable on any system that can display a web page and the password is not stored anywhere (so it's firmly "something you know"). If the password becomes compromised then you change your salt and a new unique password will be generated. Thus you only need to memorise a small subset of salts rather than a password per site. This was how I used to do passwords several years ago before I gave into the convenience of password managers.
- squiggleblaz 6y agoYes, I guess that theoretically works. As you say, it's much less convenient than abandoning "something I know" and just going for a password manager. Which I do.
- usrusr 6y agoThe difference is that the password works as a shortcut for situations where the email approach adds lots of friction (working on a "guest" device, latency, the entire world spam countermeasures). Friction is very much acceptable for password recovery (arguably even desirable), but not so much for conventional login. A nice middle ground would be allowing to opt out of passwords, for people who are happy with the combination of device token plus email OTP. This would work even better if device tokens were not binned with all those junk cookies: I think it could be valuable to have a class of "qualified cookies" that can only be written on user prompt and have reads optionally protected by additional local authentication requirements (configured on the user prompt), basically something that sits right in the middle between the streaming heap of cookies a browser stores and the browser's password store that allegedly nobody uses. I believe that this could be a major win for web privacy, "delete all cookies except for those which the store considered important enough to depend on a user prompt" (obviously, the client needs to include a "pretend to store, but actually keep only for the session" option to prevent abuse) You could almost implement this for a site already using the web storage API, except for the unclear client prompts and lack of fine-grained tying into additional client side authentication measures (e.g. like how you might want a password manager to maintain very different master key freshness requirements for different entries)
- squiggleblaz 6y ago> The difference is that the password works as a shortcut for situations where the email approach adds lots of friction (working on a "guest" device, latency, the entire world spam countermeasures). Friction is very much acceptable for password recovery (arguably even desirable), but not so much for conventional login. That's a general response to the question of why passwords might be nicer than email OTP. But it doesn't answer my question - namely, any security problems that might be attributed to email/SMS OTP also exist almost invariably with almost all in-the-wild password implementations, and therefore, isn't email OTP only more secure than password plus an email OTP called "password reset". This question is purely a rebuttal of the claim that passwords are more secure than email/SMS OTP. In the wild, there are a few sites where an email account, and therefore password reset, is optional. Hacker News and Reddit are examples. But these are in the extreme minority, and almost never secure anything worth securing. Bank accounts are another class of exceptions, where they secure something so valuable it is worthwhile going through a human verification process before you can do a password reset. But almost everything else - online stores, newspaper comment columns, much social media, web apps used for work, phone apps that let you monitor your robot vacuum cleaner, email accounts - almost all of them expect you to have an email address and use it for a password reset