- Feature Articles
- CodeSOD
- Error'd
- Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
How did I ended frist by clicking "random"?
Admin
#define nullptr "How the fuck? Comment already installed before the Article was posted?"
Admin
Well I'd go for the Nuke. After all, it's the only way to be sure...
Admin
It may be a bit silly, but the odds of a collision are more than low enough to be comparable to guid. Well, either that or I need more caffeine before doing arithmetic.
Admin
well, i'll go to orbit, not far but still away from this planet
Admin
Just be happy THIS dev didn't try to put this stuff in the wp_usermeta. So many ways to make a mess, so little time.
Admin
Just be happy THIS dev didn't try to put this stuff in the wp_usermeta. So many ways to make a mess, so little time.
Addendum 2020-03-05 07:26: sorry for double post. ... must be a duplicate wp_usermeta row.
Admin
Let's see...
There are 26 letters and we choose 6 characters. That's 26 choose 6 = 230230 possible 6-character strings. There are five of those, so the number to the power of five - about 600 septillion possible combinations. That's less than the number of possible GUIDs (2^128, around 300 undecillion), but still high enough. And that without the user ID in the beginning, which makes the probability of collision even lower (how many users will have the same ID?).
Admin
Actually 26!/20! = 165765600 each, because order matters. 5 times gives ~2^136, so actually more than GUID (not that it matters, though).
Admin
You assume that shuffle randomness is actually random.
From the documentation:
"This function shuffles (randomizes the order of the elements in) an array. It uses a pseudo random number generator that is not suitable for cryptographic purposes. "
Admin
Are you sure? There are four versions of uuids because each has its own set of trade-offs. If someone uses a version 4 uuid, then you know what you have. With this home-baked id, you have to do all of your own analysis and come to your own conclusions. That will be more work and the results won't be near as reliable.
Admin
Well, guid's aren't random... so...
Admin
I think the real WTF the posbility of SQL injection in your username
Admin
| (how many users will have the same ID?).
It can happen when a user changes their ID - the old one becomes free, and a new user would then use that as the 'unique' prefix to the pseudo random glob.
Admin
Depends on the type of Guid... Some are Completely random, some are not....
Admin
Even if the shuffle isn't suitable for crypto, it's probably still "random enough" that you wouldn't see a collision... wait. Wait a second, I think I know why one of those 'random' letters was replaced by a user ID now.
Admin
"You might ask yourself, “What does adding an email subscription have to do with authentication?” "
You may find yourself living in a shotgun shack And you may find yourself in another part of the world And you may find yourself behind the wheel of a large automobile You may find yourself in a beautiful house, with a beautiful wife You may ask yourself, 'Well, how did I get here?'
Admin
Do something reasonable: Have a userid field as a foreign key (cascade delete) to the user table. When the user record is changed in a significant manner (username or email address) or deleted the email subscription table should reflect it.
Admin
Letting keystrokes go by, let the vendor lock me down.
Admin
I just love the subtle little touches! Like initializing $guid=rand(); which is not only totally confusing, but also - as it turns out later - absolutely pointless.
Admin
Oh haha, the postmeta table, that reminds me of an older project where the client asked for more and more signup related content... We stored everything in postmeta, which was okay early on when we only had 5-10 fields we never queried, but the project ballooned up to ten times its size. And then they wanted to interact with the database from an external application, and make queries in the signup data.
The people writing that external application considered it too difficult to write queries that accounted for the postmeta relations, because they thought of all databases as excel tables, and did not consider that it is set up this way because posts could and did have arbitrary amount of settings stored.
So, we moved what we could into a handful of fixed tables, and wrote a ~20kb filter plugin, which redirected all get_post_meta and update_post_meta calls to the new table. If you asked for a specific meta field, it queried it from the new table instead of postmeta. Caching had to be handled too, as well as querying posts based on postmeta fields.
This way, we did not have to change nearly anything in the existing template code (which was over a megabyte of PHP by that point), and the administration panel loaded 10x faster (it was a large 50 column table with each cell making a get_post_meta call).
Admin
Not that this makes it any better, but in Wordpress a user can't change username. Not even admins can. You'd need database access for that.
Admin
I was asked to do something very similar as an 'unique' ID for a piece of data - despite my objections and a suggestion that I just use a UUID and the fact that most of the data they wanted to incorporate into the ID was already in the data itself. So I did it, and the ID was never used by anybody for anything.
Admin
it starts with the userid so this is an assumption but I am willing to bet that is a sequential number that happens to be unique. Since at no point is there another number used it would be guaranteed unique.
Admin
There are 26! ways of shuffling the alphabet. We're only interested in the first 6 letters, so that's 166 million. But we're doing it 5 times in a row, for a total of around 10^41 permutations.
The output is determined by the sequence of numbers from the RNG. The sequence is dependent on the state of the RNG at the start of calls, assuming the RNG instance isn't used for anything else between the shuffle calls. This limits the number of possible ID's (for each $user_id) to the number of possible RNG states. If it's a simple LCG (x_n = (A(x_n-1) + C) % M), then this is limited to the size of x, e.g. 32-bits. There would only be 2^32 = 4 billion possible ID's.
Use something big like a Mersenne Twister and you're fine, assuming it is seeded well and can be in any possible state when these methods are called.
Admin
LUL
Admin
(puts pendant on) Version 4 UUIDs are not completely random, they have a handful of fixed bits identifying them as version 4 UUIDs. (takes off pendant)
Admin
For the subscription key, content hash the email.
On successful wp login, run an action that requests if email or username is active to external authorization. Users work in Wordpress. Wordpress provides an endpoint for reporting and a webhook for actions. A lot easier to manage sites instead of users.
External authorization has something in front of it, instead of being exposed to 4.5 billion internet users and their bots across the world.
Also I would use Wordpress as a data source only for a static site on a CDN.
Admin
So were the letters a-z specified by a PHB who doesn't understand hexadecimal, or were they dreamed up by gasp a programmer who doesn't understand hex?
I shudder to think...
Admin
I'm reminded of a shuffle algorithm I've seen that was stated to not be suitable for cryptographic usage.
It used the system's standard library rand(3) to generate a 31 bit random number, of which the lower 16 bits were fairly random, but the upper 15 bits were not quite as thorough. It apparently had somewhere around 16 million values it could give. I didn't get the full details on how that worked, just that it wasn't as great as some.
Everything about how it would shuffle would be based on that number. Every time it got the same random number for a given input string, it would generate the same sequence of characters.
If that's what's going on here, there might be 2625242322*21 character sequences which could conceptually result from the operation, but there'd only be around 16,777,216 actual combinations that would come out of the 26! total possibilities of the order of the full alphabet, and that limitation would be felt in looking at just the first 6 letters.
The fact that the sequence progressed in a loop put this into sharp relief. Most of the time, your request for random numbers with so little other things happening between them would mean that your requests were generally consecutive requests of the system rand. That would mean that, except for those times when some other rand(3) call managed to insert itself into that mix, there were really only about 16,777,216 GUIDs that it would produce.
However, it would be worse than that, because there would still be other rand calls to the system, which would bring the system around for a loop sooner than you might expect. Also, sometimes the system would get rebooted, at which point the sequence would start from the beginning. I believe at that point we're dealing with Guaranteed Unsafe IDentifiers.