Two interesting points:
1. " To make it a little
> more secure, add an ip address check along with the seed file and
> id/password."
In today's world of "super-proxies" (AOL) and super-short-life dhcp
leases, there is no guarantee that a user will come from the same IP
address during a session. An error (or even a warning) here will confuse
most users, and 99% of the time, there's nothing they can do about it
anyway.
2. " Add the mac address to the file. When the
> user connects, run a local java script to get the mac address of the
pc
> and send it back. Compare the mac address to one you have on file."
MAC addresses are easily spoofable by any script-kiddie, and javascript
does not allow direct access to the mac address. Even Java doesn't
support this (but can through an external call).
I also believe that home-grown security solutions are probably fatally
flawed 95% of the time. You have to think about things like MITM attacks
(even with SSL), weak passwords, process debugging (via SoftICE), memory
scans, and offline attacks. Unless you are a security expert and are
willing to take on these challenges, or unless this is a
politically-centered decision, I would stay away from brewing something
like this yourself.
Regards,
Michael Scovetta
Computer Associates
Senior Application Developer
tel: +1 631 342 3139
cell: +1 813 727 5772
michael.scovetta_at_ca.com
> -----Original Message-----
> From: Levenglick, Jeff [mailto:JLevenglick_at_fhlbatl.com]
> Sent: Friday, July 02, 2004 8:46 AM
> To: Michael Silk; Ivan Krstic; webappsec_at_securityfocus.com
> Subject: RE: Token authentication with web applications
>
> Ivan,
>
> You are correct that token solutions can be expensive. But.. in some
> sorts, you get what you pay for. What type of web app are you
> looking to protect?
>
> Some solutions that are out there:
>
> 1) RSA Cleartrust or Netegrity Siteminder. Not a token system, but can
be
> integrated with
> one. Can protect web apps or application server apps. (java...ect) You
> setup a user id/password
> and assign rights.
>
> 2) RSA Keon or other CA software. Be your own CA and issue certs to
your
> users. Set your web server
> up to only trust/use those certs. Set acl's/filters to only accept
your
> certs.
>
> 3) If your going to program your own system. You might find it to be
as
> expensive as just buying
> tokens...ect. But... You could try some simple things:
>
> 1) Install a password encrypted, hidden file to their hard disk.
> 2) Everytime they connect to you, get that file. Un-encrypt it and
read
> the sead number in it. Then,
> if it matches a seed number assigned to that user, change the number
and
> send it back. (encrypt the file again)
>
> This would be semi-safe because if someone did find and take the file,
> they would have a hard time trying
> to decrypt the file to get the seed. Plus, they would need the user
name
> and password to get in. To make it a little
> more secure, add an ip address check along with the seed file and
> id/password.
>
> <<just popped into my head>> Add the mac address to the file. When the
> user connects, run a local java script to get the mac address of the
pc
> and send it back. Compare the mac address to one you have on file.
>
>
> Jeffrey Levenglick
>
> -----Original Message-----
> From: Michael Silk [mailto:michaels_at_phg.com.au]
> Sent: Friday, July 02, 2004 02:25 AM
> To: Ivan Krstic; webappsec_at_securityfocus.com
> Subject: RE: Token authentication with web applications
>
>
> 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.
>
>
> -----------------------------------------
> This e-mail message is private and may contain confidential or
privileged
> information.
>
>
Received on Jul 04 2004
Intro
