Value of SSL client certificates?

I'm looking for input on authentication mechanisms for a financial
service.

We don't think that username+password login across a https connection
sounds secure enough by itself, and are looking for ways to increase
security.

One-time passwords over e.g. SMS as a second step after successful
login sounds very good, but we have concerns about the associated
costs.

Client side certificates were brought up as a cheaper option. It's one
more technical hurdle for our users, but if they make up for it in
security, and we save more than our support cost goes up, I guess they
could be worth it.

A client cert does prevent brute-forcing random accounts; you'd have
to gain access to the certificate first. And if you do gain access to
a certificate, intercepting a one-time password as it's being
submitted probably isn't a lot harder..


Thoughts? Any suggestions appreciated,
Isak

Re: Value of SSL client certificates?

Client certs seem like an effective way to authenticate the
browser. One thing that's nice about them is that hopefully
they are not as susceptible to phishing: the user cannot disclose
a credential that the user does not know (e.g., the private key).

I've always heard concerns raised about (a) browser support for
client certs, and (b) help desk calls. I'd be curious to hear
your views on whether those concerns are still relevant today.

Also one issue with client certs is that they only authenticate
the machine or the browser. If the user uses a different machine
to log in, that other machine won't have their client cert, so
they will have to "register" that other machine (by generating a
new client cert for that machine). Same if they re-install the
OS or possibly even if they change browsers. One question is,
how cheap and easy can you make that? Another question is, is
that acceptable?

I'd be interested to hear your take on these concerns. If client
certs are practically feasible, it seems to me like they have some
good security properties -- but I don't know enough about the
practicalities of using them.

You might also want to ask on Perry Metzger's cryptography mailing
list.

Re: Value of SSL client certificates?

Isak writes:
> I'm looking for input on authentication mechanisms for a financial
> service.

Who are the users? How many of em are there?

> We don't think that username+password login across a https connection
> sounds secure enough by itself, and are looking for ways to increase
> security.

Specifically what threats are you looking to counter?

> One-time passwords over e.g. SMS as a second step after successful
> login sounds very good, but we have concerns about the associated
> costs.

Novel idea. SMS as in texting a message to the client's cell phone
with a one time password? Do all the users have cell phones? Can SMS
delivery be reliable and timely enough for a user waiting to log in?
Not likely.

> Client side certificates were brought up as a cheaper option. It's one
> more technical hurdle for our users, but if they make up for it in
> security, and we save more than our support cost goes up, I guess they
> could be worth it.

If your clients are users in the general public, I see HUGE support
costs here in addition to the cert cost.


> A client cert does prevent brute-forcing random accounts; you'd have
> to gain access to the certificate first. And if you do gain access to
> a certificate, intercepting a one-time password as it's being
> submitted probably isn't a lot harder..
>
>
> Thoughts? Any suggestions appreciated,


Some banks are issuing secureid tokens (or the like) these days.


Alternatively, a credit union I recently worked with has migrated to a
login auth system that first prompts for account number. It auths
that against known accounts, and looks at the source IP. If the user
has logged in from that IP before, they are prompted for their
password, on a page showing a user-selected pictures and a phrase.

If the user is logging in from a new IP for the first time, instead of
a password prompt, they are prompted to answer one of 5 security
questions they've selected and answered during account setup. Upon
successful answering, their new IP is registered, and they are given a
password prompt.

This approach seems to be a decent balance of security vs usability.
It does also seem to protect against phishing for the client who will
be lookin for their familiar picture and phrase they selected. It
also thwarts password attacks because to even get to the password
prompt, the correct answer to a randomly selected out of 5 question
needs to be provided, which greatly increases the complexity of any
scripted attack.

If a client is infected with malware, you've still got problems. And
there will be more calls to your helpdesk, but it is lower cost of
entry than issuing every customer a token they need to figure out and
your infrastructure needs to support.

Best Regards,
--
Todd H.
http://www.toddh.net/

Re: Value of SSL client certificates?

On Oct 19, 10:18 pm, Isak wrote:
> I'm looking for input on authentication mechanisms for a financial
> service.
>
> We don't think that username+password login across a https connection
> sounds secure enough by itself, and are looking for ways to increase
> security.

For practicality, username+password is considerable. We just need to
add some verification mechanism, such as token card, ekey, etc.

> One-time passwords over e.g. SMS as a second step after successful
> login sounds very good, but we have concerns about the associated
> costs.

Nowadays, copy a sim card is very easy. The idea that use sim for
authorization is not comfortable in some restrict applications.

> Client side certificates were brought up as a cheaper option. It's one
> more technical hurdle for our users, but if they make up for it in
> security, and we save more than our support cost goes up, I guess they
> could be worth it.

Client certification only provides the authentication of the used
public key, for authorization, there are still many works need to be
done. E.g., we can use this public key to exchange session key in
Diffie-Hellman protocol.

> A client cert does prevent brute-forcing random accounts; you'd have
> to gain access to the certificate first. And if you do gain access to
> a certificate, intercepting a one-time password as it's being
> submitted probably isn't a lot harder..
>
> Thoughts? Any suggestions appreciated,
> Isak

Re: Value of SSL client certificates?

On Oct 19, 7:25 pm, d...@taverner.cs.berkeley.edu (David Wagner)
wrote:
> Client certs seem like an effective way to authenticate the
> browser. One thing that's nice about them is that hopefully
> they are not as susceptible to phishing: the user cannot disclose
> a credential that the user does not know (e.g., the private key).
>

We'd have to automate the cert generation process, using some stronger
form of authentication (one-time passwords / SMS), which would again
make us susceptible to phishing. Protecting people from themselves is
hard.


> I've always heard concerns raised about (a) browser support for
> client certs, and (b) help desk calls. I'd be curious to hear
> your views on whether those concerns are still relevant today.
>

I assume (a) is "solved" these days. I've seen mention of issues with
key sizes larger then 1kbit, but not sure how recent that was.

I think (b) is still a major issue, no matter how streamlined and
simple we/the browser developers make the process..


> Also one issue with client certs is that they only authenticate
> the machine or the browser. If the user uses a different machine
> to log in, that other machine won't have their client cert, so
> they will have to "register" that other machine (by generating a
> new client cert for that machine). Same if they re-install the
> OS or possibly even if they change browsers. One question is,
> how cheap and easy can you make that? Another question is, is
> that acceptable?
>

Yup, that's the question. As we'll need some additional auth mechanism
for cert generation, I'm not sure what we could gain.

As far as I can see, it all boils down to cost / complexity of sending
out more text messages vs. cost / increased complexity of doing both
sms & client certs.


Regards,
Isak

> I'd be interested to hear your take on these concerns. If client
> certs are practically feasible, it seems to me like they have some
> good security properties -- but I don't know enough about the
> practicalities of using them.
>
> You might also want to ask on Perry Metzger's cryptography mailing
> list.

Re: Value of SSL client certificates?

On Oct 20, 6:02 am, comph...@toddh.net (Todd H.) wrote:
> Isak writes:
> > I'm looking for input on authentication mechanisms for a financial
> > service.
>
> Who are the users? How many of em are there?
>

General public. Thousands to tens of thousands if things pan out.


> > We don't think that username+password login across a https connection
> > sounds secure enough by itself, and are looking for ways to increase
> > security.
>
> Specifically what threats are you looking to counter?
>

I guess distributed brute forcing / dict attacs are the main threats
we can do something against..?


> > One-time passwords over e.g. SMS as a second step after successful
> > login sounds very good, but we have concerns about the associated
> > costs.
>
> Novel idea. SMS as in texting a message to the client's cell phone
> with a one time password? Do all the users have cell phones? Can SMS
> delivery be reliable and timely enough for a user waiting to log in?
> Not likely.
>

It's actually a fairly common scheme around here. Pretty much anyone
has a cellphone, and if we exclude those w/o internet access, I'm sure
cell coverage is pretty much 100%.


> > Client side certificates were brought up as a cheaper option. It's one
> > more technical hurdle for our users, but if they make up for it in
> > security, and we save more than our support cost goes up, I guess they
> > could be worth it.
>
> If your clients are users in the general public, I see HUGE support
> costs here in addition to the cert cost.
>
> > A client cert does prevent brute-forcing random accounts; you'd have
> > to gain access to the certificate first. And if you do gain access to
> > a certificate, intercepting a one-time password as it's being
> > submitted probably isn't a lot harder..
>
> > Thoughts? Any suggestions appreciated,
>
> Some banks are issuing secureid tokens (or the like) these days.
>
> Alternatively, a credit union I recently worked with has migrated to a
> login auth system that first prompts for account number. It auths
> that against known accounts, and looks at the source IP. If the user
> has logged in from that IP before, they are prompted for their
> password, on a page showing a user-selected pictures and a phrase.
>
> If the user is logging in from a new IP for the first time, instead of
> a password prompt, they are prompted to answer one of 5 security
> questions they've selected and answered during account setup. Upon
> successful answering, their new IP is registered, and they are given a
> password prompt.
>
> This approach seems to be a decent balance of security vs usability.
> It does also seem to protect against phishing for the client who will
> be lookin for their familiar picture and phrase they selected. It
> also thwarts password attacks because to even get to the password
> prompt, the correct answer to a randomly selected out of 5 question
> needs to be provided, which greatly increases the complexity of any
> scripted attack.
>

Whitelisting by IP sounds like an interesting option for limiting the
use of one-time passwords.


Thank you,
Isak

> If a client is infected with malware, you've still got problems. And
> there will be more calls to your helpdesk, but it is lower cost of
> entry than issuing every customer a token they need to figure out and
> your infrastructure needs to support.
>
> Best Regards,
> --
> Todd H.http://www.toddh.net/

Re: Value of SSL client certificates?

Isak wrote:
>We'd have to automate the cert generation process, using some stronger
>form of authentication (one-time passwords / SMS), which would again
>make us susceptible to phishing. Protecting people from themselves is
>hard.

? I thought web browsers had the capability to generate the
private/public keypair on the client side. I would think that
would be preferable to having the server generate the user's
private key for them. That's all you need, isn't it?

Perhaps what you mean is that you need a way for users to register
their public key. There are many ways you could potentially do that.
You could do whatever you do today if a user claims to have forgotten
their password. You could ask them a few challenge questions. You could
have them call a telephone number with automated voice response system.
You could snail-mail or text them a one-use password. You're absolutely
right that the bootstrap problem is a challenge. But: How do you handle
the bootstrap problem today? That might give you some ideas about how
you could solve the bootstrap problem, as the bootstrap problem is not
unique to public-key authentication.

>> I've always heard concerns raised about (a) browser support for
>> client certs, and (b) help desk calls. I'd be curious to hear
>> your views on whether those concerns are still relevant today.
>
>I assume (a) is "solved" these days. I've seen mention of issues with
>key sizes larger then 1kbit, but not sure how recent that was.
>
>I think (b) is still a major issue, no matter how streamlined and
>simple we/the browser developers make the process..

Okay.

Re: Value of SSL client certificates?

Isak writes:
> I'm looking for input on authentication mechanisms for a financial
> service. ... [other post:] general public, 10,000's of users.
> Thoughts? Any suggestions appreciated,

You really want hardware authentication tokens like Paypal is now using.

https://www.paypal.com/securitykey

Re: Value of SSL client certificates?

Paul Rubin wrote:
>You really want hardware authentication tokens like Paypal is now using.
>https://www.paypal.com/securitykey

How does this defend against man-in-the-middle phishing attacks?
(I'm talking about attacks where the attacker presents a spoofed
web site, and acts as a man-in-the-middle relaying challenges and
responses between the victim and the legitimate website.)

See also:
http://www.schneier.com/blog/archives/2005/03/the_failure_of .html

Re: Value of SSL client certificates?

On Oct 23, 5:59 pm, d...@taverner.cs.berkeley.edu (David Wagner)
wrote:
> Isak wrote:
> >We'd have to automate the cert generation process, using some stronger
> >form of authentication (one-time passwords / SMS), which would again
> >make us susceptible to phishing. Protecting people from themselves is
> >hard.
>
> ? I thought web browsers had the capability to generate the
> private/public keypair on the client side. I would think that
> would be preferable to having the server generate the user's
> private key for them. That's all you need, isn't it?
>
> Perhaps what you mean is that you need a way for users to register
> their public key.

Yes. The user would create a key pair and hand us their public key,
which we sign or whatever to issue a client certificate.


> >> I've always heard concerns raised about (a) browser support for
> >> client certs, and (b) help desk calls. I'd be curious to hear
> >> your views on whether those concerns are still relevant today.
>
> >I assume (a) is "solved" these days. I've seen mention of issues with
> >key sizes larger then 1kbit, but not sure how recent that was.
>
> >I think (b) is still a major issue, no matter how streamlined and
> >simple we/the browser developers make the process..
>
> Okay.

We haven't done any real research on this, though. Would be
interesting to see some real data if there's anything out there.


Regards,
Isak

Re: Value of SSL client certificates?

On Oct 19, 9:18 am, Isak wrote:
> I'm looking for input on authentication mechanisms for a financial
> service.
>
> We don't think that username+password login across a https connection
> sounds secure enough by itself, and are looking for ways to increase
> security.
>
> One-time passwords over e.g. SMS as a second step after successful
> login sounds very good, but we have concerns about the associated
> costs.
>
> Client side certificates were brought up as a cheaper option. It's one
> more technical hurdle for our users, but if they make up for it in
> security, and we save more than our support cost goes up, I guess they
> could be worth it.
>
> A client cert does prevent brute-forcing random accounts; you'd have
> to gain access to the certificate first. And if you do gain access to
> a certificate, intercepting a one-time password as it's being
> submitted probably isn't a lot harder..
>
> Thoughts? Any suggestions appreciated,
> Isak

We've come up with an interesting new approach for 2-factor that is
cheap/free and is not as easily man-in-the-middle attackable as
"token" solutions. It's called PhoneFactor and it is different than
the SMS solutions you mentioned before. Basically, it includes a call
to a phone and a verification either using # or a PIN number for a
little bit more security. You should at least take a look, at
www.phonefactor.net.

Anthony Maughan
Systems Engineer, MSCE + Security
Positive Networks

Re: Value of SSL client certificates?

daw@taverner.cs.berkeley.edu (David Wagner) writes:
> >You really want hardware authentication tokens like Paypal is now using.
> >https://www.paypal.com/securitykey
>
> How does this defend against man-in-the-middle phishing attacks?
> (I'm talking about attacks where the attacker presents a spoofed
> web site, and acts as a man-in-the-middle relaying challenges and
> responses between the victim and the legitimate website.)

Fair enough--I may have missed or forgotten some of the earlier
discussin in the sporge flood. I have to say I don't think client
certs help with that so much either. Authentication tokens do, at
least, stop the phisher from capturing the user's credential
(i.e. password) and re-using it later, in the case where the attacker
gets control of the client computer and compromises the key store.

Re: Value of SSL client certificates?

Paul Rubin wrote:
>I have to say I don't think client
>certs help with [man-in-the-middle phishing attacks] so much either.

Can you elaborate? If the bank's web server uses SSL and knows the
public key of each of their account holders, then I would have thought
that would defeat MITM attacks.

>Authentication tokens do, at
>least, stop the phisher from capturing the user's credential
>(i.e. password) and re-using it later, in the case where the attacker
>gets control of the client computer and compromises the key store.

Yup.

Re: Value of SSL client certificates?

daw@taverner.cs.berkeley.edu (David Wagner) writes:
> >I have to say I don't think client
> >certs help with [man-in-the-middle phishing attacks] so much either.
>
> Can you elaborate? If the bank's web server uses SSL and knows the
> public key of each of their account holders, then I would have thought
> that would defeat MITM attacks.

Oh yes, that would do it, I guess. Typically in SSL one just checks
the validity of the signature on a certificate. That means the
attacker could present a legitimate client certificate (from an
illicit or hijacked account) to the server while opening a session
logging in under the phished account. Using the certificate serial
number to identify the account (assuming one trusts the CA to keep
them unique) is one obvious fix that avoids messing with the actual
public keys. I guess one should always do this.

Re: Value of SSL client certificates?

daw@taverner.cs.berkeley.edu (David Wagner) writes:
> Can you elaborate? If the bank's web server uses SSL and knows the
> public key of each of their account holders, then I would have thought
> that would defeat MITM attacks.

we claimed that in x9.59 financial standard we eliminated the
requirement to encrypt the transmission.

we had been called in to consult with this small client/server
startup that wanted to do payment transactions on their server
http://www.garlic.com/~lynn/subnetwork.html#gateway

they had this technology they called SSL they had invented and they
wanted to use it in conjunction with the payment transactions. They had
the SSL domain name certificates as part of webserver authentication
.... but for payment transactions we had to enhance it with mutual
authentication ... for interaction between the webserver and the payment
gateway. we also had to do detailed end-to-end business process analysis
of the while operation ... including this things that were starting to
call themselves certification authorities.

recent postings on the subject in some other threads
http://www.garlic.com/~lynn/2007q.html#30
http://www.garlic.com/~lynn/aadsm27.htm#62

afterwards we got involved in the x9a10 financial standards working
group that had been given the requirement to preserve the integrity of
the financial infrastructure for all retail payments. As part of that
effort we eventually did a much detailed vulnerability and threat model
study (including analysing exactly what benefits did the digital
certificates provide in the previous effort related to SSL ... which is
now frequently referred to as electronic commerce).

x9a10 effort resulted in the x9.59 payment standard that required every
transaction to be authenticated.
http://www.garlic.com/~lynn/x959.html#x959

In the x9.59 standards document, it shows how this can be done with
ec/dsa digital signature on every transaction and validated with a
public key on file with the authorizing financial instituation (w/o
requiring any digital certificate, the on-file public key making digital
certificates redundant and superfluous).

part of the detailed vulnerability study found that there were actually
much larger exploits of the transaction logs stored at various end
points (and required for quite a few backroom business processes related
to payment transactions) than were ever happening with evesdropping on
transmitted transactions. so part of x9.59 financial standard (as part
of the requirements given the x9a10 financial standard working group to
preserve the integrity of the financial infrastructure for all retail
payments) ... was to eliminate all the exploits ... not just the replay
attacks from evesdropping attacks ... but also replay attacks resulting
from harvesting things like transaction logs. the other issue was there
have been studies that something upwards of 70percent of account fraud
involves insiders (who have valid, required access to the information).

so part of the solution in x9.59 financial standard was to make
evesdropping and/or havesting of previous transaction useless for
performing fraudulent transactions ... i.e. even if attackers obtained
the information (regardless of the means), it wouldn't be useful for
doing things like various kinds of replay attacks or other fraudulent
transactions. x9.59 didn't do anything about preventing unauthorized
access to the information ... it just made it so that whatever kind of
access there was ... the information couldn't be used by crooks to
perform fraudulent transactions.

as part of the mutual authentication work for the original SSL, we came
to realize that the digital certificates were redundent and superfluous
(setting up long live encrypted sessions between the webservers and the
payment gateway) ... because they both had to have registered
information (including public key) of the entities that they were
dealing with.

this was further highlighted when x9a10 working group looked as some of
the other payment efforts going on at the same time that were oriented
towards including digital certificates as part of a public key and
digital signature operation.

one of the issues was that x.509 identity digital certificates from
the early 90s were starting to become overloaded with personal
information. by the mid-90s, numerous institutions had started to
realize this represented significant liability and privacy problems
.... and had regressed to something they called relying-party-only
certificates
http://www.garlic.com/~lynn/subpubkey.html#rpo

these involved only including some sort of account number and/or other
kind of database record locator (say userid) in the digital certificate
.... and all the required information was onfile (and not being
repeatedly sprayed all over the world in digital certificates). However,
it is trivial to show that part of registration process that preceeds
generating the digital certificate, the person's public key is also
place on-file. As a result, it is then trivial to demonstrate that the
digital certificate becomes redundant and superfluous.

The other part ... at least as far as payment transactions were
concerned ... for even the reduced "relying-party-only" digital
certificate processing (i.e. appending digital certificates
to typical payment transaction) ... increased the payload (and
typical processing) overhead by two orders of magnitude
http://www.garlic.com/~lynn/subpubkey.html#bloat

not only were the digital certificates redundant and superfluous ... but
in the typical payment transaction operation, they represented a
100-fold increase in payload and processing overhead.

the x9 financial standards group did make some effort to look at the
(redundant and superfluous) digital certificate enormous payload bloat
in payment transactons with a standard project for compressed digital
certificates (possible objective of reducing the enormous payload bloat
from 100 times to possibly only 3-10 times).

one of the suggestions for compressed digital certificates was to
eliminate all fields that were the same across all the digital
certificates. my suggestions was doing information compression ...
i.e. eliminate all fields that were already on-file with issuing
relying-party. I was then able to show that all fields would be
already on-file and therefor all fields could be eliminated. Rather
than having a certificateless infrastructure
http://www.garlic.com/~lynn/subpubkey.html#certless

there would be a transition to issuing zero-byte digital certificates
.... and that all transactions would always have zero-byte digital
certificates appended.

i.e. the redundant and superfluous nature of the digital certificates
were futher reinforced (at least in payment transactions) by their
enormous (two orders of magnitude) payload and processing bloat.

Re: Value of SSL client certificates?

Paul Rubin writes:
> Oh yes, that would do it, I guess. Typically in SSL one just checks
> the validity of the signature on a certificate. That means the
> attacker could present a legitimate client certificate (from an
> illicit or hijacked account) to the server while opening a session
> logging in under the phished account. Using the certificate serial
> number to identify the account (assuming one trusts the CA to keep
> them unique) is one obvious fix that avoids messing with the actual
> public keys. I guess one should always do this.

re:
http://www.garlic.com/~lynn/2007q.html#72 Value of SSL client certificates?

.... see the "yes card" scenario ... where they refer to "static data"
authentication ... basically the digital certificate w/o the individual
digital signature (which has been referred to as "active data")
http://www.garlic.com/~lynn/subintegrity.html#yescard

some of this (again) is related to the enormous processing and payload
bloat associated with digital certificates (at least in the payment
transaction scenario)

part of the issue is whether there is session level authentication
.... but actual transactions still remain vulnerable (potentially
requiring enormous amounts of encryption and other security mesures to
try and hide the vulnerable transactions)... discussed in these postings
on the "naked transaction" metaphor
http://www.garlic.com/~lynn/subintegrity.html#payment