Random Strings and Integers That Aren’t

endpoint.com

26 points·samsk··10 comments

Should be common knowledge, but please avoid using 1, I, l, O, and 0 in codes such as these.

If you really want to avoid any potential similarities, your character option of A-Z and 0-9 is even more limited to "abdfhjkprstuvwxyzACGHJKLMNPQRVWXY3469", according to this research: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3541865/

The alphabets that are created for nanoid seems to be a valid choice too: https://github.com/CyberAP/nanoid-dictionary

It's not strictly necessary to remove all the similar characters, as you can treat any of the similar inputs as being the same. eg. you could include 8 or B in the output, as long as you accepted 8 and B as being the same character you chose for output at input.

If you want to avoid the possibility of accidental profanity in your "random" strings, it is definitely worthwhile removing the vowels, although that may not apply to other languages than English!

https://philzimmermann.com/docs/human-oriented-base-32-encod...

I disagree about excluding all of these in some situations. For example if you know you use CAPS, then L is fine and not ambiguous. 1 is also fine.

Until someone in design or marketing changes the font on you.

Which is why I only mentioned lowercase l. 1 in some (especially serif) fonts looks like l and in some others (especially sans serif) like I. Definitely not okay in general.

Should be common knowledge, but please start using decent fonts that can distinguish different characters

This post is in the context of a PostgreSQL stored procedure. If you have ready access to a block cipher, you could use one with an appropriate block size; e.g., 32-bit RC5 for coupon codes, 128-bit AES for activation keys, or 64-bit Blowfish for something in between.

Reply on news.ycombinator.com