Timeline for How to securely hash/tokenize a string
Current License: CC BY-SA 3.0
4 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 2, 2017 at 19:17 | comment | added | John Deters | Careful auditing and rate limiting are the best ways to secure an oracle against attack. And while the original poster says the tokens are never "sent", that does not stop an insider threat, nor is the future protection of the tokens guaranteed. It's far too easy for the marketing side of the business to look around a year from now and do something unsafe, like "let's include these tokens on the survey forms so we can see who is responding!" Multi-use tokens just take on too much risk. | |
| Mar 2, 2017 at 8:58 | comment | added | Out of Band | @JohnDeters: Interesting analysis. You could make the attack expensive by using aggressive rate limiting. If you allow for five queries from the same IP in, say, 10 minutes, and have anyone who exhausts this wait for progressively longer periods of time between tries, an attacker will need to rent a large botnet to hide his oracle attack from the rate limiting code - and the rate limiting code could still pick up increased usage and either sound an alarm, lock down the system or implement even harder rate limiting. | |
| Mar 1, 2017 at 15:58 | comment | added | crgwbr | The token is just an internal identifier used to uniquely identify an account. It's never displayed to the user or sent anywhere. | |
| Mar 1, 2017 at 14:58 | history | answered | John Deters | CC BY-SA 3.0 |