Hi guys,
I'm sorry but, like our programmer, I don't get the SMS / hardware etc.
solutions - they are, by their very nature, exclusive - you would never get
all 8 million of BOA's online clients to adopt them, for example - and, in
addition, many of them are not international in nature - cell phone
solutions being typical
The only real solutions we can see are software based.
On the other hand, we would say that - we sell the software !
Graham Howe
VP of Marketing
www.dualshield.com
-----Original Message-----
From: sfdl01 [mailto:sfdl01_at_leach.net.au]
Sent: July 2, 2004 5:53 AM
To: Michael Silk
Cc: Ivan Krstic; webappsec_at_securityfocus.com
Subject: RE: Token authentication with web applications
Something I've seen come up on the odd occasion more recently is
out-of-band authentication using (in Europe and Asia) SMS to the users'
GSM phone. The SMS contains a onetime password that the user enters into
their web browser. The is typically after the user has entered in a
password that they know (to prevent a dos attack on the users' phone phone
:).
It is not what I would call real two factor authentication, but if you can
handle the overhead of an sms every time your users log in, then..?
Otherwise you could look at one of the more traditional token based
systems such as SecureID for a time based, or a DES calculator that
handles a challenge response type system.
Lastly, vendors have started knocking up small smartcard readers with a
pinpad (like a des calculator i guess, but the keys are on a smart card)
to handle smart card auth in situations where a pc might not have a
traditional card reader attached. i believe some of these devices sell
for <US$10, then you've got to personalise your chip card as well though.
> Hi,
> As far as I have found is that the secure systems will perform
> some computation on the card itself, the computation is such that
> it is secure (i.e. no private data leaves the card, and other
> such things)
>
> So, in your situation obviously the computer where the key is plugged
> into isn't considered secure; so computation can't be done there.
>
> Perhaps you could look into utilising the users' palm pilots? If they
> have them ...
>
> If not, well, the only solution is to use a system that can be
> copied (i.e. cd's, printouts, and so on) and accepting the risk.
>
> Potentially (and this is just a very rough suggestion) you could
> have a secure server and the users' computers can request a token
> from that. (i.e. try and emulate the computational card-based system
> utilising a server instead of the card).
>
> -- Michael
>
>
> -----Original Message-----
> From: Ivan Krstic [mailto:krstic_at_fas.harvard.edu]
> Sent: Friday, 2 July 2004 8:48 AM
> To: webappsec_at_securityfocus.com
> Subject: Token authentication with web applications
>
>
> All,
>
> I'm looking for people's experiences with cheap, uncomplicated token
> devices or other physical means of authentication that play nicely with
> more traditional authentication methods in web applications.
>
> The cheapest solutions that came to mind are printing credit-card sized
> s/key cards, or burning mini-CDs with a key and an auth agent for users.
> Obviously, both methods are flawed (s/key cards can be copied down if
> left exposed, and that's assuming they're not taped to the monitor,
> while a stolen CD can be copied and replaced without evidence of
> tampering[1]), but would still raise the security bar at essentially no
> cost. More extensive authentication solutions are usually rather
> expensive.
>
> Thoughts?
>
> Cheers,
> Ivan.
>
>
> [1] The s/key printed cards at least address this insofar as the user,
> presuming he can be bothered with remembering which of the 100 s/keys he
> used last, can notice that an intruder gained access to the system.
>
>
> This email message and accompanying data may contain information that is
> confidential and/or subject to legal privilege. If you are not the
> intended recipient, you are notified that any use, dissemination,
> distribution or copying of this message or data is prohibited. If you have
> received this email message in error, please notify us immediately and
> erase all copies of this message and attachments.
>
> This email is for your convenience only, you should not rely on any
> information contained herein for contractual or legal purposes. You should
> only rely on information and/or instructions in writing and on company
> letterhead signed by authorised persons.
>
>
Received on Jul 02 2004
Intro
