Smartcard and non-password methods (was Re: Password repository)

Are any network providers supporting smartcards or other non-password based authentication methods? Passwords always end up blaming the user for choosing/not remembering good passwords instead of blaming the
technology for choosing/not doing things so the user isn't forced to
work around its flaws.

I know about the DOD Common Access Card. One-time code-generator tokens seem more widely used by single enterprises. But inter-operable credentials still seem to be one of those great unsolved problems for compter security. Are passwords still the only lowest-common-denominator?

Are passwords still the only lowest-common-denominator?

There's OpenID, where a provider can use any verification process it
wants, but all the OpenID providers I know use ordinary passwords.

R's,
John

John Levine wrote:

Are passwords still the only lowest-common-denominator?

There's OpenID, where a provider can use any verification process it
wants, but all the OpenID providers I know use ordinary passwords.

Yeah, and every ISP would probably use key authentication, except there's not a simple distribution method for the multitude of ways clients might connect and handling temporary issues such as a customer connecting from a public site via webmail.

So if a customer needs a password to retrieve or unlock a cert, they see no reason for a cert. This shows in the limited support for client certificates in standard software. Due to the limited support and increased overhead in supporting getting a client cert installed, they end up not being used.

The same could be said for other protocols, though. Kerberos rocks, even does good with M$ networks, but there is no click and have fun kerberos support that I've seen for ISP networks.

On the other hand, even with a very hands free implementation, I'm sure people would complain "but I want to let my son authenticate to this with my username/password, but not have access to this." Obviously, such a problem is best solved with "son" having his own auth, which may have different resources than the parent's, which is easily maintained and billable based on the resources actually required (see any number of Profile setups on fee based services; ie, netflix).

Jack (off topic, and annoyed with the way we do things today)

myvidoop.com does OpenID auth based on pictures. It's... interesting to
use.

- Matt

Sadly, passwords are the least common denominator. The biggest problems
with 2 factor devices (smart cards, OTPs, etc) is having to buy, configure,
and distribute them; plus get them to work with all the myriad of
applications.

Certificates that are issued to computers/web browsers suffer from a lack of
portability (i.e. by design, the user shouldn't be able to export and share
the certificate with anyone they want). Plus with any solution using
certificates (client or smart card) a substantial reconfiguration is
required to support websites/applications being able to process certificate
logons.

IMHO, even though OTPs are the less secure of the two types of two-factor
products, I see them growing faster than any other method. From an end-user
perspective, they are small/portable, don't require a reader, and don't
require any special OS, web browser, or software. For an infrastructure
perspective, it is easier to convert a website to support OTPs (simply
change the function that runs the password validation; instead of having to
install and configure a special module/component that would handle the
mutual auth required by certificates). Also, many of the OTP vendors are
working on making their products function more easily cross platform (while
with smart cards, you are basically stuck with either the Microsoft's
corporate/non-service provider friendly solution, or have to code your own).

My $0.02,
Adam Stasiniewicz

[Sightly off-topic - solution specific] Some European countries have
long figured out logistics of smartcard distribution and management in
their healthcare systems - some being at the second generation,
already.

In fact this is a subject "dear" to my heart, as I've researched and
attempted a proposal for such systems for a few disparate businesses
(with possible extension into eHR), based on a model similar to the
one of SSL certificates authority (i.e third party management of
authentication, with some very neat federated solution), but nobody
seems to care....

Moral? It's been done and it works. Good luck with selling such.

Stefan

I was pretty excited about this post until I found out that myvidoop
only works on older version of FF.

Jeff

I can only find something about the plugin not working on FF 3.5, but I
don't use the plugin since I only use it as an OpenID endpoint. I can't
imagine how the main site wouldn't work in FF 3.5 -- it's just a bit of
javascripty fluff.

- Matt

So it works as a standalone password vault also?

Jeff

I don't know. My only experience with it has been as an OpenID
endpoint/provider/whatever, and it was on that basis that I replied
originally.

- Matt

http://yubico.com/developers/openid/

I'm currently trialing Yubico's for access to a number of Unix systems (via
PAM), and they seem to work very well. Haven't played around with the
OpenID support, so I can't comment on if/how well it works.

  Scott.

is there a freebsd pam tacacs+ hack?

randy

cards and tokens are a proxy for the use of a certificate authentication
system...

You can in fact do certificate auth without the use of cards or tokens
or mix and match physical tokens and other private key storage depending
on need with the same authentication backend (typically ldap).

Since this plays nicely with eap-tls, 802.1x. ike, ssl/tls, and s/mime
it seems like a shoe-in, once you have a uniform authentication system
one is inclined to use it for everything. obviously being involved in
several of these with with multiple ca's is something of a pain in the
ass if it involves juggling 2 or more tokens instead of passwords.
(which are already a problem if you have to trach quite a few
non-overlapping ones.

Typically tokens continue to require passwords or some other method to
unlock them for use, effectively making them two factor (secret+physical
possession)

Sean Donelan wrote:

Yep, there are lots of potential technologies out there. I've also implemented several on your list. I'm trying to stay neutral about the
technology, as long as it works. I suppose my question was more about market share/mind share. Figure out where everyone else is already go, and then get in front of that :-).

So where is the market going beyond passwords?

> Are passwords still the only lowest-common-denominator?

There's OpenID, where a provider can use any verification process it
wants, but all the OpenID providers I know use ordinary passwords.

http://yubico.com/developers/openid/

I'm currently trialing Yubico's for access to a number of Unix systems (via
PAM), and they seem to work very well. Haven't played around with the

+1 for yubico's simplicity to setup/use. They also support a 'run your
own auth server' model, so if you've got a closed system you don't
have to find a way to sneak out http/s links to yubico-land.

OpenID support, so I can't comment on if/how well it works.

I have not used their openid support either... but it looks promising.

-Chris

If memory serves me right, Randy Bush wrote:

is there a freebsd pam tacacs+ hack?

Yep. Haven't actually used it though.

PAM_TACPLUS(8) FreeBSD System Manager's Manual
PAM_TACPLUS(8)

NAME
     pam_tacplus -- TACACS+ authentication PAM module

Bruce.