Security is More Than Just Passwords
One of the things I got out of the whole security issue with Broadvox was the simple fact that security is more than just passwords. I’ve actually known this for a long time, but the incident basically reiterates that point.
A brief summary of the events: over the past weekend, someone had “discovered” a web page containing the configuration files for a number of Broadvox Direct users. It turns out some of the files contained unencrypted information (the files are usually supposed to be encrypted). Some of this information was the SIP username and password for the end user’s service. Broadvox “shut down” the web page, reprovisioned all the affected customer accounts, then did a WTF just happened. After that occured, and Monday rolled around, Jeff posts his statement. The long and the short of it is: it was a small number of customers, there was no personally identifying data in these files, and the data in those files were not enough to use the service as someone else. It’s this last point that is the subject of some debate.
It is true that, at least as I understand SIP, the only authentication mechanism is username and password. But that isn’t the only data available to the switches authenticating the connection. There are a few other items available:
-
IP(s) used frequently to make calls. Now I know that most people don’t have “static” IPs, but the fact of the matter is, you usually use either the same IP or the same range of IPs quite often in a residental broadband setup. In my case, I not only have a static IP, but the reverse DNS of said IP points right back to phoneboy.com. This came in handy today when Broadvox was troubleshooting an issue for me. Now using a different IP may not be enough of a red flag itself, but if your “user id,” for instance, logs in from a US-based location and five minutes later logs in from a location in, say, Slovekia, that might be a huge red flag.
-
Calling patterns. Despite the fact that different IPs may be used, one thing’s for sure: most individuals have pretty “typical” calling patterns. That isn’t to say individuals don’t make the occasional “unusual” call, but typical patterns can be tracked and something that falls way out of that pattern might raise a red flag.
-
User Agent. Since most service providers provide a “locked” device to use their service, the “User Agent” for that device will be known and is something that can be checked. This can be spoofed, of course, but it’s another roadblock to throw up.
The switch can use any or all of these methods, plus others I haven’t described, in order to decide what the user can and cannot do. For example, a user might be able to authenticate with other SIP clients using certain credentials, but may not be allowed to actually make and receive phone calls, or calling may be limited. The decision about who and what to allow is a lot more complicated than the “right password.”
