Closed domain. Not worth the effort...
I think it's typical to use the same password on all cameras in a system. I can think of some systems in my past which used three vendors' cameras but all the same password.
Is it a risk? Sure. If one is compromised, they all are. The question is how much of a risk is one being compromised? Assigning a unique password to every single camera is a bit impractical just because documentation gets pretty particular at that point. Ideal? Yes. Necessary? Probably not.
We have 200+ cameras, 7 NVR servers (soon to be 8), multiple workstations on a private VLAN and do not use the manufacturer default for any password. We use a fairly long and complex single password for all cameras with the exception of one manufacturer's devices which only allows 8 characters. Our password for those is complex, however. On the cameras that have a built-in viewer and/or user account that cannot be deleted, we change that password to be the same as the administrative password.
For us, only admins are authorized to change camera settings. The admin password is known by only two people, and if one of us leaves someone will spend a day changing passwords. We do the same with the admin accounts for our VMS application, servers, and workstations.
We do not consider this a security vulnerability any more than a domain administrator would consider the domain admin password a vulnerability. It does, however, require that we be diligent in protecting that password. If someone (e.g., integrator/installer) needs access to a device's settings we allow it only through the VMS and they are given a temporary user account that is strictly limited to the specific device(s) they need access to. If the VMS can't access the particular camera settings then we do the configuration with input from the integrator/installer.
Our camera VLAN is private and cannot be seen from outside our network and from only a select few other VLANs on that network. We consider the risk of hacking very low. Not zero, but low.
We have been keeping the camera switch segregated from the "normal" switched network when possible and only allowing a second NIC in the server to connect to the "normal" network. This way, only the server itself is actually able to connect to the cameras themselves. Sure, you still have the risk of the server being compromised, but that is always a risk as long as the network is connected to the internet. Proper firewalls and VLANS should help prevent server discovery anyways.
Batch password change by manufacture's utility. You can also add ip filtering + Mac filtering to limit direct ipc access.
As for security risk, psasword should be batched in before installation.
Since your cameras are on a private network then I consider it an acceptable practice to have the same strong password. That approach should be fine either via a VLAN or a physical private network.
For folks whose cameras are not on a private network, then yes I would utilize different strong passwords for each camera — even if it’s painful.
One of our staff (an ex-programmer) developed our own customised scan tool that finds almost any camera/device we need.. We can roll out passwords using his tool very quickly, as well as set IP address, see a thumbnail of the image and various other useful, time saving features. Its sooo handy and saves many hours when we are on-site. For example, the last thing we do is click one button and the tool will go and take an "as installed" full res image of all the cameras and store it in in our documentation area.
Regardless of using passwords, don't overlook the ability to protect all cameras by implementing switchport security based on learned, or assigned MAC addresses. Then of course you have to be vigilant and monitor the environment over time. Any changes in the MAC tables or disables ports needs an thorough investigation. To properly monitor the health of ports, RFC2613 on your switches is the feature, and perhaps one of the best tools we found for port monitoring is manageengine oputils, and intravue.
Else, another celebrity video clip could end up on youtube.
Actually, most managed L2 switches support MAC filtering simply by enabling the features once all the working cameras are up and running. Turn no MAC filtering, and their is a learned feature, and that's it. If your IP cameras and VMS support APIPA addressing, you can further simplify the lan by not using DHCP, or assigning Static IP addresses. You can install a small IP based camera system very quickly, and know that only your cameras will remain on the private camera network. The two tools I mentioned are sold on the number of supported IP addresses, and may have a free trial tool.
To seperate your company from your competition, you should at least discuss the idea of adding more security, and let them say no.
A question that I have related to this issue - are there cameras that have the ability to email on failed log-in attempts?
That would assume the private LAN has access to an SMTP email server to bounce email off off, and that might imply the LAN has a router in place, and that greatly increases the security footprint. regardless of the system being a video network, or an IT LAN, enabling MAC protection via learning, is perhaps the easist thing to suggest to a client regardless of size, to limit plug in access to the LAN and/or cameras. VLANS are great too, but more complex that simple MAC learned security on a small LAN... If you have a multi-homed (dual NIC) VMS then the LAN side can have access to email systems, and let the VMS advise you when cameras fail...
From my experience, since 84' supporting LAN's of all sizes, email has never been a reliable tool. There are many problems with email, and they include, the mail module isn't very smart, and a failed email never retries, the smtp mail server, must accept relays, and that's a no-no. We've found managing thousands of desktops, and hundreds of servers, we prefer to monitor systems on L2/L3 and manage the exceptions, and opposed to looking at email to see if things are good or bad... That takes a lot of human eyeballs..
Personally, I've suggested long ago to my preferred VMS vendor to develop a mechanism to dynamically assign a password from within the VMS package. IE, the superadministrator sets a camera password scheme, and it's pushed to the camera on bootup and registration. SIP, has had this technology for some time. Also it would be the berries, if they can set an authorized remote access password source IP address or IP address Range. This is common in LAN environment where you have routed VLANS.