Last week, I needed to find a way to generate a random and unique id to get names for phone files on ios systems. Anyway, googling around, I found ...
For further actions, you may consider blocking this person and/or reporting abuse
If length is long enough then this is likely to produce non-conflicting ids for many cases on a single system, the problem is that they are not cryptographically secure. Conflicts become more likely when it is used on multiple systems.
The reason that they aren't secure is that Math.random() is predictable and not "really random". In fact, producing one ID with this method, of reasonable length, would probably give enough information to work out what the next ID was going to be.
This is a problem if you used such an ID as the key to a database record and then exposed that ID in a URL, because a hacker would be able to work out many other IDs and potentially access data they shouldn't.
To create really secure IDs then some "entropy" should be added - this is something that you could derive from the system or the environment. Like the movement of the users mouse, the number of packets received on the server. Something that is not computer generated if possible. You should also make the random part of the calculation come from a cryptographically secure method. There are many with different characteristics, for instance the mersenne twister is considered good, there are many way of getting that algorithm including this.
Exactly. Problem with generating some "random and unique" string may sounds trivial, but it's not. As addition to what you have wrote, the problem is tried to be solved by ietf and uuid implementations: ietf.org/rfc/rfc4122.txt
Personally I use nanoid which is ideal for many circumstances, has variable length and is faster that uuid
maybe this one liner help (toString(32) means radix: 32):
result is random text with lead a -> k other character small letters and numbers.
You can use this package to create a UUID npmjs.com/package/uuid it works in browsers and Node.
Your solution will not create a unique random string.
+1
Well, this will be random but not unique. Kudos.
As a proof-of-concept or coding challenge, this is okay but DO NOT DO THIS IN A PRODUCTION ENVIRONMENT!!!! If you need random, unique IDs use uuid packages from npm. There’s a saying “don’t reinvent the wheel” especially when your “wheel” is a less-good version.
For production systems don’t: roll your own encryption, roll your own auth (unless you REALLY REALLY REALLY know what you’re doing), roll your own ID generation.
If you do any of the above YOU WILL BE HACKED.
Best solution:
Date.now(); // parse this as string
Nope, that's a really bad solution.
Well done
If this is not so frequent, you can use date.now()
Things are not frequent until they are. If you ever expect to scale, don't even start this way.
Plus it's guessable.
thanks, good post