network profile
| bio | website | |
|---|---|---|
| location | Utah | |
| age | ||
| visits | member for | 1 year |
| seen | Apr 24 at 15:29 | |
| stats | profile views | 0 |
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 |
