RE: SecureID in place of passphrase

From: Chris Macneill (temp_at_eguesswork.co.uk)
Date: 05/29/03

  • Next message: Roumen Petrov: "Re: X.509 and OpenSSH"
    To: "'John Brightwell'" <brightwell_151@yahoo.co.uk>, <secureshell@securityfocus.com>
    Date: Thu, 29 May 2003 19:36:03 +0100
    
    

    John,

    The private key is generally encrypted using the passphrase; therefore the
    passphrase needs to be a static entity. A SecurID PASSCODE is dynamic,
    changing in some multiple of 30 seconds, usually every 60 seconds, so on
    first inspection it would appear difficult to use SecurID to protect the
    private key.

    However, there is a method whereby protection of the private key by SecurID
    could be implemented. If the front end for the access to the private key
    were replaced with custom code that initially uses SecurID authentication,
    the ACE/Server could be made to pass back the private key from its database.
    Communications to/from ACE/Server are over a secure protocol. There are at
    least three ways this integration could be achieved:-

    1. The simplest method is to store the private key in the ACE/Server
    database as an unencrypted string. However, anyone with administrator access
    to the ACE/Server database could potentially recover the private keys. Not
    good! This option is fairly easy to implement, but not very secure. The time
    required for development would probably be in the order of 2 to 3 man weeks.

    2. A more secure method would be to store all private keys encrypted with a
    single common passphrase, only known to someone with access to the source
    code. However, anyone with administrator access to ACE/Server could retrieve
    the keys and perform a brute force attack. This option is fairly easy to
    implement and more secure than option 1. The time required for development
    would probably be in the order of 2 to 3 man weeks.

    3. Alternatively the private key could be encrypted using the user's SecurID
    PIN. This is more secure, but would require a custom method for PIN change
    as the user's private key would need to be re-encrypted each time the PIN
    was changed. This option is very secure, but would require considerable
    development effort to achieve. The time required for development would
    probably be in the order of 3 to 8 man weeks, depending on the interface
    method required for changing PINs.

    Another issue to consider is if you are trying to allow a user to access
    multiple systems whilst only authenticating with SecurID once, you would
    have to cache the decrypted passphrase for some period of time and it would
    thus be open to attack. A better approach may be to require SecurID
    authenticated access to a gateway system and then use Kerberos to
    authenticate users between the gateway and target systems.

    I used to work for RSA Security and have over 12 years experience of
    integrating SecurID authentication with many third party products and have
    some 3 years experience of integrating SecurID with OpenSSH.

    The development times quoted are a rough estimate for a developer with good
    knowledge of ACE/Agent Authentication and ACE/Server Database APIs,
    knowledge of OpenSSH and general principles of encryption.

    The development times quoted assume only one flavour of UNIX is involved for
    both SSH Client System and ACE/Server, development on MS Windows or multiple
    flavours of UNIX would probably increase development times.

    Regards,

    Chris Macneill

    -----Original Message-----
    From: John Brightwell [mailto:brightwell_151@yahoo.co.uk]
    Sent: 29 May 2003 14:35
    To: secureshell@securityfocus.com
    Subject: SecureID in place of passphrase

    Dear All

    Do you know whether it's possible to use SecureID to
    gain access to the private key, in place of a
    passphrase?

    Background:
    It may seem like an odd request - I realise that the
    authentication to the server can be by SecureID
    instead of via private key (and that would be a more
    secure solution ... probably)

    I would like our admins to be able to swap between
    machines transparently (using ssh-agent) but I want to
    be absolutely sure that it is they who originally
    unlock the key ... so I'd like to use two factor
    authentication rather than a passphrase to access the
    key that is used by ssh-agent.

    If I authenticate to the server(s) using SecureID then
    they have to use it every time they move to a new
    machine.

    I suppose that I can require that the machine that
    they use as a client requires SecureID for
    authentication, which isn't quite as good .... but if
    you know how to authenticate access to the key with
    SecureID that'll be great.

    Many thanks

    John

    __________________________________________________
    Yahoo! Plus - For a better Internet experience
    http://uk.promotions.yahoo.com/yplus/yoffer.html

    ---
    Outgoing mail is certified Virus Free.
    Checked by AVG anti-virus system (http://www.grisoft.com).
    Version: 6.0.483 / Virus Database: 279 - Release Date: 19/05/2003
     
    

  • Next message: Roumen Petrov: "Re: X.509 and OpenSSH"

    Relevant Pages

    • Re: How can I secure a Debian installation?
      ... The passphrase protects the private key from being accessed. ... being more secure than a password login because any Tom, ...
      (Debian-User)
    • Re: How can I secure a Debian installation?
      ... The passphrase protects the private key from being accessed. ... being more secure than a password login because any Tom, ...
      (Debian-User)
    • Re: [Fwd: Re: Debian SSH server configuration]
      ... passphrase (which is fractionally less secure but that's probably OK.) ... containing the private key is compromised so, potentially, is every ... To UNSUBSCRIBE, email to debian-user-REQUEST@xxxxxxxxxxxxxxxx ...
      (Debian-User)
    • Re: Ubuntu server remote file access
      ... If someone has your private key then they have your private key. ... There is no encryption that they need to break. ... If they brute force that passphrase *then* they ... I thought someone said ssh keys are more secure. ...
      (Ubuntu)
    • Re: Feature request
      ... >>case why can that not be send across on request in the handshake phase? ... > change his private key in any way, he could no longer be authenticated ... the passphrase is ... but the passphrase belongs to the private keyfile. ...
      (comp.security.ssh)