|
Posted by Isak on October 23, 2007, 9:04 am
If you were Registered and logged in, you could reply and use other advanced thread options
On Oct 20, 6:02 am, comph...@toddh.net (Todd H.) wrote:
> > 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/
| 
XML site map