RE: Username password VS hardware token plus PIN

[MHawkins () TULLIB COM]

Here's my problem:

Our user community is brokers. That doesn't mean that much to me but it
means a lot to executive management who like to coddle these people. If I
had my way, I would force brokers to act the same way that every other
employee in every other company I ever worked for behaved. That is, strong
passwords, learn the technology and deal !

However, management sees it differently. Yes yes, I can all hear you
already. I am not communicating effectively with management to get things
done right, blah blah blah. The reality is, brokers make a lot of money and
I am a cost center.

So, every single deployment simply has to be a simple and seamless to the
user as possible. I personally hate single sign on. I think it represents
security risk. But I also don't like non integrated security solutions.

Now, we use Active directory group policy to enforce access controls. It
works great in our inside environment. And our VPN clients also authenticate
via active directory. We have various ldap groups in FW-1 mapped to
different groups in Active directory. So when a user logs into the vpn they
get access to what our group policy dictates. This works extremely well by
pushing management of applications back to the desktop group. The firewalls
are preconfigured for the required applications/user mapping. Then it's up
to desktop to manage the group communities.

But now we have the problem of putting tokens into the mix which I would
like to do. But the current solutions would totally break our group policy.
Oh yeah, I can hear someone already telling me that I can deploy yet another
couple of boxes in our environment that will support tokens along with group
policy (well maybe not, I'd like to hear from someone who thinks they have a
solution that would integrate tokens/pins with active directory group
policy). But I hate to proliferate boxes for every fandangled solution that
comes along.

I just want to be able to have the user login using active directory
credentials and also provide a token. That would be the perfect scenario.

When users are at their desktop at the office they would do what they always
do - provide username/password. But when they wish to get access to apps via
the VPN they would provide their username/password and a hardware token.

Asking a broker to carry around a token is ok. But asking them to run this
and that and do this and do that is too much and it simply won't happen.

Mike Hawkins



-----Original Message-----
From: firewall-wizards-admin () honor icsalabs com
[mailto:firewall-wizards-admin () honor icsalabs com] On Behalf Of Frank Knobbe
Sent: Tuesday, February 22, 2005 12:39 PM
To: Hawkins, Michael
Cc: firewall-wizards () honor icsalabs com
Subject: Re: [fw-wiz] Username password VS hardware token plus PIN

On Tue, 2005-02-22 at 10:08 -0500, MHawkins () TULLIB COM wrote:
> What solutions are out there that do not use a PIN but use some
> username/password combination along with the hardware/software token?

Why would you need that?

In both cases you need a user name to identify the user.

In case of password-only, you just the password, something you know.

In case of token, you use the token (something you have), and the PIN
(something you know). The PIN is in a sense acting as the password.

Why would you need two passwords?


Another advantage that tokens have (but also other OTP schemes like OTP
calculators) is that the password/token-response is only valid once. If
someone intercepts the given token code during authentication, he should
not be able to use the same information again. Just like a
one-time-password created by an OTP calculator. 

The valid-only-once advantage is something a static username/password
can not provide.

Regards,
Frank



----------------------------------------------------------------------------
----------------------------------------------------------------------------
-------------------------
The information contained in this email is confidential and may also contain
privileged information. Sender does not waive confidentiality or legal
privilege. If you are not the intended recipient please notify the sender
immediately; you should not retain this message or disclose its content to
anyone.
Internet communications are not secure or error free and the sender does not
accept any liability for the content of the email. Although emails are
routinely screened for viruses, the sender does not accept responsibility
for any damage caused. Replies to this email may be monitored.
For more information about the Collins Stewart Tullett group of companies
please visit the following web site: www.cstplc.com
----------------------------------------------------------------------------
----------------------------------------------------------------------------
--------------------------

_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards