News for hackers. Stuff that matters.
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.
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.
Re:Blog post id enumeration can lead to unwanted information... by dsr_ on Monday February 29, 2016 @08:20AM (#11195250)
GDDMNSHTFCK.
Re:Blog post id enumeration can lead to unwanted information... by gmac on Wednesday March 09, 2016 @07:26AM (#11252530)
Bless you!