By Jake Edge
June 2, 2010
When last we looked in on
OpenID, it was close to finalizing the OpenID 2.0 specification. That
was in 2007; since that time, various other identity management solutions
have come about and have been more widely adopted, OAuth in
particular. One of the architects of OpenID, David Recordon, has put out a
idea (or "strawman" as he calls it)
for a new API that
combines the best of OpenID and OAuth into "OpenID Connect".
There are a number of shortcomings of OpenID that Recordon and others would
like to see addressed. In the three years since the last revision, the
internet has not stood still, but OpenID has. OpenID works reasonably well
for web sites, but is much more difficult to use for things like desktop
widgets or mobile applications. A bigger problem is that OpenID's
user-centric nature has made those users less "valuable" to web sites,
which results in fewer sites adopting OpenID.
OpenID is structured such that users need only share a limited amount of
data (typically just a URL) with a site in order to register with it. That
is good from a privacy perspective, but doesn't give site owners
information that they want, like name, email address, photo, and so on.
According to Chris Messina—who originated
the OpenID Connect concept and name—that makes OpenID users into
second-class citizens: "Because OpenID users share less information with third parties, they are perceived as being 'less valuable' than email-based registrants or users that connect to their Facebook or Twitter accounts."
More and more sites are farming out their identity management to big sites
like Facebook and Twitter using OAuth. Messina and Recordon's idea is to
reimplement OpenID atop OAuth 2.0, which would leverage that
existing—widely adopted—API for identity management. It would
also allow OpenID to become simpler for web site operators to implement.
Recordon pointed out some of the problems he has heard about:
I've heard story after story from developers implementing OpenID 2.0 who
don't understand why it is so complex and inevitably forgot to do
something. With OpenID Connect, discovery no longer takes
over 3,000 lines
of PHP to implement correctly. Because it's built on top of OAuth 2.0, the
whole spec is fairly short and technology easy to understand. Building on
OAuth provides amazing side benefits such as potentially being the first
version of OpenID to work natively with desktop applications and even on
mobile phones.
Based on that, one might wonder why OpenID doesn't just adopt OAuth, rather
than build atop it, but
there is an important distinction between the two. OpenID Connect would
still decentralize the storage of user information and allow the
user-centric nature of OpenID to survive. Users would be able to choose their
provider or run their own that stored their personal information. That
way, users would get to choose whom to trust or to only trust their own
server.
Another problem that OpenID Connect hopes to solve is to simplify things
for users. Right now, users have to remember and type in a URL that
corresponds to their OpenID provider, or click on multiple buttons for
popular providers (which leads to the so-called NASCAR
problem where there are multiple logos as buttons). OpenID Connect
would allow for simpler URLs or even email addresses as identifiers.
It is important to recognize that this proposal is being driven by
the fact that OpenID adoption has largely stalled. That has happened
because the sites that folks want to use want a little—or a
lot—more information about those who are signing up for or using their
services. There is a trade off, clearly, as it is not unreasonable for
site owners to require more information as a kind of payment, as long as they
are up front about it. But
the privacy conscious are likely to still be marginalized as the demands
for information increase.
While there currently is a lot of noise being made about privacy concerns
for sites like Facebook, there appears to be little actual action about it
by most users. Privacy just does not seem to be something that is high on most
users' priority lists, or, perhaps, Scott
McNealy was right: "You
have zero
privacy anyway ... Get over it."
OpenID Connect seems like a reasonable idea, overall, but as long as the
majority are happy with the current OAuth-based systems, it is a little
hard to see it making any headway. Yes, it may be used by a small minority
of internet users, but it is likely to require just enough effort that most
will not take advantage of it. It would seem that many are already "over it".
Comments (4 posted)
Brief items
The activist siphoned more than a million documents as they traveled across the internet through Tor, also known as "The Onion Router," a sophisticated privacy tool that lets users navigate and send documents through the internet anonymously.
The siphoned documents, supposedly stolen by Chinese hackers or spies who
were using the Tor network to transmit the data, were the basis for
Wikileaks founder Julian Assange's assertion in 2006 that his organization
had already "received over one million documents from 13 countries" before
his site was launched, according
to the article in The New Yorker.
-- Wired
Comments (3 posted)
New vulnerabilities
clamav: multiple vulnerabilities
| Package(s): | clamav |
CVE #(s): | CVE-2010-1639
CVE-2010-1640
|
| Created: | May 27, 2010 |
Updated: | March 14, 2011 |
| Description: |
From the Mandriva advisory:
The cli_pdf function in libclamav/pdf.c in ClamAV before 0.96.1 allows
remote attackers to cause a denial of service (crash) via a malformed
PDF file, related to an inconsistency in the calculated stream length
and the real stream length (CVE-2010-1639).
Off-by-one error in the parseicon function in libclamav/pe_icons.c
in ClamAV 0.96 allows remote attackers to cause a denial of service
(crash) via a crafted PE icon that triggers an out-of-bounds read,
related to improper rounding during scaling (CVE-2010-1640).
|
| Alerts: |
|
Comments (none posted)
kdenetwork: arbitrary code execution
| Package(s): | kdeaccessibility |
CVE #(s): | CVE-2010-1511
|
| Created: | May 27, 2010 |
Updated: | April 21, 2011 |
| Description: |
From the KDE advisory:
In some versions of KGet (2.4.2) a dialog box is displayed allowing the
user to choose the file to download out of the options offered by the
metalink file. However, KGet will simply go ahead and start the download
after some time - even without prior acknowledgment of the user, and
overwriting already-existing files of the same name. (CVE-2010-1511)
|
| Alerts: |
|
Comments (2 posted)
kernel: unexpected file access in btrfs
| Package(s): | kernel |
CVE #(s): | CVE-2010-1636
|
| Created: | May 31, 2010 |
Updated: | September 23, 2010 |
| Description: |
From the Red Hat bugzilla:
The existing [btrfs] code would have allowed you to clone a file that was only open for writing. Not an expected behaviour.
|
| Alerts: |
|
Comments (none posted)
perl-POE-Component-IRC: arbitrary IRC command execution
| Package(s): | perl-POE-Component-IRC |
CVE #(s): | |
| Created: | May 31, 2010 |
Updated: | June 2, 2010 |
| Description: |
From the Red
Hat bugzilla:
A vulnerability was reported to Debian for POE::Component::IRC, where it
did not remove carriage returns and line feeds. This affects tools or IRC bots
using the perl module, and can be used to execute arbitrary IRC commands by
passing an argument such as "some text\rQUIT" to the 'privmsg' handler, which
would cause the client to disconnect from the server. |
| Alerts: |
|
Comments (none posted)
rhn-client-tools: privilege escalation
| Package(s): | rhn-client-tools |
CVE #(s): | CVE-2010-1439
|
| Created: | June 2, 2010 |
Updated: | June 2, 2010 |
| Description: |
The rhn-client-tools utilities fail to set secure permissions on the loginAugh.pkl file, allowing local users to manipulate it. The result can be unwanted package downloads or the manipulation of action lists associated with the system's profile. |
| Alerts: |
|
Comments (none posted)
transmission: denial of service
| Package(s): | transmission |
CVE #(s): | CVE-2010-1853
|
| Created: | June 1, 2010 |
Updated: | June 2, 2010 |
| Description: |
From the Gentoo advisory:
Multiple stack-based buffer overflows in the tr_magnetParse() function
in libtransmission/magnet.c have been discovered.
A remote attacker could cause a Denial of Service or possibly execute
arbitrary code via a crafted magnet URL with a large number of tr or ws
links.
|
| Alerts: |
|
Comments (none posted)
Page editor: Jake Edge
Next page: Kernel development>>