• Last Updated:
  • Dec 30th, 2019 11:05 am
Sr. Member
Aug 30, 2015
580 posts
791 upvotes
BC
Seems we have some knowledgable people in here --- I came across the Google Titan (discussed in the youtube video linked earlier in this thread)

https://store.google.com/ca/product/tit ... ty_key_kit

It's currently on Black Friday sale for $55.25. Any thoughts on this relative to the Yubikey options?

Edit: For that price you get two keys: 1 USB Security Key and 1 Bluetooth Security Key ... plus an adapter and cable.
Deal Addict
User avatar
Sep 18, 2003
1717 posts
240 upvotes
Winnipeg
setlist wrote: Seems we have some knowledgable people in here --- I came across the Google Titan (discussed in the youtube video linked earlier in this thread)

https://store.google.com/ca/product/tit ... ty_key_kit

It's currently on Black Friday sale for $55.25. Any thoughts on this relative to the Yubikey options?

Edit: For that price you get two keys: 1 USB Security Key and 1 Bluetooth Security Key ... plus an adapter and cable.
A few things,

Some people don't like that they're assembled in China (I think Google flashes them locally?).

They're produced by Feitan, they're not as good of quality as the Yubikey.

Bluetooth isn't secure (compared to NFC). It also requires a battery and isn't passive.

They're fido, not fido2, Google's new key is fido2 and made by yubico I think.

I think those are some reasons. They could work for you. The good thing is you'd get two (though one is Bluetooth).
Sr. Member
Aug 20, 2011
961 posts
1102 upvotes
can80an wrote: Anybody figure out how to use the $7 coupon twice? I want to buy a second Yubikey 5 NFC but the coupon won't load on the second one.
I can't either. I want to use twice too.
Jr. Member
Dec 19, 2008
127 posts
17 upvotes
Calgary
BlackXstar wrote: I can't either. I want to use twice too.
Seems to be a moot point, looks like the coupon deals are over on all Yubikeys ...
Newbie
Nov 21, 2018
8 posts
I've been looking at Yubikey for awhile, long before this post.

I wasn't so much interested in the 2FA for remote servers/etc., I was more interested in using for local machines (I deal with a considerable number). The problem is credentials get re-used, or are predictable. If one machine gets compromised, others can too from known passwords/patterns/etc. Windows does support in a variety of configurations Yubikey (and similar devices) for access control (IE: to make sure those kiddies brute forcing your remote desktop connections can't get in).

The bit I couldn't get past though, was the fact that the credentials it spit out (after you pushed the button/whatnot) were basically just dumped out of the device as though it was a keyboard based on my understanding. Why does this matter? Well, if a device is compromised (IE: say your home PC), a keyboard logger would pick up your 2nd factor just as easily as your password, entirely invisibly, and no real protection would be had. I never made it past this point, as that was really one of my core concerns, you rarely know you're on a compromised PC until something goes wrong (on the attackers side), so chances are you'll dump out your 2nd factor to the attackers long before you realize what's going on.

For third party sites/etc., this makes a lot more sense then text based 2fa (which is riddled with security concerns surrounding targeted attacks [IE: somebody with a fake utility bill porting your phone number over to a new activation at a random mall cell phone kiosk, and then triggering the 2fa to his new mobile device]), but as others have mentioned, support for custom hardware keys throughout most institutions is sorely lacking.
Member
User avatar
Aug 28, 2005
360 posts
82 upvotes
porcupine5 wrote: The bit I couldn't get past though, was the fact that the credentials it spit out (after you pushed the button/whatnot) were basically just dumped out of the device as though it was a keyboard based on my understanding. Why does this matter? Well, if a device is compromised (IE: say your home PC), a keyboard logger would pick up your 2nd factor just as easily as your password, entirely invisibly, and no real protection would be had. I never made it past this point, as that was really one of my core concerns, you rarely know you're on a compromised PC until something goes wrong (on the attackers side), so chances are you'll dump out your 2nd factor to the attackers long before you realize what's going on.
I'm still trying to understand all the different standards supported by YubiKey so I may only be speaking about one specific use case of the YubiKey, but I thought that the authentication methods it offers were based on the fact that the private key stays inside the YubiKey and is never revealed? I think one approach is that the server generates a challenge that the YubiKey then signs and spits back out a response to send back to the server. The server can use this response to validate that the YubiKey knows the private key without actually needing the private key to be sent. Moreover, the result that is sent back to the server should not be the same all the time, so even if a key logger captured all that traffic, an attacker cannot replay those responses usefully because they won't be the correct responses for future server challenges.

Of course, I suppose you are still susceptible to a live man-in-the-middle attack, but not a passive attack like someone capturing input via a keylogger and then reusing it later.

My impression is that the added security of the YubiKey (say over an authenticator app) is that the secret is not supposed to be duplicated by trivial means, whereas with OTP authenticator apps can have their secrets copied over and over again (e.g. just take a screen shot of the QR code and anyone can generate the same codes as you in the future without you knowing). In the case of Google Authenticator, some time ago I was able to access the secrets manually when I rooted my device just by querying the app's SQlite database. Not sure if that database now secured, but on that older version, if someone compromised my Android device, then they'd be able to generate my OTPs without me knowing.
Sr. Member
Apr 14, 2017
657 posts
583 upvotes
rcxAsh wrote: I'm still trying to understand all the different standards supported by YubiKey so I may only be speaking about one specific use case of the YubiKey, but I thought that the authentication methods it offers were based on the fact that the private key stays inside the YubiKey and is never revealed? I think one approach is that the server generates a challenge that the YubiKey then signs and spits back out a response to send back to the server. The server can use this response to validate that the YubiKey knows the private key without actually needing the private key to be sent. Moreover, the result that is sent back to the server should not be the same all the time, so even if a key logger captured all that traffic, an attacker cannot replay those responses usefully because they won't be the correct responses for future server challenges.

Of course, I suppose you are still susceptible to a live man-in-the-middle attack, but not a passive attack like someone capturing input via a keylogger and then reusing it later.

My impression is that the added security of the YubiKey (say over an authenticator app) is that the secret is not supposed to be duplicated by trivial means, whereas with OTP authenticator apps can have their secrets copied over and over again (e.g. just take a screen shot of the QR code and anyone can generate the same codes as you in the future without you knowing). In the case of Google Authenticator, some time ago I was able to access the secrets manually when I rooted my device just by querying the app's SQlite database. Not sure if that database now secured, but on that older version, if someone compromised my Android device, then they'd be able to generate my OTPs without me knowing.
Yeah, the only time the credentials are dumped is when using static password option. Otherwise the private key stays inside. There's also protection against man-in-the-middle and cloning.
https://developers.yubico.com/U2F/Proto ... rview.html
Image
Member
Dec 13, 2006
261 posts
18 upvotes
porcupine5 wrote: I've been looking at Yubikey for awhile, long before this post.

this makes a lot more sense then text based 2fa (which is riddled with security concerns surrounding targeted attacks [IE: somebody with a fake utility bill porting your phone number over to a new activation at a random mall cell phone kiosk, and then triggering the 2fa to his new mobile device]),
(The concern is that with gmail, even with a security key as one of the 2nd FAs, google may send the weak link SMS as a recovery method)
Deal Addict
Dec 16, 2001
1712 posts
635 upvotes
Oakville
21Rouge wrote: (The concern is that with gmail, even with a security key as one of the 2nd FAs, google may send the weak link SMS as a recovery method)
1. Write down your Google recovery codes and store 2 copies in two separate safe places.
2. Delete your phone number from your Google account.
Member
Dec 13, 2006
261 posts
18 upvotes
Kursor17 wrote: 2. Delete your phone number from your Google account.
For sure this sounds like that should work ie deleting the # from the 2 sections of one's google account, in the "Personal Information" i.e. Contact Information and Recovery Phone in "Security" BUT from what I have read Google can still "pull it up" if really needed for an account recovery or in a change of password. I know it doesnt seem to make sense but it has been reported.
Newbie
Nov 21, 2018
8 posts
rcxAsh wrote: I'm still trying to understand all the different standards supported by YubiKey so I may only be speaking about one specific use case of the YubiKey, but I thought that the authentication methods it offers were based on the fact that the private key stays inside the YubiKey and is never revealed? I think one approach is that the server generates a challenge that the YubiKey then signs and spits back out a response to send back to the server. The server can use this response to validate that the YubiKey knows the private key without actually needing the private key to be sent. Moreover, the result that is sent back to the server should not be the same all the time, so even if a key logger captured all that traffic, an attacker cannot replay those responses usefully because they won't be the correct responses for future server challenges.

Of course, I suppose you are still susceptible to a live man-in-the-middle attack, but not a passive attack like someone capturing input via a keylogger and then reusing it later.

My impression is that the added security of the YubiKey (say over an authenticator app) is that the secret is not supposed to be duplicated by trivial means, whereas with OTP authenticator apps can have their secrets copied over and over again (e.g. just take a screen shot of the QR code and anyone can generate the same codes as you in the future without you knowing). In the case of Google Authenticator, some time ago I was able to access the secrets manually when I rooted my device just by querying the app's SQlite database. Not sure if that database now secured, but on that older version, if someone compromised my Android device, then they'd be able to generate my OTPs without me knowing.
Yeah, for some cases that may be the case. I had been investigating the product from a Windows 7 compatibility standpoint, assuming no domain controller was installed/implemented (IE: stand-alone Windows 7, without all the fancy corporate network bits/pieces in play, just a regular Windows 7 pro setup). Most of the issue I ran into when investigating, was the product unsurprisingly documented very well how to set it up/etc., but not what was actually going on in the background (which is what I was specifically interested in). IIRC, I couldn't verify any sort of OTP support between Yubikey/windows, I had gotten the impression the login security being provided was simply a key file being exchanged (at which point, the USB device emulating a keyboard to dump out a static key... Well that didn't address my concerns at all!).

I may have been wrong on this understanding (it certainly wasn't information that was easy to come by, some guesswork/assumptions/etc. obviously existed), and it may have been limited to Windows7 only (as I haven't used Windows 10 hello, and wasn't sure where anything started/stopped/etc. with their general terminology [IE: is "hello" online only? device sign in? hell if I know without testing, and I haven't tested squat!). It could be Windows 10 obsoletes any of these methods, I didn't get far enough to find out at the end of the day (but Windows10's day is looking much sooner now!)

Hope that ramble makes sense, maybe somebody here knows more than I do about Yubikey/Windows/RDP/remote attacks/whatnot and OTP support for the product?
Sr. Member
Aug 30, 2015
580 posts
791 upvotes
BC
Sorry I'm still new to this ---- am I correct in understanding "one is none" and you really need to have two keys: one you carry around, and one you put safely away as a back up in case you lose your primary? If that's the case, can the back up be a cheaper Yubikey since it would get little to zero actual use?

For example:
Primary key: Yubico YubiKey 5 NFC - $59 on amazon.ca
Backup key: Yubico Security Key - $25 on amazon.ca
Deal Expert
User avatar
Jun 15, 2011
41280 posts
6439 upvotes
Curious from a security standpoint. Would love to analyze this further and put it to the test.
Proud to be an Indian.
__________________________________________________________________________
Incident/Cyber Breach Response|Malware Analyzer|Threat Intellligence
Sr. Member
Nov 12, 2009
523 posts
587 upvotes
setlist wrote: Sorry I'm still new to this ---- am I correct in understanding "one is none" and you really need to have two keys: one you carry around, and one you put safely away as a back up in case you lose your primary? If that's the case, can the back up be a cheaper Yubikey since it would get little to zero actual use?

For example:
Primary key: Yubico YubiKey 5 NFC - $59 on amazon.ca
Backup key: Yubico Security Key - $25 on amazon.ca

Would like to know this as well.

Top