Hacker News Reader

Comment by barbegal | Hacker News Reader

An interesting idea but in theory just three correct pass codes and some brute force will reveal the secret key so you'd have to be very careful about only inputting the pass code to sites that you trust well.

It's definitely computable on a piece of paper and reasonably secure against replay attacks.

View on HN

I was wondering about the overall security. How did you determine that 3 pass codes and brute force will reveal the secret key?

Thinking about it, there are only 10 billion different keys and somewhat fewer sboxes.

So given a single pass code and the login time, you can just compute all possible pass codes. Since more than one key could produce the same pass code, you would need 2 or 3 to narrow it down.

In fact, you don't even need to know the login time really, even just knowing roughly when would only increase the space to search by a bit.

Yep known issue, was hoping someone could spice the protocol up without making it mentally to heavy, hn is full of smart playful people.

Also @MattPalmer1086 the best solution for this I have now is to have several secret keys and rotate usage. Would be nice to have some additional security boosts.

Key rotation among a set of keys only partially mitigates the issue (have to obtain more samples).

It has it's own synch problems (can you be sure which key to use next and did the server update the same as you, or did the last request not get through?).

This post on security stack exchange seems relevant.

https://security.stackexchange.com/questions/150168/one-time...

Yep, I am aware, 2 or 3 OTP's and timestamps plus some brute forcing using the source-code. Server-side brute force by input should or could be implausible. But that is why I am signaling here that I would love a genius or a playful expert/enthusiast contributing a bit or two to it - or becoming a co-author.

I'm not an expert, but roughly know the numbers. Usually with password-based key derivation, one would increase resource needs (processor time, memory demand) to counter brute forcing. Not an option for a human brain, I guess.

So the key would have to be longer. And random or a lot longer. Over 80 random bits is generally a good idea. That's roughly 24 decimal digits (random!). I guess about 16 alphanumerical characters would do to, again random. Or a very long passphrase.

So either remember long, random strings or doing a lot more math. I think it's doable but really not convenient.

A handful of words is generally more memorizable than the same number of bits as a random alphanumeric string. You wouldn’t need a very long pass phrase for 80 bits as long as you’re using a large dictionary.

Reply on news.ycombinator.com