Yubico Forum

Just letting you guys know that I've finally pushed out my first release of a PAM module that supports offline authentication of the Yubikey.

A summary of the current features are:

1. Multi-user authentication - database backend stores, obfuscated, yubikey information per user
2. Simple heuristic checking - detects likely replays of OTPs
3. Simple database management add/delete Yubikey entries.
4. It's Open Source

Head on over to http://www.securixlive.com for more information (well given a first release there isn't exactly a great deal of it).

We're always open to ideas, improvements, support and more.

_________________
http://www.securixlive.com/yubipam

Took a quick browse through the source code today.

Any reason you don't use the OpenSSL AES implementation but roll your own? And how do you store the AES keys of the Yubikeys on disk? Are they encrypted or masked in any way?

Asgeir

The reason for rolling our own is simply because we could, it also keeps the coding skills fresh. Once side potentially beneficial side effect is that it does remove the dependency for OpenSSL. However that being said as the code base increases, it will most likely be the first to go

The AES keys are obfuscated through additional encryption. The database entry structure has two components

1. a hash for the username, a hash for the Public UID (ie. fixed) portion of the Yubikey, a hash for second factor password (not yet implemented but still catered for)
2. an encrypted substructure including

a.the AES key
b. a hash of the Private UID
c variables to store the last seen counters and timestamps

The key is formed from a SHA256 hash from concatenation of the public UID, second factor password and the username, which is used to AES CBC encrypt the structure. Obviously we didn't want to be storing the Yubikey AES keys in the clear and this was the strongest and simplest method we came up with. It is not unbreakable but is highly improbably given that you will have to reverse all the lookup hashes in order to decrypt the substructure containing the AES key.

Hopefully that makes sense. Let me know if you need more information. Later releases will include some more detailed documentation on the database structure.

Alternatively if you see any glaring holes in this method I am very keen to know and fix

_________________
http://www.securixlive.com/yubipam

I can't think of any (reasonable) better way to secure the secrets than what you have done, given the restriction that you must have the authenticator on the same box.

I like the use of a hash for lookups, leaving the clear text public ID as part of the key used to decrypt the AES secret. Strictly speaking it's not any better than requiring a strong "pin" (aka a manually entered second factor password) that is used to protect the secret. But it's an elegant way to retain most of that security without requiring a super-long pin.

I think the only way to do better given the constraints of this hardware scheme, would be to move authentication back "online" to some machine on the LAN that's more trusted than the workstation requesting the logon.

I thought it would be spiffy to protect a yubikey database by using the onboard TPM. But *gak*, the amount of effort needed to ensure the system boots all the way through in a trusted state makes that a show stopper. I'm on the windows side of the fence, and I may eventually do that on Vista, but it's not worth it at the moment, since most users would demand XP support too.

Really cool!

What do you think about merging your work into my pam_yubico? I'd like to see a group of people work on improving it, and I think there could a pam_yubico module that supports both online and offline validation.

Thanks,
/Simon

Let me strongly recommend that you don't use OpenSSL: its license is incompatible with the GPL. Thus, the pam_yubico module licensed under the GPL (like this pam module appears to be) couldn't be distributed by Debian for example. There is libgcrypt which is a LGPL library for crypto.

Also consider using the Yubico C library that also contains AES decryption and OTP parsing: http://code.google.com/p/yubico-c-client/

/Simon

I received my AES key details from Yubico support as 3 tokens: tokenId_modhex, tokenId_b64, secret. Could you please tell me how to invoke ykpasswd using those parameters?

Cheers,
Klaus

--
Unselfish actions pay back better

Klaus,

Sorry for the tardy reply but you can input either hex or modhex when it prompts for hex. This saves you having to decode the tokenId_modhex for yourself

Alternatively you can pass it straight through on the command line using:



Feel free to PM or email me if you have any further questions.

_________________
http://www.securixlive.com/yubipam

What I really can't fathom is what parameters to pass as public uid and private uid. In the example you gave me you pass what I see as the public id as the AES key, whereas I would ring in the secret as the AES key.

Again: I was given 3 parameters from Yubico: tokenId_modhex (which is my 12 char public id in modhex), tokenId_b64 (which is my public id in base64), and secret (which I guess is the AES key).

Now, how do I invoke ykpasswd in order to add my yubikey to /etc/yubikey, please?

Cheers,
Klaus

I have added a link to your project on our main web, see:

http://yubico.com/developers/library/

Note sure why it took me so long to add this, sorry for the delay!

I still look forward to merging our two PAM modules though: I think one PAM module should be able to feature both disconnected and online capabilities.

Thanks,
Simon