 <blockquote> <ol> <li>What are some advantages/disadvantages to using either approach?</li> </ol> </blockquote> <p><strong>Using sequential numbers</strong></p> <p>Advantages: Easy to implement</p> <p>Disadvantages: Possible vector for attack. See <a href="https://www.youtube.com/watch?v=gocwRvLhDf8" rel="nofollow">this video</a> for a high-level overview.</p> <p><strong>Using random numbers</strong></p> <p>Advantages: Solves the problems outlined in the video re: sequential record attacks</p> <p>Disadvantages: Since there's only 10 bits of entropy, ID's would have to be much longer if your app grows.</p> <p><strong>Base 64 (use this instead of hex)</strong></p> <p>Advantages: 64 bits of entropy means an ID 5 chars long would have 64^5 possible permutations. This allows for comparatively much shorter URLs. Use <code>SecureRandom.urlsafe_base64</code> for this.</p> <p>Disadvantages: None, really.</p> <blockquote> <ol start="2"> <li>Is there a good industry standard or best practice for generating synthetic ids for concepts like users, groups, posts, etc..</li> </ol> </blockquote> <p>To my knowledge, no. Anything sufficiently random and of sufficient length should be fine. Within your model, you'd want to check if an ID is taken first so you don't have duplicates, but outside of that there's little to worry about.</p> <blockquote> <ol start="3"> <li>What's the best way in Ruby/Rails to generate each of these IDs? I know of SecureRandom.hex but that seems to generate a long hash.</li> </ol> </blockquote> <p>Like I said above, I recommend using <code>SecureRandom.urlsafe_base64</code></p>