Those usecases are at least 5 years if not 10 years out. They require software support which won't come until a significant part of the pc market has the necessary hardware for it. Until then, paying extra for the hardware is foolish.
This will only come if Windows 12 requires a TPU and most of the old hardware is decommissioned.
I've seen this happen with both juniors and seniors. They do come back with a working solution /for the happy path/. Because the happy path is easy. It turns out that most of the complexity sits in the unhappy paths.
I still don’t agree. The trick to good design is getting more things on the happy path. Most of the software I use is small and constructed in this manner.
"They only coded the happy path" is software engineer for "they coded it as if nothing would ever go wrong". It is definitely not good design to do that.
There's an engineering trap/fallacy I like to call "how hard could it be". How hard could it be to build a [whatever] clone? If you find yourself thinking that, stop what you're doing, because the answer is almost always "at least an order of magnitude harder than you think."
What I meant is that most commercial software has a large number of code paths. Because it’s built incrementally, not holistically. This creates complexity and cost.
If you’ve only worked on that kind of software it’s hard to know the alternative which is to aggressively prune code paths and rework your main code.
And open source example is Quake. I rarely come across software whose inherent complexity is more than quake.
Yeah, that's not what the person you were replying to is talking about. I was explaining the jargon.
Complexity and LoC has nothing to do with "only coding for the happy path". Both complex and simple software can be written this way.
A great example is the moltbook hilarity. They slapped together something that looked good and did function -- in the happy case only. They put together an "authorization" flow but exposed their entire database because they didn't know how to secure Supabase. They had no rate limiting on account creation -- so one dude created 1M in an hour.
Even putting aside adversarial usage, you have to code for, like, normal stuff going wrong or your app will lose data, crash, leak information, fall over, etc, etc.
The 30 seconds (+30-60 seconds to account for clock drift) are long enough to exploit.
TOTP is primarily a defense against password reuse (3rd party site gets popped and leaks passwords, thanks to TOTP my site isn't overrun by adversaries) and password stuffing attacks.
Note that a prover may send the same OTP inside a given time-step
window multiple times to a verifier. The verifier MUST NOT accept
the second attempt of the OTP after the successful validation has
been issued for the first OTP, which ensures one-time only use of an
OTP.
Assuming your adversary isn't actually directly impersonating you but simply gets the result from the successful attempt a few seconds later, the OTP should be invalid, being a one time password and all.
