Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] Cutting the phone line



Kent Borg wrote:
> Rich Braun wrote:
>> ...go to the obitalk site and enter the unit's serial number. Then
>> enter your gmail account credentials. Done.
> 
> But I get worried again.
> ...if you expect some third party to login to Google on your
> behalf...

My understanding of the implementation in this case is that although you
enter the GV credentials into the cloud-based service (setup wizard),
they are not stored in the cloud, but simply conveyed to your Obi
device, and stored in its Flash memory.

Conceptually someone could still breach your Obitalk account and
potentially leverage the config access it has to your Obi to obtain the
GV credentials.

Using the cloud service for configuration management is optional. (I
don't use it.)

For actual call handling. the Obi device talks directly to GV. It isn't
proxied through Obitalk servers.


> Unless Google implements some special on-my-behalf feature for this
> case (they kinda do for gmail), your password is sitting on some
> disk, and that disk's backups, in the clear.

I'm pretty sure GV uses Google's usual account authentication
infrastructure, and as Rich mentioned, if you enable 2-factor
authentication, Google provides a mechanism to generate device-specific
passwords, and a UI where you can see when each was last used and revoke
them individually.

(Before you enable 2-factor you need an email address and password to
get into your account. After you enable 2-factor you need those, plus an
app generated code, have possession of a cell phone registered to the
account (to receive an SMS code or voice message), or pre-generated auth
codes (designed to be printed in case you lose your cell). Or email
address plus any of dozens of application-specific passwords. Seems a
little counter intuitive that increasing means of access from 1 to over
a dozen possibilities results in increased security... It would be
better if the app-specific PWs could be constrained to a single Google
service. At least they can't be used to access the usual web UI, and
thus can't change settings or be used to lock you out.)


> If you only use your Google credentials for Google Voice, or keep a
> separate account for Voice...

Generally a good idea, in my opinion. I used to have completely isolated
accounts for each Google service I used. Annoyingly the integration on
Android makes that very challenging to maintain. For example, the Play
store makes it a necessity to have a credit card affiliated with the
same account that you use for other lower security, inconsequential
activities.

 -Tom

-- 
Tom Metro
Venture Logic, Newton, MA, USA
"Enterprise solutions through open source."
Professional Profile: http://tmetro.venturelogic.com/



BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org