With TCP connections you can cheat by checking the first time the connection is established. But for any incoming UDP packets, you're going to have not check on a per connection basis but a per packet one. And generally the reason you use UDP is speed. So you're going to be adding further latency to things that tend to be depending on speed.
Come again? Look, no offense but I'm not sure you understand what I'm talking about on a technical level, which may be the reason you think this is so difficult, but..
No, you only have to check one packet per login attempt. If the packet that brings the password does not have a local source IP and the password presented is the default, then you deny the login. End of story, like any other failed login, no checking UDP packets, no latency, no "staggering large number" of IP addresses to sort.
Why do I think this is easier, than forcing a new password?
Here are the two main reasons:
- No UI change. You will need to create a new screen flow, that handles redirecting to and from your force change screen, as well as new help for those screens.
- Not dependent on state. You need to check some global value in some database which tells you if the password has been changed. You will also have to write (possibly concurrently) the same state after password is actually created. BTW, make sure and update your auto password tool to maintain your global flag correctly as well. My way is stateless, requiring only the incoming packet to function.
As for the automated password change mechanisms, you maybe right, I'm not aware of what percent of cameras have them. That certainly would help.
I've certainly heard plenty of complaints over and over, haven't you?
Not sure what you background is, but every manufacturer just wants people to plug their cameras into the LAN and have them automatically show up on every VMS, NVR, LAN client, etc. Not even go into a mass update tool if it's avoidable. Integrators like simple, easy and universal discovery. Why wouldn't they, when every minute spent resolving connections issues is money out of their pocket.
So regardless of the actual burden, if the integrators believe it is a burden, that's bad enough. And make no mistake, for a lot of these mfrs, the integrator IS the customer.
So, no matter how much you wave away and say it's nothing to be concerned about, it is in fact the VERY reason that your solution has taken so long to get to market. You think they couldn't have done it 5 years ago? It took enough Hack attacks and fallout from to motivate SOME mfrs into action.
Cut to the chase, I asked why don't they implement this WAN check, you say because they should do something better.
But the reality is that the majority have not yet, so what do you say, are you in favor of the WAN block for those who are NOT planning a force original password scheme?
Yes/no.