I bought a Yubikey NEO 3.3 a few weeks ago and I am very satisfied.
As I mentioned in another post, I'm currently using my Yubikey NEO for:
- Yubico U2F: U2F at sites which support it (just google at the moment, sadly).
- YubiOATH: Holding my TOTP/HOTP credentials for various websites, including google, wordpress, github, dropbox and Facebook.
- OpenPGP: Holding my OpenPGP subkeys, which I use for signing emails, opening encrypted files, and SSH authentication.
- YubiKey PIV: Holding my personal client-ssl and S/MIME certificate from StartSSL.com, as well as a self-signed PIV Auth certificate I use sometimes for SSH authentication.
- YubiKey OTP: I use this for storing an HOTP credential that I use for banking.
I have some feedback and feature requests that would make future versions of this product even more useful:
- Allow the OATH app to use any HOTP credentials that are configured in the standard OTP slots. This would be useful when using the yubikey over NFC. I'd rather use the same interface for all OTPs rather than have to remember that the OTP credential I need has to be read as an NDEF URL, when I'd rather just go to the yubico authenticator app. Note that I can't just add the credential to both apps because then the counter would get out of sync.
- Bitcoin wallet. Incredibly useful. I understand that this was an original goal, but that hardware capabilities prevented it from coming to fruition. If the hardware ever changes to allow support for this, jump on it.
- Support for ECC keys in the OpenPGP app.
- The PIV app is limited to just four certificates, and those certificate slots have additional behaviors associated with them which may not be appropriate. I would love to have the ability to store a somewhat arbitrary number of private keys (and associated certificates), as I have several S/MIME certificates. There is obviously going to be an upper limit on the number of certificates that can be supported, but I'm guessing that you could fit considerably more than four certificates and their associated private keys. Just give me a pkcs11 interface and I'll be happy.
- I would love to have the optional ability to require physically touching the button for signing and decryption operations in both the PIV app and the OpenPGP app. (When used with NFC, a simple timeout, requiring a re-tap, would be adequate) This would ensure that even if my computer and PIN code were compromised that the attacker couldn't arbitrarily perform signing or decryption operations while my NEO was connected.
Additionally, I think that the mechanism for development is kind of unfortunate at the moment. I propose the following mechanism, inspired by the OLPC process:
All yubikey NEO tokens would come from yubico as "development-locked". They are not in development mode and cannot be loaded with apps or updated via software, HOWEVER... Users may contact yubico to request a unique "developer unlock key" that, when presented to that specific yubikey, fully wipes the data storage for all of the apps and irrevocably sets an additional bit indicating that the device is now in a non-factory configuration mode. In this state the user may then load new javacard apps onto the token and do general token development.
The specific case outlined in
this blog post is avoided because:
- Someone would have to contact yubico to get the developer unlock key. You could even require that the user supply a valid original Yubico OTP from the token in question, to verify physical possession of the token.
- The developer unlock key would only be accepted if the device was unprotected.
- All application data (including the U2F internal secret, which would need to be regenerated) would be wiped, making it pretty obvious that the device has been tampered with.
I know the whole developer-mode idea is a bit of a stretch, but I figured it was worth throwing out there.