Isak <isak.hansen@gmail.com> 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/