Hacker News Reader

Comment by landgenoot | Hacker News Reader

I have been thinking about a useless TOTP app that works the other way around. Instead of giving you the current code, it gives you the timestamps when the code is e.g. 000000, 123456 or 777777.

With a window of 30 seconds and 1e6 possibilities, the expected time it takes to get to a particular number is 347 days. Should be easy to brute force.

View on HN

In a deep voice: Your wish is my command.

https://gist.github.com/skull-squadron/8f806b28abbcaa1ba9c25...

Unfortunately, it may take several years before a certain TOTP value is reached because the values are nondeterministic rather than ordered and so there will be hash collisions of other values as well.

Example: JBSWY3DPEHPK3PXP 999999

    TOTP will match 999999 between 2024-11-29 16:37:00 -0600 and 2024-11-29 16:37:29 -0600

The community here keeps impressing me. Nice job!

Yes it could be several years, however the expected value is less than a year. Just like the expected dice rolls before rolling 6 is 6.

Yes, it's good to disambiguate that it's expected in a statistical sense but it's not an upper bound or confidence interval.

I also wrote a program to find CRC32 hash collisions that can be injected into a text file or script to make a text hash to that value. https://gist.github.com/skull-squadron/c85d295cf9e6124dd7e90...

Doing so MD5, SHA1, or even SHA256 would be extremely slow and expensive, but not impossible.

You don't need to brute-force CRC-32. I do a preimage attack directly using linear algebra: https://www.nayuki.io/page/forcing-a-files-crc-to-any-value

That's neat but I'm embedding the CRC-32 hex digest itself in a TBD location rather than a chosen text. It's moot because the time savings would be premature optimization. Brute force takes only a couple of minutes and I barely use it. Thanks for the thought though.

Selective partial SHA1/SHA2 matches only take a few seconds. https://github.com/not-an-aardvark/lucky-commit

Not so useless. A user of that could memorise the times/dates where a particular easy-recall code comes up. With that, they have effectively "transferred" 2FA for those times into their brain, and not need to use any 2FA app (at only those times).

Good luck memorising a number of 30 second windows and hitting them exactly. That would require a level of organisation, timing and self-discipline I can not fathom.

Well, the thirty second window in practice is usually a 2 - 3 minute window, as TOTP servers are set up to allow for drift, network issues, human slowness etc. For sure, memorising more than a handful may be hard but it's just "11 Nov 14:35", etc.

I wonder if something could be set up to be both more secure, and more tailored to this use-case. Be pretty sweet to embed a 2FA in users brains somehow.

  > Be pretty sweet to embed a 2FA in users brains somehow.

2FA already has a concept of "Something that you know".

Still, "Something that you could calculate without revealing the thing that you know" is an interesting concept.

This is a fascinating idea. Would you mind if we call it a "cryptographic hash"?

Well, it's been a long time since then, but I've had some crypto and some hash mess with my brain. ))

I think it would be easier to use HOTP for that as the codes are one time use and aren't time based. The user just needs to memorize one of the next N codes.

If you are able to choose the seed you could brute force it so that it produced a memorable code at a memorable time.

That's a very cool idea, with the caveat that if an attacker knew you were doing that, the search space for your key would shrink.

You mean like this? You can get push notifications when your codes are “cool”

https://open.substack.com/pub/jacobbartlett/p/building-a-2fa...

Reply on news.ycombinator.com