I did some reading on the yubikey, and it works pretty much how I expected, and I’m pretty sure my assessment still holds. (And as an aside, up until the latest release they were all completely broken… https://arstechnica.com/information-technology/2017/10/crypto-failure-cripples-millions-of-high-security-keys-750k-estonian-ids/ <https://arstechnica.com/information-technology/2017/10/crypto-failure-cripples-millions-of-high-security-keys-750k-estonian-ids/>)
If the authentication is device only, then stealing the device gets you in (I can’t imagine any one doing it this way though - I am assuming all services probably use two factor for the initial host device login - so you would need to still the key and the computer/phone - and if they have that, you are probably dead anyway, so you really don’t care at this point). If it is part of a two factor authentication (password or pin), then if root is compromised it doesn’t help anyway, as someone has already installed a key tracker, etc. to grab the pin password if needed. The key coupled with external factors (voice, etc.) and machine identity makes it pretty darn safe though… (except bugs in the crypto code as above). At least according to their website on FIDO2: Now, Yubico has worked in collaboration with Microsoft on the evolution of the FIDO U2F authentication standard, to create FIDO2. With FIDO2, the Security Key with its strong authentication can now solve multiple use case scenarios and experiences: — second factor in a two factor authentication solution — strong first factor, with the possession of the device only, allowing for a passwordless experience like tap and go — multi-factor with possession of the device AND PIN, to solve high assurance requirements such as financial transactions, or submitting a prescription. Anyway, your original point about not swapping the master password to disk is valid, but if root is comprised I still say it makes no difference as a malicious program can watch the application live to steal the password directly from pinned, non-swappable memory if so inclined. I’d probably still buy a yubikey, but it seems to be a nightmare calling hundreds of services to tell them my device was lost/stolen. I didn’t see any “one point of contact” in this case ??? Can I log into a single yubikey website and disable it for all services - doesn’t seem available ? > On Oct 16, 2018, at 2:37 PM, Christopher Nielsen <m4dh4t...@gmail.com> wrote: > > Maybe we're talking about different things. Are you thinking of TOTP > 2FA tokens? Your arguments do apply to those. > > I'm not talking about those. I'm talking about devices like a yubikey, > which is essentially a a poor person's HSM. > On Mon, Oct 15, 2018 at 7:21 PM robert engels <reng...@ix.netcom.com> wrote: >> >> That is not true. If you lose the key, anyone else can use the device - >> which is why there is usually an additional requirement beyond the hardware >> key - I am referring to hardware dongles given to users. >> >> By LOSE I meant unknowingly lost - not that once I lose it and KNOW I’ve >> lost it I deactivate the keys - and by then the system may be compromised >> anyway (think murder to steal the hardware device - the victim is not >> reporting the device stolen). >> >> Now sometimes that secondary info might be a retina or fingerprint scan, but >> the point is if the machine providing the information has been compromised >> (root access granted), they are free to alter the binaries and the OS >> itself, to compromise these procedures, meaning they probably already >> captured these elements already (prior to the crime). >> >> It is the coupling of the two scenarios - the security cannot be based on >> the hardware device alone (since it can be lost/stolen), and when there is >> backup identifying information, that can be compromised (if the machine is >> compromised). >> >> I know very well how the hardware devices work. >> >> >>> On Oct 15, 2018, at 7:12 PM, Christopher Nielsen <m4dh4t...@gmail.com> >>> wrote: >>> >>> On Mon, Oct 15, 2018 at 4:33 PM robert engels <reng...@ix.netcom.com> wrote: >>>> >>>> To clarify, this is for a hardware device that protects a local resource - >>>> a network based protocol that challenges the device for access is a >>>> different story, and yes, when properly implemented is secure (unless >>>> someone steals your device! - which is why it is usually password + >>>> device, and then you are back to the same problem of compromising >>>> passwords when root access has been compromised). >>> >>> This statement indicates to me you don't understand how hardware >>> security tokens work. It doesn't matter if you have root access. You >>> cannot obtain key material from it. If you lose it, you lose the set >>> of keys on it. That's it. Revoke them and issue new ones using your >>> root cert/key that never touches a networked system and lives in a >>> safe. >>> >>> -- >>> Christopher Nielsen >>> "They who can give up essential liberty for temporary safety, deserve >>> neither liberty nor safety." --Benjamin Franklin >>> "The tree of liberty must be refreshed from time to time with the >>> blood of patriots & tyrants." --Thomas Jefferson >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "golang-nuts" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to golang-nuts+unsubscr...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >> > > > -- > Christopher Nielsen > "They who can give up essential liberty for temporary safety, deserve > neither liberty nor safety." --Benjamin Franklin > "The tree of liberty must be refreshed from time to time with the > blood of patriots & tyrants." --Thomas Jefferson -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
