905
These F-ing Logins Nowadays (lemmy.today)
submitted 1 day ago by to c/programmer_humor@programming.dev
217 comments fedilink hide all child comments
 
you are viewing a single comment's thread
view the rest of the 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