On Fri, Jul 18, 2014 at 10:27 AM, Mark Kolmar <mark at burningrome.com> wrote: > Sanitized output: > > $ stoken show > Enter password to decrypt token: > Serial number : 000123456789 > Encrypted w/password : yes > Encrypted w/devid : no > Expiration date : 2099/99/01 > Key length : 128 > Tokencode digits : 6 > PIN mode : 0 > Seconds per tokencode : 60 > App-derived : no > Feature bit 4 : no > Time-derived : yes > Feature bit 6 : no > > The Windows RSA app generates a 6-digit code. It doesn't ask for the PIN or > a password to protect the token once imported. What the VPN admins call the > PIN is used as a prefix to the 6-digit code to form the first password. It's > not clear to me that this so called PIN has exactly the same purpose as what > stoken or openconnect call a PIN. So, according to page 193 of [1], software tokens can be provisioned in the following ways: a) PINPad-style. The user must enter a PIN in the software token application to generate the passcode. Page 190 indicates that this is the default configuration for a software token, and indeed, all of the tokens I've seen "in the wild" use this configuration. b) Fob-style. The user must enter the PIN, followed by the tokencode when logging on to the resource protected by SecurID. It sounds like this is what you have. c) Tokencode. The user enters a tokencode. No PIN is required. Looking at the PIN-related attributes in the sdtid file, I think (a) corresponds to PIN mode 2: AddPIN=1, LocalPIN=0. If you have (b), then (b) is indicated by PIN mode 0 (AddPIN=0, LocalPIN=0). The seed file for my SID700 hardware tokens also use this mode: <DefAddPIN>0</DefAddPIN> <DefLocalPIN>0</DefLocalPIN> <DefCopyProtection>0</DefCopyProtection> <DefPinType>0</DefPinType> <DefKeypad>0</DefKeypad> <DefProtLevel>0</DefProtLevel> <DefRevision>0</DefRevision> <DefTimeDerivedSeeds>1</DefTimeDerivedSeeds> <DefAppDerivedSeeds>0</DefAppDerivedSeeds> So maybe (c) corresponds to PIN mode 1 (AddPIN=0, LocalPIN=1)? It would be good to verify this somehow. I can confirm that the official RSA app does not ask for a PIN when presented with a PIN mode 0 or 1 token. What I cannot tell is whether PIN mode 1 means "don't combine PIN + tokencode = passcode; just send the raw tokencode as-is". If libstoken can reliably distinguish cases (b) and (c), then we can teach openconnect to prompt for a PIN prefix for case (b) but not for cases (a) or (c). If not, then I guess a partial solution is to always prompt for a PIN prefix on a PINless (!stoken_pin_required()) token, and allow the prefix to be blank. [1] http://www.emc.com/collateral/15-min-guide/h12276-am8-administrators-guide.pdf