905
These F-ing Logins Nowadays (lemmy.today)
submitted 1 day ago by to c/programmer_humor@programming.dev
218 comments fedilink hide all child comments
 
you are viewing a single comment's thread
view the rest of the comments
[–] 60 points 23 hours ago* (8 children)

Except when it's just an email, or worse, a txt message, or worse, a whatsapp message, with no other option for using a proper 2fa generator...

But also, not every site needs 2fa, sometimes I really couldn't care less if someone managed to hack into something, because I can just make a new account if that happened...

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 8 child comments
    •
  • [–] 36 points 22 hours ago (6 children)

    What really bugs me is that TOTP is objectively easier than any other form of 2fa. Just import the library, add the field on your login form, and you're done.

    • Email verification is annoying to code, it requires SMTP or an email gateway, is slow for the user, is risky from a security perspective, and to generate the code you probably still have to implement TOTP.
    • SMS/RCS is even more annoying to code, it almost inevitably requires a third-party gateway, it can work differently if the user is in a different country or on a MVNO or in a low-signal area or just has the wrong astrological sign, is very slow for the end user, is almost useless from a security perspective, and you STILL have to implement TOTP.
    • WhatsApp messages are somehow even more annoying to code than that, requires an api interaction with Meta (which is never fun and poorly documented), requires the end user to have an account with a specific third party, is slow for the end user, relies on another company's security posture to determine your own, and you STILL have to implement TOTP.
    • Making your own app for 2fa is undoubtedly the worst: not only is it annoying to code, it's an ongoing annoyance that is strained through multiple app stores, adds an additional maintenance and support load, adds additional technical debt, adds an unnecessary attack vector, requires users to download another app, is often unreliable, is often pretty slow for the end user, is a total crapshoot from a security perspective, and guess what? YOU PROBABLY STILL HAVE TO IMPLEMENT TOTP.

    Any company that chooses SMS or email verification over TOTP emphatically does not know what they're doing.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 6 child comments
    •
  • [–] 4 points 21 hours ago (2 children)

    You don't have to implement totp for these alternatives... The "thing" about totp is that there's a shared secret and a timestamp. Due to potential drift in clocks you need a window and period to know how many time steps to test, and how long each is.

    But with an email/SMS/WhatsApp, there's no shared secret. So you can simply send a random code, and store server side when it was generated. Totp makes no sense in that case.

    Not that totp is difficult to implement at all. My implementation for work was what, less than 200 lines of C++ I think? I didn't implement the sha1 myself though.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 2 points 20 hours ago

    An earlier version of that comment said "something like TOTP," but I guess I left that out while I was revising it. My point is you have to implement something that does most of what TOTP does anyway, so why not just use the version that's already been stress tested?

  • permalink
  • fedilink
  • source
  • parent
  • [–] 1 point 8 hours ago

    You do have to implement TOTP, just not necessarily RFC 6238. Time-based one-time passwords require a shared secret, a shared time and a time-to-live. The shared secret is usually the key for generating the code, but can be the code itself. The shared time is still needed in mail authentication between the code generator and the code validator. The thing that's usually different is the time to live, but in RFC 6238 it is a parameter, so you can implement mail verification with it and a long TTL.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 3 points 15 hours ago

    The real reason is conversion. The majority of users aren't good at technology, so you risk them losing their TOTP secret. Then the user either just says "screw this site" and leaves, or they take time getting customer support to reset their key.

    So depending on the branch and customer base, it can often be much "cheaper" in the end to send login codes via email instead of using TOTP.

  • permalink
  • fedilink
  • source
  • parent