Re: [fw-wiz] Username password VS hardware token plus PIN
From: Kevin (kkadow_at_gmail.com)
Date: 02/22/05
- Previous message: Frank Knobbe: "Re: [fw-wiz] Username password VS hardware token plus PIN"
- In reply to: MHawkins_at_TULLIB.COM: "RE: [fw-wiz] Username password VS hardware token plus PIN"
- Next in thread: David Lang: "Re: [fw-wiz] Username password VS hardware token plus PIN"
- Reply: David Lang: "Re: [fw-wiz] Username password VS hardware token plus PIN"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
To: firewall-wizards@honor.icsalabs.com Date: Tue, 22 Feb 2005 12:24:02 -0600
On Tue, 22 Feb 2005 12:15:40 -0500, Mark Gumennik <mgumennik@mitre.org> wrote:
> Mike,
> I think the best you can get is SecureID/ACE (used to be AXENT, now RSA?)
> (Also quite expensive :-)
SecurID is unrelated to AXENT's product, totally different set of patents. For
some info on SecurID, please visit my totally unofficial SecurID User's forum:
http://groups.yahoo.com/group/securid-users/
I converted from the old X9.9/Axent challenge-response tokens after the
algorithm was shown to have major cryptographic weaknesses and
withdrawn by ANSI. The old school Axent tokens are no longer viable
for strong authentication; the newer response-only tokens from
Cryptocard and Secure Computing do not have the X9.9 flaws in their
standard algorithm, but can be programmed to use the flawed mode.
On Tue, 22 Feb 2005 12:03:47 -0500, MHawkins@tullib.com
<MHawkins@tullib.com> wrote:
> The RSA key you use, can you force regular PIN changes al la
> password policy style?
RSA doesn't offer this as a feature, there are add-ons which can provide
a password-expiration-style PIN change. Actually, the standard "new pin"
mode in the ACE/Server is a security risk, as anybody possessing a token
in this mode can set the PIN just using the tokencode -- one factor auth.
Another example would be where the user authenticates to a web site
via SSL. If I compromise the machine they are using with a keystroke
logger or MITM the session or copy the packets and brute force the
session key, even the longest password won't help.
> On the password brute forcing side of things. Surely locking the account on
> X failed attempts is good enough to stop brute forcing - right?
What about where the CHAP or IKE encrypted password is intercepted
and the hash is being brute-forced offline? With a token, all this will net
the attacker is the PIN and a worthless timed-out tokencode.
> If the security officer (yuk) gets an alert for locked accounts, that would
> help on forensics too. Right?
Actually, RSA's server will lock out token accounts when it sees certain
types of brute force attempts, but *DOES* *NOT* send alerts. I had to
manually hack together my own alerting mechanism.
> There are other advanatges for a very few people, like duress codes etc.
> Not all that relevant.
Another major advantage of tokens, is they deter account sharing and
prevent setting up clients (RAS, VPN, etc) with "saved" passwords.
Many organizations have policies that say users cannot share accounts,
and that you shouldn't share your password with anybody. Then you go
to audit a site or respond to an incident and find out that everybody was
using the team lead's password because his account was the only one
with full privileges, and now your audit trail is worthless...
Kevin Kadow
_______________________________________________
firewall-wizards mailing list
firewall-wizards@honor.icsalabs.com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
- Previous message: Frank Knobbe: "Re: [fw-wiz] Username password VS hardware token plus PIN"
- In reply to: MHawkins_at_TULLIB.COM: "RE: [fw-wiz] Username password VS hardware token plus PIN"
- Next in thread: David Lang: "Re: [fw-wiz] Username password VS hardware token plus PIN"
- Reply: David Lang: "Re: [fw-wiz] Username password VS hardware token plus PIN"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|