113 reputation
4
bio website
location Utah
age
visits member for 2 years, 3 months
seen Apr 24 '13 at 15:29

I am currently working as a Senior developer for a payment gateway. I am interested in concurrency and mobile development.


Sep
21
awarded  Scholar
Sep
21
accepted Is it considered insecure in an HOTP implementation to publicly provide the next counter?
Sep
21
comment Is it considered insecure in an HOTP implementation to publicly provide the next counter?
Thanks for your input. The man in the middle attack you mentioned isn't one I had considered in my original proposal. Thank you for pointing it out. I really like the timestamp model here. It is almost but not quite a full TOTP implementation. My server won't have a clock (beyond elapsed time since startup) but will have network access. Pinging NIST once at startup for the correct time shouldn't be too hard to add. Thanks again for taking the time to help me with this question.
Sep
21
comment Is it considered insecure in an HOTP implementation to publicly provide the next counter?
So it sounds like I'd still have to track the current counter for each serial number in the microcontroller eeprom (which is honestly fairly tamper resistant) for each client (much more feasible than the key/counter combination). In this case would I send the HOTP code along with the serial number? Then on the server I'd derive the key from the master via the serial number and lookup the expected counter?
Sep
21
awarded  Student
Sep
21
awarded  Editor
Sep
21
revised Is it considered insecure in an HOTP implementation to publicly provide the next counter?
Fixed some incorrect sentences.
Sep
21
asked Is it considered insecure in an HOTP implementation to publicly provide the next counter?
May
1
awarded  Supporter