RE: Token authentication with web applications

[<stevenr () mastek com>]

Hi 

> > 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.

Though this does raise the bar a bit, its not really reliable to base
authentication on IP. Load balancing proxies will raise too many false
positives into your code. Also, reading MAC address using javascript,
you would be relying the client to give you authentication credentials,
which can be bypassed.

Regards, 
Steven Rebello 
"This email is printed using 100% recycled electrons." 


-----Original Message-----
From: Levenglick, Jeff [mailto:JLevenglick () fhlbatl com] 
Sent: Friday, July 02, 2004 6:16 PM
To: Michael Silk; Ivan Krstic; webappsec () 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 () phg com au]
Sent: Friday, July 02, 2004 02:25 AM
To: Ivan Krstic; webappsec () 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 () fas harvard edu]
Sent: Friday, 2 July 2004 8:48 AM
To: webappsec () 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.




MASTEK
"Making a valuable difference"
Mastek in NASSCOM's 'India Top 20' Software Service Exporters List.
In the US, we're called MAJESCO

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Opinions expressed in this e-mail are those of the individual and not that of Mastek Limited, unless specifically 
indicated to that effect. Mastek Limited does not accept any responsibility or liability for it. This e-mail and 
attachments (if any) transmitted with it are confidential and/or privileged and solely for the use of the intended 
person or entity to which it is addressed. Any review, re-transmission, dissemination or other use of or taking of any 
action in reliance upon this information by persons or entities other than the intended recipient is prohibited. This 
e-mail and its attachments have been scanned for the presence of computer viruses. It is the responsibility of the 
recipient to run the virus check on e-mails and attachments before opening them. If you have received this e-mail in 
error, kindly delete this e-mail from all computers.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~