Re:Blog post id enumeration can lead to unwanted information...
by stan_rogers on Monday February 29, 2016 @01:39AM
(#11193937)
A base 30 time stamp will give you about the right number of characters, case-insensitive, and without the possibly-ambiguous 0, 1, O, I, L (lower-case ambiguous) and Q (possibly upper-case ambiguous) using 23456789ABCDEFGHJKMNPRSTUVWXYZ as valid characters. Adding back the 0 and 1 (that is, anybody listening to a user on a support call, or any code, would automatically interpret I or L as 1 and O or Q as 0) gives you base 32 and a shorter ID code. If milliseconds are going to be too collision-prone (that is, you can't recuperate the time you'll occasionally have to advance), a short entity code (user or server name abbreviation, f'rinstance) prepended with a dash should make it memorable and user-friendly.
[ Parent
| on HN ]
Re:Blog post id enumeration can lead to unwanted information...
by gmac on Monday February 29, 2016 @01:53AM
(#11193975)
I suggest you remove the remaining vowels from that, giving base 27. Then you have no worries about accidentally generating obscenities.
Re:Blog post id enumeration can lead to unwanted information...
by stan_rogers on Monday February 29, 2016 @02:12AM
(#11194027)
Oddly, nobody ever seems to worry about that with hashes, encryption output or GUIDs... but if it's a worry, then, sure, hey, why not. (By the way, that system has been in regular use for more than 20 years in commercial software.)
Re:Blog post id enumeration can lead to unwanted information...
by zo1 on Monday February 29, 2016 @02:21AM
(#11194057)
Thank you for that! I could have had a very front-facing "dirty" bug make it into production soon.