The spec doesn't define a max length... Instead.... "For example, if Token Secrets are valid for two weeks, Service Providers should ensure that it is not possible to mount a brute force attack that recovers the Token Secret in less than two weeks. Of course, Service Providers are urged to err on the side of caution, and use the longest secrets reasonable. "
However with most providers making their tokens infinite expiry this is kind of defeated as an approach. It's also impossible to determine what can be done in X weeks. For a big botnet owner they might have enough CPU to crack the longest keys in less then any token expiry period measured in weeks. It'd be nice from a developers standpoint to have some indication of how large to make our database fields for recording tokens. Maybe the brute-force aspects can be better mitigated elsewhere, as it seems no- one is following the spec in regards to expiry recommendations. Just spent hours looking for what turned out to be a truncated token because I didn't make a database field long enough. I don't often jump straight to 255 characters for a varchar field. -Ben --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
