[mehrdadn]

Not really... it's not that simple. You could use the time of day as a seed for the hash, for example. There are tradeoffs to be made, which is partly why they don't do it, but the story isn't as simple as "the hash becomes the password".

[nl]

If the client knows to use the time of day then an attacker also does.

This is exactly the same: the seeded hash is the password.

[euyyn]

Then how does the server check that it's valid?

[mehrdadn]

The time of day is known to both the client and the server right? So they check to see that they get the same hash.

[hermitdev]

And how do you propose to do that when the clocks arent synchronized? Clock drift is exceptionally common. Not everyone runs ntp or ptp. Probably even fewer use ptp. Desktop/laptop clients it's typically configurable on whether or not to attempt clock sync, and ive never seen where the level of synchronization is documented for PCs. High precision ptp usually requires very expensive hardware, not something to be expected of home users or even a startup depending on the industry.

[LgWoodenBadger]

Well how do you think TOTP works?

[scrollaway]

TOTP works by having huge margins of errors (minutes worth). The original post is suggesting using time of day as seed.

[mehrdadn]

The point was you could do similarly here. Just have a margin of like 30 seconds (or whatever). I never said you have to do this to nanosecond precision.

[deepbreath]

But the password is only known to the client?

[mehrdadn]

Only if the server only keeps around the hash -- which is why I said there are trade-offs to be made. The point I was making was that the mere fact that you're sending a hash does not trigger the "hash-becomes-password" issue; that's a result of secondary constraints imposed on the problem.