I don't see SKEY style OTP lists as inherently bad. "its how you do
it" which concerns me, not that it is done.
trust your users to always ALWAYS find the worst way to use the product.
Note the label on bleach bottles: "Do not lick"
or coffee cups: "Caution: contents hot"
I agree that 'consenting adults' can do this properly, it's when people
really want to find their own way that....we end having this dicsussion
Hi,
In my experience, yubikeys are not very secure. I know of someone in my team who would generate a few hundred tokens during a meeting and save the output in a text file. Then they'd have a small python script which was triggered by a hotkey on my macbook to push "keyboard" input. They did this because the org they were working for would make you use yubikey auth for pretty much everything, including updating a simple internal Jira ticket.
By that argument, SecureID (and other LCD tokens) are also really
insecure. When I worked at AOL we had to use them for almost
everything - a bunch of people got together and put their secureIDs in
a grid under a webcam. That way they didn't need to carry them with
them - when they needed a token they would open the webcam page, and
know that theirs was third down, and fourth across....
W
Meh. Here's a better example of bad:
SSH Key Auth + Yubi key.
This isn't two-factor authentication folks, it's just 1-factor: what
you have. You have an ssh private key. You have a yubi key. Same
factor. Either one proves you have possession of something only the
user should have. Proving two does not appreciably change the
probability that you are you.
For two factor auth, you actually have to use an additional factor.
Something from the what you know factor (e.g. a password) or the what
you are factor (e.g. a fingerprint).
Just like a password and a pin isn't two factor. It's exactly the same
as having a single longer password and subject to the same general
types of compromise.
Regards,
Bill Herrin
Not actually, no…
SecurID and the others of its ilk have a safety feature in that the number doesn’t change that often.
It turns out to be awkward and time-consuming to do what is being done with the UBIKEY.
I agree that this abuse of the UBI Key is more an issue of implementation than the inherent nature of the
UBIKEY, but the UBIKEY does allow this kind of abuse in ways that other tokens don’t facilitate.
Owen
The details of the implementation of the dispensation may be nuanced.
Experience will tell us more in the coming days.
Are there any inklings of international co-operation with regards to “no foreigners” as per recently Australia and other nations, in terms of allowing in those engaged in telecommunications services where in some cases remote/local hands are not sufficient?
> In my experience, yubikeys are not very secure. I know of someone in my team who would generate a few hundred tokens during a meeting and save the output in a text file. Then they'd have a small python script which was triggered by a hotkey on my macbook to push "keyboard" input. They did this because the org they were working for would make you use yubikey auth for pretty much everything, including updating a simple internal Jira ticket.
Meh. Here's a better example of bad:
SSH Key Auth + Yubi key.
This isn't two-factor authentication folks, it's just 1-factor: what
you have.
Well, yes and no. With a Yubiikey the attacker has to be local to
physically touch the button[0] - with just an SSH key, anyone who gets
access to the machine can take my key and use it. This puts it in the
"something you have" (not something you are) camp.
You have an ssh private key. You have a yubi key. Same
factor. Either one proves you have possession of something only the
user should have. Proving two does not appreciably change the
probability that you are you.For two factor auth, you actually have to use an additional factor.
Something from the what you know factor (e.g. a password) or the what
you are factor (e.g. a fingerprint).Just like a password and a pin isn't two factor. It's exactly the same
as having a single longer password and subject to the same general
types of compromise.
Not really -- if an attacker steals my laptop, they don't have the
yubikey (unless I store it in the USB port). If they *do* steal both,
they can bruteforce the SSH passphrase, but after 5 tries of guessing
the Yubikey PIN it self-destructs.
This makes it very different to a longer passphrase.
W
[0]: Yes, obviously an attacker who has root on a machine could trojan
the ssh binary, change the OS to make it play Nyancat through the
speaker, etc... but that's true for any solution...
>
>>
>> Hi,
>>
>> In my experience, yubikeys are not very secure. I know of someone in my team who would generate a few hundred tokens during a meeting and save the output in a text file. Then they'd have a small python script which was triggered by a hotkey on my macbook to push "keyboard" input. They did this because the org they were working for would make you use yubikey auth for pretty much everything, including updating a simple internal Jira ticket.
>
> By that argument, SecureID (and other LCD tokens) are also really
> insecure. When I worked at AOL we had to use them for almost
> everything - a bunch of people got together and put their secureIDs in
> a grid under a webcam. That way they didn't need to carry them with
> them - when they needed a token they would open the webcam page, and
> know that theirs was third down, and fourth across….Not actually, no…
SecurID and the others of its ilk have a safety feature in that the number doesn’t change that often.
It turns out to be awkward and time-consuming to do what is being done with the UBIKEY.
Not if you run it in TOTP mode. Yubikeys support many options - if you
choose to use a weak solution, well that's your choice...
I guess you could ask them nicely to make a version without the
features you don't want to use - or you could just not *use* the
features you don't want to use....
I agree that this abuse of the UBI Key is more an issue of implementation than the inherent nature of the
UBIKEY, but the UBIKEY does allow this kind of abuse in ways that other tokens don’t facilitate.
That's like saying that cars are worse than bicycles, because cars
allow you drive into things are a more dangerous speed. I mean, yes,
but ....
W
Well, yes and no. With a Yubiikey the attacker has to be local to
physically touch the button[0] - with just an SSH key, anyone who gets
access to the machine can take my key and use it. This puts it in the
"something you have" (not something you are) camp.
Hi Warren,
They're both "something you have" factors. The yubi key proves
possession better than the ssh key just like a long password proves
what-you-know better than a 4-digit PIN. But the ssh key and the yubi
key are still part of the same authentication factor.
Not really -- if an attacker steals my laptop, they don't have the
yubikey (unless I store it in the USB port).
You make a habit of removing your yubi key from the laptop when nature
calls? No you don't.
If they *do* steal both,
they can bruteforce the SSH passphrase, but after 5 tries of guessing
the Yubikey PIN it self-destructs.
What yubikey are you talking about? I have a password protecting my
ssh key but the yubikeys I've used (including the FIPS version) spit
out a string of characters when you touch them. No pin.
Regards,
Bill Herrin
I confess I haven’t investigated the implementation details, but is it possible for one to issue ubikeys
to an employee in a secure way with those features disabled?
It’s the allowing the employee to make a poor choice not necessarily desired by the employer thing
that seems to me is the issue in this case.
Cars are more dangerous than bicycles, but everything is a matter of balancing tradeoffs.
In this case, I’m not sure the ubikey offers anything over the Secur-ID to balance that increased
hazard.
Owen
First, for your whole message:
s/\s+UBIKEY'/YUBIKEY/g
s/\s+UBI/YUBI/g
thanks.
Not if you run it in TOTP mode. Yubikeys support many options - if you
choose to use a weak solution, well that's your choice...
I guess you could ask them nicely to make a version without the
features you don't want to use - or you could just not *use* the
features you don't want to use….I confess I haven’t investigated the implementation details, but is it possible for one to issue ubikeys
to an employee in a secure way with those features disabled?
You can set the key and the authentication system to only do TOTP
(time based) and not HOTP.
you can also program the keys (I think all of their keys since their
first key) with custom firmware.
It’s the allowing the employee to make a poor choice not necessarily desired by the employer thing
that seems to me is the issue in this case.
Sure limit the manner in which they can do foolish things, require
totp not hotp.
-chris
Well, yes and no. With a Yubiikey the attacker has to be local to
physically touch the button[0] - with just an SSH key, anyone who gets
access to the machine can take my key and use it. This puts it in the
“something you have” (not something you are) camp.Hi Warren,
They’re both “something you have” factors. The yubi key proves
possession better than the ssh key just like a long password proves
what-you-know better than a 4-digit PIN. But the ssh key and the yubi
key are still part of the same authentication factor.Not really – if an attacker steals my laptop, they don’t have the
yubikey (unless I store it in the USB port).You make a habit of removing your yubi key from the laptop when nature
calls? No you don’t.If they do steal both,
they can bruteforce the SSH passphrase, but after 5 tries of guessing
the Yubikey PIN it self-destructs.What yubikey are you talking about? I have a password protecting my
ssh key but the yubikeys I’ve used (including the FIPS version) spit
out a string of characters when you touch them. No pin.
The yubikey does many things depending on how it’s configured. None of mine use the touch to spit out OTP mode, that is the factory mode though yes. Other modes can be password protected (it uses the PIN nomenclature which is confusing, it definitely accepts ASCII and nay even take binary data as a PIN depending on mode of operation) — it can present as industry standard smart card ( I have one with a pin/password for code signing in Visual Studio f/ex…along with a backup kept locked elsewhere)
Well, yes and no. With a Yubiikey the attacker has to be local to
physically touch the button[0] - with just an SSH key, anyone who gets
access to the machine can take my key and use it. This puts it in the
“something you have” (not something you are) camp.Hi Warren,
They’re both “something you have” factors. The yubi key proves
possession better than the ssh key just like a long password proves
what-you-know better than a 4-digit PIN. But the ssh key and the yubi
key are still part of the same authentication factor.Not really – if an attacker steals my laptop, they don’t have the
yubikey (unless I store it in the USB port).You make a habit of removing your yubi key from the laptop when nature
calls? No you don’t.If they do steal both,
they can bruteforce the SSH passphrase, but after 5 tries of guessing
the Yubikey PIN it self-destructs.What yubikey are you talking about? I have a password protecting my
ssh key but the yubikeys I’ve used (including the FIPS version) spit
out a string of characters when you touch them. No pin.The yubikey does many things depending on how it’s configured. None of mine use the touch to spit out OTP mode, that is the factory mode though yes. Other modes can be password protected (it uses the PIN nomenclature which is confusing, it definitely accepts ASCII and nay even take binary data as a PIN depending on mode of operation) — it can present as industry standard smart card ( I have one with a pin/password for code signing in Visual Studio f/ex…along with a backup kept locked elsewhere)
Replying to myself to clarify a bit… the PKI/SSL private keys are on the Yubikey, password protected, signing is accomplished by VS passing the bits to be signed to the smart card application on the yubikey, which requires a password to enable/unlock. On the yubikey Depending on configuration this is a just once operation typically. So each signing op requires a password entry. But it could be configured diffferebtly. By only keeping the private keys on the yubikey it’s something you have (the yubikey) and something you know (the password)… the yubikey (barring software bugs obviously) will not expose the private key, it only does the signing op.
That same yubikey has a separate app and trust store in OpenGPG mode, which does signing for ssh pubkey auth, with a different private key. Same key also does FIDO, another application with another key store.
The same key doing all that could also have a “long touch” to spit out an OTP.
I confess I haven’t investigated the implementation details, but is it possible for one to issue ubikeys
to an employee in a secure way with those features disabled?
Yes. And changing that setup either requires a separate admin pin or wiping the associated private key data to reconfigure. It depends on which application/mode. FIDO I believe is most inflexible here as it can only be short touch to activate.
I don’t use the HID keyboard mode OTP keying app/feature so I’m not terribly familiar with that. It might be that it can be configured limited such that N in X seconds or a replug is required (to circumvent the timer) but I really do not know. If people are really curious I can grab a spare key and check. I use the CCID/smart card type modes. I do know that the touch OTP key feature requires wiping the associated private key data, or having it available to reprogram and change options. They’re a shared secret mode so the yubikey authentication server has those private keys.
For all my banking apps in South Africa, I can use username/password, QR code or Face ID, in ascending order of preference. All transactions that have not been pre-approved before require further authentication, typically via SMS approval, which goes to the the registered phone. Qatar Airways’ FQTV app supports Face ID login, but it SMS’s and e-mails you an OTP as the 2nd stage of authentication. So different companies are doing different things, but one thing that is consistent is that there are multiple stages being employed to login. Mark.
Well, not the whole of Africa, yet :-)...
Mark.
How about a new technology I have heard about called sqrl. See
https://sqrl.grc.com for more information. It overcomes a lot of the
problems discussed here.
Like this: when I hear someone tell that her country got on lockdown then advice to not forget OTP device at desk.
Mr. Morrow - where are you situated approximately?
Alex
What yubikey are you talking about? I have a password protecting my
ssh key but the yubikeys I’ve used (including the FIPS version) spit
out a string of characters when you touch them. No pin.
PIV enabled ones have pins if you are using that functionality.
third planet from the sun... so they tell me.
He’s a network operator. From North America, on the North American Network Operators mailing list. Something you are not, so please stop spouting your drivel on a list that has nothing to do with you. This is a crisis, not a time for a European Project Proposer to spout off massively uninformed bullshit non-stop because no one else will listen.
NANOG-L mods: it’s time to show some leadership.