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] single sign-on



Rich Braun wrote:
> There was a business opportunity a long time ago to create single-signon for
> "The Internet".  I remember a 1995 talk (in Boston no less) by Bill Gates who
> described this opportunity, with the seeming assumption that his company would
> be the one to introduce it.  Maybe VeriSign could've actually pulled it off.

These services live and die by the early adopters, and early adopters
didn't trust Microsoft.

But it isn't so clear that another provider, like Verisign, could have
done any better, or if there actually was a business opportunity there.
 It seems like a confluence of technical and cultural roadblocks stood
in the way.


> But now we've got a plethora of "single"-signon services such as the widely-
> but not universally-supported Facebook Connect.

OpenID[1] was big for a while, and that's faded as Twitter's OAuth[2]
has risen. Sounds like the 2.0 version of OAuth is turning out to be a
mess[3,4]. I'm not sure what protocol Facebook Connect ("Log in with
Facebook"[5]) uses. I guess their own thing.

1. http://en.wikipedia.org/wiki/OpenID
2. http://en.wikipedia.org/wiki/OAuth
3. http://en.wikipedia.org/wiki/OAuth#Security
4. http://en.wikipedia.org/wiki/OAuth#Controversy
5. https://en.wikipedia.org/wiki/Facebook_Platform#Log_in_with_Facebook


> ...more-recent ones are trying to gather personal data.

And make it easier for vendors using the protocol to access your social
networking data[6], in addition to authenticating you.

> 6. http://en.wikipedia.org/wiki/OAuth#Abuse_of_OAuth_for_Internet_data_mining

In some cases using OAuth to permit this sort of thing makes perfect
sense. If, for example, you want Klout to analyze your Twitter activity,
then authenticating to Klout using Twitter as an OAuth provider, and
granting access to your twitter feed is logical.


> Users have long since stopped believing this is a problem...

Is that the case? Or are typical users frequently clicking on the "sign
in with..." buttons when they see them? I don't know.

Do you use this feature when you see it?

If it is implemented right, there are some security advantages to it, as
a breach at site using the authentication API only has your email
address and additional personal information it has accumulated to lose.
No password. And an authentication token that may be of no use (if tied
to an IP) or of limited use to the hackers.

On the other hand, the way the initial granting of access is implemented
in OAuth is ripe for phishing exploits. They improved on the usability
of OpenID, where you might have had to paste in a URL of your
authentication provider. With OAuth they carry you through the process,
bouncing you over to the provider's site to login, and then bringing you
back.

Consider how easy it would be for a malicious site to show a "Login with
Twitter" button, bounce the user to a faked Twitter login page, and
capture their credentials. Even for someone who knows what they are
doing, this could be easy to overlook if they aren't paying close attention.

Now consider the same deal in a mobile app, where the login page on the
OAth provider is typical presented without any URL visible or ability to
examine the certificate.

For me, "single sign on" serves no purpose, as I feel far more secure
with randomly generated, site-unique passwords that I manage. I do use
OAuth, but only in cases where the objective is to grant 3rd parties
access to the data held by the auth provider.


> As someone else here noted, the "unimportant" accounts can be used to
> impersonate you...

What's especially dangerous is dismissing an email account, like the one
at Gmail you might use for mailing list correspondence, as unimportant,
forgetting that the account is also listed as the recipient address for
password resets at other accounts.


> ...I've been recommending LastPass.com to my non-technical friends:
> but their service isn't free on mobile phones so I'm looking for a
> new recommendation.

LastPass is probably the best option for that audience. Keepass may be
free, but it doesn't provide a cloud or sync solution. It only makes
sense for those comfortable moving files around or able to setup and
manage Dropbox, Google Drive, or the like. (I use rsync on my LAN, so my
password database never goes into the cloud...at least not without
additional layers of encryption.)

 -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