Are You Diffident?

It always amused me when someone says “my personal opinion”. I find it strange, because the “personal” part is superflous. If the person says “my opinion is that red is a nice color”, I assume that the person means what he says: To him, red is a nice color.

If I then give him a red shirt, he says “don’t like it, I hate red”, I would assume some mental illness at play…

“but.. but.. you just said…”, I stutter

“yes, but that was not my personal opinion”



Opinions don’t have to be personal, sometimes you’ll read “it is the opinion of the court” and things of that nature. But in those cases, it’s pretty clear that it is not the opinion of the person saying the words, that we are talking about. It would be exceedingly weird if the court clerk said “in my opinion, the accused is guilty”.

There are people with mental issues that have trouble with this concept. It is known as Dependant Personality Disorder. It basically means that you can’t have an opinion on anything, you constantly have to ask someone else what their opinion is and then act in accordance with that.

Someone who is deeply narcissistic (borderline?) might assume that everyone in the world, besides themselves, ought to suffer from DPD, and become upset and frustrated when people have opinions that do not align with what they are preaching.

The truth is that finding factual, verifiable information about IP cameras and software is getting easier every day (and this is an old video). Like most people, I don’t much care for what salespeople are saying if it can’t be verified or measured. If the salesperson can provide the raw data, I’ll take it. I will form my own opinion based on what I see. I don’t need some Gríma Wormtongue whispering into my ear.


With the commoditization of IP cameras, increasing demand for true interoperability we’re getting to a point where facts are valuable, whereas opinions are not (yep, this blog is free!!!). In some cases though. arguments and opinions may be based, not on unbiased interpretation of facts, but instead it is shaped by grudges and anger.

If you are paying for facts, you definitely should demand full disclosure, or if you’re not, you need to ask yourself, am I reading verifiable facts, or just bullshit? You might ask: Are manufacturers paying (directly, or indirectly) the one stating opinions about either the manufacturers products, or the products of the manufacturer’s competitors? If you’re being lied to in the full disclosure, you might be lied to elsewhere.



Password Security

When you’re dealing with user passwords, the site owner does not (or should not) want to know the actual password the user enters. A very good reason for not wanting to know the actual password is that if the database is leaked, in one way or the other, whoever gets hold of the database won’t know the passwords.


What you do instead, is to save a hash of the password. A hash is a kind of checksum, so that for a given input, you get a fixed length output value. A very simple (and useless) hash is to just add the ascii-values of each char together, taking modulo 256 of the sum.

So, when the user enters “23456” as his password, you calculate the sum of the ascii-values ( 50 + 51 + 52 + 53 + 54 ) = 260, take the modulo 256 of 260, we get “4” as the checksum, we then store the “4” in the database, instead of the “23456” string.

Username Password-Hash
Morten   4

The next time, the user comes along, we do the same calculation, and compare the results. If the result is “4”, the user gets access. If the user, by a mistake, entered “23457” we’d get the hash of “5” and we’d reject the user.

But wait a minute, the astute reader yells out, banging his fist on the table: “the password “65432” would give the exact same hash!”. And the reader would be correct. This is known as collision, and is why some hashes are good, and others are bad. In my idiot hash algorithm, it is completely trivial for someone to find a combination of letters that give “4” as the output.

Instead of a useless hash, you might use some that are considered “good”. The SHA family of hashes are generally considered the gold standard of hashes. Bitcoin, for example, uses SHA-256 to provide Proof of Work.


So, let’s say we pick SHA-1, and we store the output of that. In that case we’d get

SHA1( "23456" ) = c24d0a1968e339c3786751ab16411c2c24ce8a2e

But what if two users have the same password? Consider these two rows in the db

Username    Password-Hash
Morten      c24d0a1968e339c3786751ab16411c2c24ce8a2e
John        c24d0a1968e339c3786751ab16411c2c24ce8a2e

If I know the password of “Morten”, I also now know the password of “John”.

What you do, instead, is to add a “salt”. The salt is just a random sequence of strings that I append to the password before computing the hash. For example, with salts, we’d get

Username    Password-Hash                               Salt
Morten      ac5740fde13da84ba4a5266ce9e9b7d697e0622b    xyz
John        c96bbd1bed0ffa3f5a0098ce7ee568ce6e9d496c    abc

Now it’s not apparent that Morten and John both use “23456” as passwords, and we’re almost done….

Brute Force Attacks

In my bad hashing algorithm, it’s pretty clear that you can’t guess my password from knowing the hash value “4”. On one hand it means that other users, might easily get access to an account on the site, but on the other hand, it also means that they can’t guess the original password.

This means that even if they could get access to an account on the site using the (false) password “65432”, they probably wouldn’t be able to access the users gmail account, because it uses a different security model, and in that case the “65432” just wouldn’t work.

However, if the site uses SHA1, the chance of collision is quite low, which means that if I can find an input string that gives the same SHA1 there’s a very good chance that I found the actual original password, and if the user reused the password on other sites, I might be able to gain access to those too.

Brute force attacks don’t actually try every conceivable input, instead it uses something known as “rainbow tables”. These are tables of the most common passwords, As GPU’s improve, the number of SHA1 computations we can make in a given time increases. For example, a new NVidia GTX 1080 TI will do 11374.1 MH/s

In other words, SHA1 salted passwords are not safe, and they are certainly not safe if they occur in a rainbow table somewhere, and there is plenty of software available to accomplish this, hashcat being one.

What To Do?

If you’re reading this, you probably aren’t using either “password” or “123456” as passwords (or are you John?). Furthermore, if you are using “123456”, then you probably are also using the same password for multiple logins, and chances are your other accounts have already been breached.

Two-factor authentication goes a long way to remedy the situation; if the user logs in from a new IP (meaning outside a subnet of known verified ips), then the 2nd stage kicks in, and you need to authenticate over email or SMS. However, this doesn’t work too well if the user uses “123456” all over the place, because the attacker might already have access to your email account (especially if the email account is your username on the site).

Enforcing “good” passwords on the site is also an improvement. You don’t have to go nuts on the requirements that it has to have special chars, upper and lower case etc. The site could actually generate the password for you. This way it would be unique, and hard to guess, if the site was breached, only the site would be affected, and if the site is just a TMZ style rag, the damage would not be too bad.



The Parts of an IP Camera

To understand where the IP camera market is headed, I think it’s important to understand how one of these things are put together.

Like most high tech devices, each product is really an amalgamation of parts from different manufacturers. In fact many products are the result of tight, but perhaps unappreciated, collaboration of several (sometimes competing) companies. I’d recommend listening to Freakonomics rundown of the “I, Pencil” essay (starts 7 minutes in).

So, an IP camera is not a pencil, but just like all pencil manufacturers don’t manufacture every single part of the pencil, but instead, they purchase the parts (graphite, brass, paint and so on) and every manufacturer puts the pencil together following roughly the same pattern.

And, so, when it comes to IP cameras, they too are composed of parts that are available to everyone who wants to start making cameras.

You’ll need a couple of things: A lens, a sensor, some circuitry and some code.

You’re not going to start making your own lenses or sensors, are you? Probably not, so you’ll get the lenses from a lens maker (and they may even outsource their manufacturing process even further), and the sensor from either Sony or Canon.

You’re not going to design your own CPU either (unless you’re Axis). Today, you’d be better off grabbing an ARM platform and use that to drive the sensor and interface. The other advantage is that ARM is well supported in the software world, so you’re already halfway there.

Now that you have the basics, you need to write some code to get it all working together. If you went the ARM route, it’s pretty simple to get a linux kernel running. Well.. “simple” is depends on your level of skill, but finding a few geeks who can do this shouldn’t take long. So you grab the Linux kernel, add Apache or perhaps GoAhead, you can add gStreamer too (do check the link, it is a great presentation by Axis) . The next thing you know, you have a jumble of cables and breadboards, burns on your fingers from the soldering iron, you haven’t seen your kids in 4 days and the smell is getting a little hard to stomach.

On top of that, you need to wrap this in an enclosure. There’s regulations to follow, tests that need to be carried out and so on. Then you have the nightmare of maintaining all those pieces of code, and trust me – if you wrote everything yourself, it would take even longer and be much harder to test and maintain.

What if there was a company, that could do all of the above? And just stick my name on the box? After all, my company would pick the same lens, the same sensor, the same board and the same software, so why not do it?

I have no intention of starting production of a Raspberry Pi Zero based IP camera, but I know that I can make one for ~$40 (and that’s buying all the parts retail). Not only will this thing work as an IP camera, it can work as a full fledged stand-alone VMS.

In other words, the question is: if some washed up coder in Copenhagen can build a fully functional “IP camera” for $40, I think you’re going to face a tough time if you’ve based your entire organization around selling your cheapest cameras for $250+ (they may be “even more good enough”, but who cares?).

Obviously, my camera is not going to be materially different from the other guy’s cameras. We’re all going to use the same bits and pieces, including software, even the damn protocols are going to be the same.

So, I think we’re going to see a race to the bottom in terms of prices. The cameras will look and perform almost identically across brands, use the same protocols, and be completely interchangeable, much to the chagrin of the incumbents, so the USP for the brands in this realm will have be something else.

VMS Software, perhaps…







HDR and Low Light

In the early days, the only thing that mattered was pixel count. The more pixels you could cram onto a sensor, the better. Some people noticed that the higher pixels count would decrease the performance in low light scenes (for the same sensor size), and we got to a point where you’d have ridiculously high resolutions on extremely small sensors, but you’d need to be a few miles from the sun in order to get good, sharp footage.,

There are all sorts of software tricks that you can employ to improve the appearance of the image to the casual observer, but you can’t conjure up data that just aren’t there. One trick is to use very long exposure, but that causes moving objects to get blurry, or you can do noise reduction, but that also removes actual details.

So what happened that caused the cameras to suddenly improve quite dramatically over the last couple of years? The sensor guys came up with back-illuminated sensors. Basically, the sensors got a hell of a lot better, and now we’re reaping the benefits.


Xda-Developers has a great article on the Sony IMX378 explaining BI sensors and how HDR is achieved. And of course, there’s always Wikipedia.

Competition is a wonderful thing.





A while back I got fed up with people parking their cars right in front of my driveway, and I decided to find a solution.

A camera could work, but since I am cheap, I decided to look for something a bit more… economical. A PIR sensor wouldn’t work because it triggers when there is motion, and cars and people pass by all the time, so I looked into ultrasonic sensors and eventually radars. If the distance measured drops below a pre-defined threshold and stays there, I know to run into the street, yelling and screaming.

The inspiration came from Adafruit and Andreas Spiess who has a great YouTube channel where you can get more information about ultrasonic sensors and radars (and about 1000 other things).


Basically, you can get an Arduino capable board. I hope the WiFi capable ESP8266 will work (since I have one lying around). Then get some cheap sensors from China via Alibaba and you’re ready to experiment. At the very least, it should give you some idea of the base cost of such a device.

Both Axis and Avigilon have launched commercial versions of miniature radars that can interface to your favorite VMS. Combined with a PTZ camera this might be a very interesting combination that offers a bit more smartness than the good old PIR/PTZ combo.



As with IP cameras, one of the IoT challenges is how to get your controlling device (typically a phone) to talk to the IoT device in a way that does not require opening up inbound ports on your firewall.

All communication is peer to peer, so the term, when used in the context of IoT devices, is perhaps a little misleading, after all, an exposed camera sending a video stream to a phone somewhere is also “peer to peer”. Instead, P2P might be translated to “send data from A to B, even if both A and B are behind firewalls, using a middleman C” (what the hell is up with all the A, B, C these days).

On a technical level, the P2P cameras use something called UDP hole punching, which sounds a bit onymous, but there’s really nothing sneaky about it. What happens is that A connects to C, so that C now knows the external IP address of A. Likewise, B also connects to C, and now C knows the external IP address of both A and B.

This middleman, now passes the IP address of A to B, and B to A. Next step is for A to fire a volley of UDP packets towards B, while B does the same towards A.

The firewall on A’s side sees a bunch of packets travel to B’s address, and when B’s packets arrive, the firewall thinks that the UDP packets are replies to the packets that were sent from A and let’s them through.

You could accomplish the same thing by having A go to “” and email it to B, B would then do the same. Then run scripts that send UDP packets over the network, but a STUN server automates this process.

But who controls this “middle man”? Ideally, you’d be in charge of it; you’d be able to specify your own STUN-type server in the camera interface, so that you have full control of all links in the chain. In time, perhaps the camera vendors will release a protocol description and open source modules so that you can host your own middle-man.

The problem might be that you bought a nice cheap camera in the grey market. The camera is intended for the Chinese market, but comes with a “modded” firmware that enables English menus and so on. This is obviously risky. Updating a modded firmware may be impossible and brick the camera, and the manufacturer may be less inclined to support devices that have been modded. You get what you pay for, so to speak (and this blog is free!)

The modder is selling the cameras in the western markets, but the STUN server is still pointing to a server in China. This makes sense if you are a Chinese user, but it may seem very strange that your camera “calls home” to a server in China. A non-modded camera might do the same, simply because running a STUN service is cheaper, and allows the government to eavesdrop on the traffic. If you are Chinese (I am not), you could argue that you don’t trust Amazon, Microsoft or Google because they might work with the NSA. Therefore, using your own server would be preferred.

Apart from the STUN functionality, the camera may follow direction that are sent from B to C to A. This puts a lot of responsibility in the hands of the guys maintaining this server. If it is breached, a lot of cameras will then be vulnerable.

Depending on the end user, P2P may not be appropriate at all. To some users, the cost of a breach is small, compared to the hassle of installing a fully secure system it might be worth it.

While yours truly has abandoned all attempts to appear professional over the years, the truth is that most big installations have their shit together. Unfortunately the volume of DIYers and amateurish installers who don’t really know what they are doing is much bigger (in terms of headcount, not commercial volume), and if there’s one thing we all want to do, it’s to blame someone else.

Caveat Emptor.