4 ms·

Yeah it would be a fairly simple fix in code: they could hash some of the user data (e.g. email + name) and then append the id to create a token that won't ever

by crucio 13y ago

Yeah it would be a fairly simple fix in code: they could hash some of the user data (e.g. email + name) and then append the id to create a token that won't ever collide and is always unique. e.g. http://www.flickr.com/invite/?resend=<hash>-<id> http://www.flickr.com/invite/?resend=<hash>-<id>

Sovietaced 13y ago
Exactly what I was thinking, expiration isn't even necessary.
- kngspook 13y ago
  Of course, hashing _and_ expiration would be best. I'm not really seeing any good reason _not_ to expire them...
nilved 13y ago
Or just use a UUID.
- logn 13y ago
  UUIDs (depending on the version) could be easier to guess than a hash or random string. See http://www.ietf.org/rfc/rfc4122.txt http://www.ietf.org/rfc/rfc4122.txt --> 6. Security Considerations -- Do not assume that UUIDs are hard to guess; they should not be used as security capabilities (identifiers whose mere possession grants access), for example.
  - nknighthb 13y ago
    Under no circumstances are RFC-compliant UUIDs of any version as secure as a properly-generated 128-bit (or more) key. Even version 4 and 5 UUIDs necessarily have non-random bits. Furthermore, although the RFC makes a half-hearted attempt to nudge you in that direction, there is no assurance that any of the bits of a UUID are generated in a cryptographically secure manner. If you're using a UUID library that chooses its random numbers poorly, your results may be utterly non-random.
    - jamiesonbecker 13y ago
      Even so, UUID's would be nearly infinitely better than the current model of incrementing integers! Wow...
eli 13y ago
Sure, of course, but I would caution against playing armchair developer on someone else's product. I'm sure product decisions I've made seem odd and inscrutable to someone else, but that's because they don't know about the backend interface to a legacy system, etc.

4 ms·

Yeah it would be a fairly simple fix in code: they could hash some of the user data (e.g. email + name) and then append the id to create a token that won't ever

by crucio 13y ago

Sovietaced 13y ago
Exactly what I was thinking, expiration isn't even necessary.
- kngspook 13y ago
  Of course, hashing _and_ expiration would be best. I'm not really seeing any good reason _not_ to expire them...
nilved 13y ago
Or just use a UUID.
- logn 13y ago
  UUIDs (depending on the version) could be easier to guess than a hash or random string. See http://www.ietf.org/rfc/rfc4122.txt http://www.ietf.org/rfc/rfc4122.txt --> 6. Security Considerations -- Do not assume that UUIDs are hard to guess; they should not be used as security capabilities (identifiers whose mere possession grants access), for example.
  - nknighthb 13y ago
    Under no circumstances are RFC-compliant UUIDs of any version as secure as a properly-generated 128-bit (or more) key. Even version 4 and 5 UUIDs necessarily have non-random bits. Furthermore, although the RFC makes a half-hearted attempt to nudge you in that direction, there is no assurance that any of the bits of a UUID are generated in a cryptographically secure manner. If you're using a UUID library that chooses its random numbers poorly, your results may be utterly non-random.
    - jamiesonbecker 13y ago
      Even so, UUID's would be nearly infinitely better than the current model of incrementing integers! Wow...
eli 13y ago
Sure, of course, but I would caution against playing armchair developer on someone else's product. I'm sure product decisions I've made seem odd and inscrutable to someone else, but that's because they don't know about the backend interface to a legacy system, etc.