8 ms·

I hate email-based authorization. It is an extra step and requires access to a working email. Sure 95% of the time I get that email in a second and then it is o

• human 5y ago
  I also hate password emails. I use a password manager and find it much more efficient. However, I can see how this solution is interesting for small projects where users might create an account once and forget about it. I wouldn’t want that setup for a site I use often, and especially not for a site where I have multiple accounts (Twitter for example).
• slapslash 5y ago
  "Honestly I'm excited that we are getting 2FA pretty mainstream" Doesn't that have those extra steps included as well that you critizised on email-based auth?
  • scim-knox-twox 5y ago
    No, password managers can take care of that.
    • umeshunni 5y ago
      Can password managers deliver OTPs or other 2FAs?
      • unilynx 5y ago
        1Password can do TOTP
        • skyeto 5y ago
          Though it defeats the point of TOTP to some extent.
          • jackweirdy 5y ago
            It still proves you’re giving the password right this moment, and that it hasn’t been popped from a DB. On the other hand it doesn’t prove that someone has stolen your phone/laptop, defeated all of its own security, and then defeated the security of the password manager. For my personal risk propensity, the former is worth having, the latter is too unlikely to worry about
          • scim-knox-twox 5y ago
            No, it just depends on your case.
          • forty 5y ago
            (I work for a company that makes a password manager that have this feature too) I used to think that but I changed my mind. First, you can set TOTP (or other second factors) authentication on your password manager account, which I think is good philosophically at least, because you gotta have access to your second factor to get access to you website TOTP. Secondly, using a password manager with strong unique passwords that you don't know brings already a lot of benefits that pushes websites and administrator to push using a second factor (it's very often a way to avoid attacks using reused or bad passwords). You do lose a bit of security (there is now a risk that your TOTP seed get stollen), but the extra convenience (especially when you lose your TOTP device) means you can enable it on more websites without too much annoyances.
• frozenice 5y ago
  > I hate email-based authorization. Authentication, not authorization. ;)
• stevage 5y ago
  Everything you hate about email login is what I hate about 2FA, as a user.
  • headass 5y ago
    i mean it’s not much different it’s just email code/link vs an all generating a code but 2fa is unphishable as well
    • yonixw 5y ago
      2fa totp\sms is phishable, 2fa FIDO is unphishable
  • IYasha 5y ago
    Absolutely. I'd happily use password-only services. Because I'm willing to take responsibility of losing my own password. I hate it when someone forces me to use 3rd party services, usually not very secure, when it's not really required by logic.
  • danjac 5y ago
    I'm happy to jump through 2FA hoops for my banking app. I'm not so enthusiastic to do the same for every news or social media site.
• pharmakom 5y ago
  How do you sync your password manager state? This is not easy for a typical user to setup, whereas their email is probably already syncing across all of their devices.
  • black_knight 5y ago
    Really? For me, password sync just works in my browser without any adding or anything. Just had to log in once when I got each device. I use Firefox, but I would be surprised if it was more difficult on other browsers.
  • rad_gruchalski 5y ago
    Bitwarden.
  • kevincox 5y ago
    I believe all modern browsers have buikt-in easy-to-use passwords managers with nukti-device synchronization.
  • jon-wood 5y ago
    I use 1Password, so it just happens when I sign into my account on a new device. The same is true of the built in password managers from Apple, Google, and Microsoft.
• tialaramex 5y ago
  Your "Browsers and PAKE" suggestion requires everybody gets new browsers with this special feature and every web site upgrades to rely on that feature for user authentication. So that's a Big Bang change and thus not at all practical for the Internet. The Internet's last successful Big Bang change was 1 January 1983, almost 40 years ago. We can get where we want to go, without passwords, incrementally with WebAuthn.
  • kevincox 5y ago
    People need to update their browsers regularly for security updates anyways. And I didn't say anything about a big-bang change. It would obviously be a new API that slowly becomes the default choice. Maybe <input type=password-pake algo=opaque> rather than type=password. When I day the future I mean years down the road. Not next week.
    • tialaramex 5y ago
      > Maybe <input type=password-pake algo=opaque> rather than type=password. That's not how OPAQUE (or similar things) works. You cannot, in fact, just drop this in and "slowly" change. You need an enrolment step where the server does not learn the password (but does end up able to ascertain whether the client knows the password), and from then on all clients must not reveal the password to the server. The sign-in process now needs a phase where the client has identified itself in order to receive parameters it will need to deliver live proof of having the credentials, so that means re-designing many single-step sign-in processes (e.g. username and password on same form) And all the hard work is destroyed the moment either the user types their password in to a conventional web form, anywhere, or the server ends up actually storing passwords and not OPAQUE's "envelope" data, both of which are almost certain to occur if you try to introduce this "slowly".
      • kevincox 5y ago
        You are assuming a lot about the implementation that I didn't specify. I'm also not saying that I have fully designed the API for this, just giving a very rough idea of what it could look like. > You need an enrolment step where the server does not learn the password Of course, there would be something similar to new-password that can be used on password set and change forms that would do the enrollment dance. > The sign-in process now needs a phase where the client has identified itself in order to receive parameters it will need to deliver live proof of having the credentials, so that means re-designing many single-step sign-in processes (e.g. username and password on same form) IIUC the browser could get the user id and password in one step then do the back-and-forth with the server afterwards. > both of which are almost certain to occur if you try to introduce this "slowly". I don't see why this is certain to happen. For passwords that use OPAQUE the password manager would set a flag that prevents it from being filled into any field that is accessible to the website. In practice this means that it would refuse to fill in any input that isn't `type=password-pake` and the value of that input wouldn't be accessible to the site. For the user to work around this they would need to copy-paste or retype the password themselves. It won't stop everyone but there is lots of room for good UX warnings. But again, I'm not claiming that I have designed the perfect protocol, but I think passwords have value because they can easily be typed, written down and re-imported by users whereas most key systems make this very difficult (although maybe shorter keys and more efficient encodings can mitigate this). The ability to pick your own password is also valuable for the few passwords that you do need to memorize. My point is that I think that there are significant upsides to passwords and most of the downsides can be worked around such that users would barely notice the difference.
• lelanthran 5y ago
  I think you're ignoring the fact that people like to access their accounts from different devices. Using a password manager means you either only use a single device for all your internet, or you deal with the synchronisation problem yourself. Both of those are a worse UX than either using a password (with constraints enforced by the site) or email-based auth. > 1. The browser will generate all your passwords. The UX to pick your own password will be awkward. So, not only will the user be locked into a single device, they'll be locked into a single browser on that device? That's hardly an improvement, is it?
  • kevincox 5y ago
    All popular password managers and browsers have built in sync features. I don't see multi device as a problem with passwords. And don't people need to sync their email? How is that any different? > they'll be locked into a single browser on that device? I don't know where you saw this conclusion from. Their are multi-browser password managers and you can always copy+paste.
    • lelanthran 5y ago
      > And don't people need to sync their email? How is that any different? It's different because it is already done. I don't know of anyone who hasn't already set up their email on all their devices. Literally, not a single person I know that has a desktop, laptop, tablet and/or phone or any combination of the above that hasn't already got their email on their devices working. Maybe you use a computing device that doesn't already receive your email, but you're in a minority.
  • Timshel 5y ago
    Note when using multiple devices in the case of the email-based auth if the code is not simple enough then you end up with having to setup email sync on all devices ... And even if simple enough it relies a lot on cookies to avoid the hassle of the flow and become absolute crap when using private session or a cookie cleaner. For the "personal project where security isn’t critical" use-case half the time the site would be better without authentication and the other half I'll probably use my default crapshot password because it's not worth more effort. Edit: on the dev part it's not even simpler than a password solution since in the example the token is stored server-side and you still need to send emails. If you don't care about session invalidation then you could just rely on the token with a bit of encryption/hashing. Another edit: you could probably just add an optional password field to the flow and obtain something more flexible for the user without adding much complexity. -> When creating an account not much diff -> When logging if you have the correct password then great otherwise send the token -> When entering the token add optional password to update
• raverbashing 5y ago
  > or prefer to use their dog's name as their password on every site. It really sucks that a great workflow is being punished just because some users are irresponsible. Actually I'm more in favour of using a "throwaway" password in the sites I care less. Exactly because I don't know if they store this on plaintext or weakly hashed. Sure, it's still a secret, but it's something that's not hard to remember if needed (or even type on mobile, because if you think I'm generating something like a random string of characters for any website that wants me to login you're mistaken) Password managers are great but I don't have it (or want it) installed in every device.
• nickjj 5y ago
  Most sites will require you to confirm your account before being able to do anything which involves receiving an email and clicking a link which is the same workflow as a passwordless system. I don't really see a magic link system as being worse in this regard, especially if you use cookies to persist the login. The user experience is the same except for cases where you want them to login again without a cookie, I'd make a case that using a passwordless system here is better because each time you login you are verifying that you still own the email address -- this isn't bad if it only needs to be done a few times per year. For a lot of sites it's reasonable to keep a user logged in for months at a time or even permanently.
  • Tagbert 5y ago
    Using email to verify the account is a one time operation and if it takes a long time to get the email, that can be endured. Having to depend on email for authentication each time is unworkable. Frequently the email never arrives or takes a long time to arrive. I would much prefer to use the passwords that I keep in a password manager and can do an immediate login without depending on email’s duct tape and bailing wire approach.
    • nickjj 5y ago
      It could be a near 1 time operation with magic links too. The cookie can be saved for 6 months, a year or even 20 years on your device.
• rmbyrro 5y ago
  I'm just a little worried about everyone having all their passwords in a single basket like 1password. It just doesn't seem a smart thing to do. There are certainly dozens of ways to hack 1password that they don't know yet. What happens when someone decides to exploit one of these?
  • forty 5y ago
    (I work for a 1password competitor, my answer is pretty generic) Serious password managers (like 1password) encrypt data client side, with a secret not known to them. If the master password is good enough and the cryptographic part well done (for example with a hard enough password derivation function) passwords are probably relatively safe even if the servers of the password manager were to be hacked. Now you could argue that a malware could be injected in the client side code and steal your password this way. The bad news is that any software you use probably have broad access to your computer, and could probably steal your passwords in a way or another. So yes there is a risk to using a password manager, but it's not terribly different from the risk of using any software. Maybe there are some passwords you never input on a given computer, and having them in "the same basket" as the others would be a problem. In that case you'd probably want to use a separate password manager account for those passwords. On the other hand, not using a password manager means you either use the same password everywhere (or some derivative of the same), or use weak enough passwords that you can remember them all. It also means you input your passwords yourself, meaning that you could easily get phished, which is a pretty common problem these days, etc etc. So not using a password manager is itself a risk (and in my biased opinion, a much bigger risk than getting your passwords stollen from a PM vault)
    • rmbyrro 5y ago
      I'm sure you guys have pretty high security standards, I just think the incentive to break you is too high (and I'd bet anything there are at least a dozen ways to break your security). The incentive to break my personal security perimeter is quite low. That being said, I do reuse my passwords. The strategy is having 5-6 different levels of pass, depending on the service. Level 1 is the highest security. I only use in very few services, usually financial-related. Level 5 or 6 are the lowest, I use loosely on services that I don't trust and don't hold too sensitive information. EDIT: another side of this strategy is also having levels of email addresses. So the address I use in level 5-6 services is not the same I use in Level 1, and certainly not my public email address. For lower levels of security, I use browser "remember pass" feature to offload my memory.