Re: [fw-wiz] Username password VS hardware token plus PIN

From: Paul D. Robertson (paul_at_compuwar.net)
Date: 02/24/05

  • Next message: John Hall: "Re: [fw-wiz] Username password VS hardware token plus PIN"
    To: Kevin Sheldrake <kev@electriccat.co.uk>
    Date: Thu, 24 Feb 2005 08:19:42 -0500 (EST)
    
    

    On Wed, 23 Feb 2005, Kevin Sheldrake wrote:

    > to current systems where it is. I don't know if this is how any token
    > systems work; I just thought I'd chuck it in.

    That would require a client at the entry point- not usually what folks
    want to deploy.

    > The main reason for the post is because I have a problem with PINs that
    > unlock tokens (or smart cards for that matter) in order for some
    > credential from the token to be used for authentication (in isolation of
    > the original, or any other, PIN or password). While I appreciate that the
    > user requires "something he knows" (to unlock the token) and "something he
    > has" (the token) in order to log in, I disagree that an attacker would
    > necessarily require both.

    That's implementation-dependent.

    > Imagine a token (smartcard, PDA, smart phone, whatever) that usually
    > operates in this fashion, but can be made to reveal its workings after it
    > has been successful attacked. In this situation, it would be possible for
    > the attacker to steal the "something he has" and produce valid
    > credentials. In the case where the "something he knows" is transmitted to
    > the server (or combined with the OTP and hashed locally) this would not be
    > possible.

    Again, implementation dependent- SecureID seems to have done well in 3rd
    party reviews, I know Opie had issues at some point- but evaluation is
    everything.

    > BTW, the "something you are" (biometrics) always makes me chuckle. Using
    > fingerprints for authentication is like writing your password on every
    > surface you touch. It doesn't take much imagination to conceive of
    > devices that could scan faces, the iris, the retina, etc, yet appear
    > innocuous. It all depends how much you want the credentials.

    It's better than that... Denial of Service attacks are now perpetrated by
    Guido the DoS expert with a bat. Worse-yet, if an attacker believes that
    the biometric alone will allow access, stealing just that part (iris,
    finger, head) becomes attractive to them under some circumstances- and it
    doesn't matter much to the user if the attacker can't authenticate with
    the associated part- the attacker just has to believe that Demolition Man
    was true for it to be really bad for the user.

    I dislike the failure modes on biometrics because of this.

    "Ok, so we need to stop the firewall admin from logging in while we
    attack, they use iris scanners don't they?" becomes a bit unsettling...

    > Of course, specific biometric implementations do not need to fall foul of
    > this vulnerability; when we (the industry) get past the hype and debate
    > actual architectures, we might come up with something usable and secure. :)

    The implementation doesn't matter if the attacker set believes that they
    can breach the system. For instance, if a rumor starts that iris scanners
    in ATMs open up if you pop out an eyeball and hold it on the end of a pen,
    there will be a bunch of one-eyed victims running around _even if the
    premise is untrue_.

    I prefer tokens and passphrases to biometrics, attacking the token or
    passphrase doesn't have to involve my fingers or eyeballs.

    Paul
    -----------------------------------------------------------------------------
    Paul D. Robertson "My statements in this message are personal opinions
    paul@compuwar.net which may have no basis whatsoever in fact."
    _______________________________________________
    firewall-wizards mailing list
    firewall-wizards@honor.icsalabs.com
    http://honor.icsalabs.com/mailman/listinfo/firewall-wizards


  • Next message: John Hall: "Re: [fw-wiz] Username password VS hardware token plus PIN"

    Relevant Pages

    • Re: username and Password sent as clear text strings
      ... that is unfortunately only security though obscurity, ... A lot depends on what you are doing at this point, the value of the host to the attacker, and the attack modes. ... The downsides there are the inevitable turnover (loss, failure or expiry of tokens), the fact that a physical token will often be left with or near the user's customary access point vulnerable to abuse or theft given physical proximity, and the perceived security of the token being so high that often social engineering or MitM fake-failure attacks can achieve entry of a token value under the control of the attacker without arousing the suspicion of the user. ... Unless logins in parallel are to be prevented, often a single token value can be used in parallel attempts a second login with the same token value. ...
      (Pen-Test)
    • Re: Passwords: length vs. complexity
      ... number of characters in it, but by the number of tokens. ... character passphrase consists of 7 words, ... Always consider an attacker with inside knowledge. ...
      (Security-Basics)
    • Re: Rolling codes and vehicle locks
      ... What you state below is essentially how one form of event-synchronous tokens ... if they were successive codes, ... While the risk would be slim with a keyfob, with a token used for network ... attacker having to crack crypto, or keylog the token, then hijack the session. ...
      (comp.arch.embedded)
    • Re: [fw-wiz] Username password VS hardware token plus PIN
      ... I preferred tokens that require the PIN to unlock the token, ... > but never transmit the PIN. ... has" in order to log in, I disagree that an attacker would ...
      (Firewall-Wizards)