YubiKey – Making secure login easy
yubico.com
yubico.com
I wrote some patches for KeepassX to use the Yubikey to derive the encryption key (completely offline)[4] but unfortunately the maintainer has zero interest in merging them.
[1] https://www.yubico.com/2012/12/yubikey-neo-openpgp/
[2] http://googleonlinesecurity.blogspot.com/2014/10/strengtheni...
[3] https://www.yubico.com/products/services-software/personaliz...
[4] https://github.com/keepassx/keepassx/pull/52 and https://news.ycombinator.com/item?id=7801131
Other than that, this is cool and I generally really like my YubiKey Neo
Both, the FST-01 and Gnuk are made by one of the GnuPG main developers, gniibe :)
I suggest this as I discarded a Yubikey NEO for one of these and i'm pretty happy.
http://www.seeedstudio.com/wiki/FST-01 http://www.fsij.org/doc-gnuk/
I'm interested as for our local work (activism related) Gnuk showed up as the best alternative for price, openess and the possibility if something fails to not have to buy new hardware. Yubikey did the right thing with their latest "put your yubikey in the trash bug" giving a new one, but we don't live in the US and time can be a factor.
But still, Gnuk is far from perfect and the better it gets the better for us. Can you tell me about the issues you had so i can talk with gniibe to see if there are solutions for them?
Thanks in advance.
I was comparing NEO to other tokens I've seen and used - it's not worse, but non of them are as simple as I would like (and no, I don't know how to describe the simplicity I'm after).
Looks like the gnuk is a software implementation - do you trust it not to disclose the private key if it is physically accessible? If you do, why?
I trust the NEO to require more than what your average hacker can use at home - though, of course, I don't trust it against state actors, who probably have the fund and equipment to make any smart card apparatus "talk".
My Yubikey feels like a natural member of my key ring! I love it.
https://developers.yubico.com/U2F/Libraries/List_of_librarie...
You need to include this js: https://demo.yubico.com/js/u2f-api.js
... which isn't really mentioned anywhere. That js file loads an embedded chrome extension and handles all the heavy lifting.
The documentation (if there is any?) fails to mention that your appId has to be https; any http appIds will fail with an obscure error.
I guess I misunderstood. I thought that once I enabled two-factor auth for LastPass, it'd require that no matter what. Nope, just open the iPad app and no two-factor required.
Alas synching between different machines isn't easy (counter gets out of synch) and I'm not all that comfortable with keeping the databse in my owncloud.
If anyone has a good suggestion for a crossplattform (Xubuntu, OSX, Android), synchable and FLOSS OATH HOTP password storage solution that doesn't rely on 3rd party cloud storage I'm all ears. Not exactly a security expert but I feel that's the setup I want :) I could fallback to challange/response and that would fix some issues but be less secure.
[The Yubikey itself is pretty cool though]
It being a separate piece of plastic might arguably be another advantage, if we assume that most people are more likely to lose their phone than their keyring.
It’s interesting: apparently[0], YubiKey is Google’s initiative and the company itself uses YubiKeys internally.
[0] http://www.forbes.com/sites/amadoudiallo/2013/11/30/google-w...
If I understand the various OTP implementations correctly, they are essentially the same, trading a time-counter for use-counter.
The non-time OTP will give you ds1, ds2, ds3 -- where dsX ("derived secret X") is derived from shared-secret+X, while the time-based OTP will give you dsT1, dsT2 ... derived from shared-secret+TimestampX.
The former is a little more secure, as you need to allow for some drift. And having a proper 128 bit shared secret is probably more secure than something derived from a crackable password/pass phrase.
But AFAIK they're both vulnerable to the shared secret being compromised on the server-side and/or cracked (if it's possible to brute force).
I don't recall the exact details of the TOTP-spec, but in general I think the derived-secret/otp essentially boils down to: truncate(hmac(shared-secret,counter)) where counter is either a timestamp, or a sequence.
If the counter is actually a sequence of used passwords(1,2,3...N), the server can store just N passwords (usable for N logins), and cross them off after use -- so no need to store the shared secret on the server. For TOTP the server needs the shared-secret in order to generate a few +/- values to match against what the client supplied.
In both cases you could use a sniffed one-time password to try and guess the shared-secret, if you can know/guess the counter. The risk for a 128 bit random key is obviously somewhat less than if the shared secret is "hunter2" (modulus stretching etc).
The newer YubiKey versions also support the new U2F Protocol used by Google.
The YubiKey is developed and owned by Yubico - Yubico worked with Google to develop the protocol which would become U2F for Google's internal use.
See http://www.yubico.com/wp-content/uploads/2014/02/Yubico-TOTP...
I use too the Yubikey Neo as a smartcard, but not with the GPG applet, rather with the PIV applet. As such, to connect to my most secure servers, my Yubico is mandatory and as such it's just impossible to bruteforce your way in. I use the GPG applet ...well...for GPG.
However, I'm still looking for a cheap way to do fingerprint (rather than typing your PIN) authentication. Does anybody have heard of a fingerprint token which works with Linux AND Mac OS X ? Or is it possible to have a fingerprint reeader as some sort of proxy ?
Second question, I wanted to use the Yubico NEO as a smartcard token with a TrueCrypt fork, but the Truecrypt source code has really specific requirements for the object they can store on a smartcard (buggy requirements if you ask me) and as such it's not possible to use the Yubico as a physical decryption key for encrypted volume. Does anybody have a suggestion for an other working solution ?
On the downside, your encryption secret is available "in the clear" in the form of a TOTP token that is loaded into the app. You are highly vulnerable during these moments. If an attacker gets a copy of the TOTP token, they can generate the six digit numbers as easily as you.
To me, not having a yubikey would be like not being able to use cmd-C/V to copy/paste and having to use the system menu every time instead.
https://developers.yubico.com/U2F/Protocol_details/Overview....
I have one vltjjenelhnhhkvrnft also.
Each side has a seed value which then allows the calculation of what the current value should be.
Each Yubico OTP has a plain text public ID as the first 12 characters of the OTP. This is used to identify the YubiKey which generated the OTP without having to perform any OTP processing. The remaining 32 characters of the OTP are an AES-128 bit encrypted hash. This hash is made of the Private ID, a string known only to the YubiKey and Authentication server, to further validate the OTP.
In addition to the Private ID, the OTP also contains counters tracking how many times the YubiKey has been power cycled (usage) and how many OTP events it has preformed since it's last power on (session). These counter values are stored in the authentication server and checked for each OTP. If the usage counter is less than the value on the server, or if the session counter is less than or equal to the value on the server, the OTP is rejected as a replay attack.
This means the YubiKey OTP will not get out of sync with the validation server, as well as adding additional randomness to the OTPs generated.
They have some fancier keys that support a 'universal 2 factor' standard which I think they may have had a hand in creating.
I've used mine in OATH-HOTP and HMAC-SHA1 along with KeePass to do two-factor on my password db. You do need a server-side or peer component to initially sync with to do OTP or challenge-response.