A few years ago I setup an Asterisk (*) server at my house which ran for many years on a NSLU2. It was used as a proof of concept and included IAX2 and SIP connections (over VPN) to other people’s * servers. An elaborate dialplan and connections running all over the place made everything messy but fun.
Fast forward to a few weeks ago when I started working from home. I had a few choices about telephony in my office. I could have used the home phone but I definitely don’t want to give that number out to customers and coworkers. Then there’s the cellular phone that the company is picking up the tab on anyway but I’d like to conserve those minutes for customer emergencies. So it seemed that I had only a few choices left. I could have had the phone company “turn on” another circuit for me or I could roll my own. My inner geek was screaming at me. Now was the time I could use my * knowledge for good! Of course my * knowledge had dribbled out of my left ear over the last year or so since I really played with everything so I ran into a few roadblocks. Luckily I know people who are much smarter than me (and that I trust with sudo access to my server).
On my desk I’m running a Grandstream GXP-2000 (four line phone but how many people can I talk to at one time?) and I’m running CSipSimple on my Android device. I can call myself (and my wife) directly over the internal setup without touching an external line but what fun is that? I needed access to the PSTN so I could contact customers over the twisted pair. Well, I already have a Google Voice account with phone number that I had been using for work-related contacts, as well as some personal contacts, so it was an obvious choice. At Ohio Linux Fest one of the speakers talked about connecting * to Google Voice which further inspired me to make this happen.
Luckily for me the * community maintains instructions for doing such things right on the * wiki! It was almost as simple as copying and pasting the examples from the wiki to my config files. I did run into a few problems but did I mention I know people?
After a few tweaks (okay, probably more than a few tweaks but I’m telling this story) phones were ringing everywhere. I can dial out, dial in, and communicate with others everywhere now.
I’d like to take a moment to send good karma to Jared for helping me get everything straightened out and working.
I guess I should go call someone now…
Sparks’ Linux Journal by Eric “Sparks” Christensen is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
Permissions beyond the scope of this license may be available at https://sparkslinux.wordpress.com/license/.
A few months back Google introduced “2-step verification” for all Google accounts. This amounted to multi-factor authentication (something you know (password) and something you have (token)) for all web-based Google applications. Cool, right? They created an app for the Android, I-Phone, and Blackberry devices that acted like a token and if you don’t have one of these devices Google can just send you a code via a text message for you to use to login. Okay so far?
Up until this point I’d say that Google has done a pretty good job on this implementation. Of course we haven’t included those users that access their Google accounts via a third-party program (Thunderbird for email, their Android device, maybe some plug-in for Blogger, etc). These programs don’t have a mechanism for logging in with multi-factor authentication. Google thought about this and created application passwords that you can use for a program to gain access without using a token. The passwords appear to be sixteen randomly generated numbers and letters and cannot be viewed after they have been viewed that first time.
This is an interesting concept. Essentially you have many keys that now fit the same lock. Loose control of one of those keys and you can simply nullify the key remotely. So far so good? Well, what you have also done is increase the number of keys that can get access to your system. If a brute force attack were done against a Google account before 2-step verification was enacted the security was up to the user’s password strength. Now an attacker has multiple chances to gain access to the same lock because there are many more keys available.
I would like to point out that sixteen-character passwords are a lot better than most people’s passwords which average eight characters or less. But is having more keys to the lock (and knowing characteristics about that key) more of a security problem that what is being used without the 2-step verification? I guess time will tell. I would like to point out that I don’t have a better solution to the third-party application issue. Perhaps some sort of machine readable token?
Sparks’ Fedora Project Journal by Eric H Christensen is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.