dogacel

I think the title should change as

"AI models hallucinate less than AI company executives"

I recently discovered them, it is pretty cool. I really wish we could use it for our business workflows.

Also check https://conductor-oss.org/

What is the expected cost of running those tests? I think it would be a good argument to compare this to running cost of unit / integration tests for a function (based on action runners).

If it is so expensive, it can be distributed as a simple GitHub integration / action that runs perodically, what do you think?

Also see, https://dl.acm.org/doi/abs/10.1145/3663529.3664458

> A counter that can be synchronized on demand is kinda superfluous --- not really secret and not terribly relevant either. All else being equal, an attacker can sync up just as easily as a legitimate client so why bother with the counter?

A unique counter for each authorization attempt ensures the resulting key is different for each attempt, which makes replay attacks not possible. I agree if you sync the counter two ways, it is better to use a "nonce", a totally random secret each time.

Why counter is the shared secret? In TOTP time is the counter and it is obviously not secret, so there is no reason to think the counter would be secret as well. Clients can sync their counter to match the server.

Some banks in Switzerland give customers a device that generates TOTP codes.

No, RSA is asymetric, where it has a public/private key pair.

HMAC is symetric, it only has a secret and it can be used to hash values one-way.

Agree and disagree,

Deciding on how to store the credentials is still a hard task. Even storing the secret. Ideally it shouldn't stay as a plain text in your database. If you use cloud, something like KMS can be used for additional security. Also you should still consider replay attacks, rate limits etc.

I agree in the sense that TOTP is hard to implement, no it is not. I hope this article helped people understand how TOTP works.

Hashing is done before storing the secret on the server side. Therefore they still need to communicate regarding the intial secret.

Even though QR codes are standardized, the original RFCs do not use QR codes. That's what I tried to mean, you can't find apps that use plain-text secrets.

I also don't use email subscriptions, unless it is my favorite person. But I don't know how many of them are subscribed via RSS.

Clicking anywhere else discards it.

I have removed the popup anyway, seems like most people don't like it.

Nope not AI generated, I have used excalidraw. Only the cover page is AI generated.

Clock drawing was an asset, I didn't really spent time trying to match the time on clock to the time mentioned by the actors.

I see, I have removed the popup.

Two different flows, an online and an offline.

TOTP devices can be powered offline, which makes it extra secure, as you don't transfer any data around, possibility of leaking it is extremely low.

Random numbers could only work in online flow, where server sends you a one-time code using a secure communication method, such as a trusted phone number or email address.

I haven't mentioned MITM attacks in this article thoroughly. Can you give some examples on what authentication implementations carry a MITM risk?

I thought anything carried over SSL doesn't have a _significant_ MITM risk.

A simple click on a random place on screen should discard it. I wanted to connect with my readers so I have added that subscribe popup recently. As I have figured nobody subscribed to my newsletter yet :(

Let me know if it doesn't work. Also would be glad if you can give browser / platform.

I personally use 1Password with hardware keys where possible.

> It may defeat the purpose of 2FA

True, I think this as a mid-step of smooth transition from plain-text passwords to secure keys. You kinda get the benefit of both.

Also those apps are secured much better than a traditional password manager as browser auto-fill for example.

All very valuable comments! Actually I had a small edit on the "forget password" flow.

I agree that an asymmetric key makes much sense. Secret key can be left at the user device while server only contains the public key. That sounds much more secure. I will dig deeper!

True about the stuffing proteciton, I actually want to do further reading on how TOTP is secured from random attacks. Statistically you are expected to crack 1 account in every 1 million attempts in 6 digits codes. Those numbers look pretty huge in the context of security, and a bot-net can potentially brute force couple hundred accounts every day.

Thanks for all your insights, I have updated the post to outline this as a "theoretical" use-case rather than a practical one. I also revised it to include random number approach.

Hi,

> Also, the author struggled to check their implementation. One can easily compare an implementation of many websites by grabbing the QR codes they use for login and importing into your favorite authenticator app and also decoding the QR code to get the secret.

Can you clarify this? It's been some time since I have written the code, AFAIK it was working fine. Did you see any discrepencies when you tested the implementation against a real authenticator app?

Good catch. In my mind storing that random number is similar to storing a plain-text password, thus I thought they were generating TOTPs. Let's hear from others how they implemented it.