South Africa On Lockdown - Coronavirus
So the South African president has just announced - full country lockdown from midnight this Thursday, 26th March (SAST). If any of you have any work that needs to be done out here, please bear that in mind. Mark.
And oh, it's for 21 days... Mark. On 23/Mar/20 20:22, Mark Tinka wrote:
So the South African president has just announced - full country lockdown from midnight this Thursday, 26th March (SAST).
If any of you have any work that needs to be done out here, please bear that in mind.
Mark.
But also: "The categories of people who will be exempted from this lockdown are... those involved in the production, distribution and supply of... telecommunications services" https://www.cnbcafrica.com/news/2020/03/23/breaking-nationwide-lockdown-anno... I think most anyone on this list could be considered exempt. I do hope the same will be true should our respective local and national governments take similar action. On Mon, 23 Mar 2020, Mark Tinka wrote:
And oh, it's for 21 days...
Mark.
On 23/Mar/20 20:22, Mark Tinka wrote:
So the South African president has just announced - full country lockdown from midnight this Thursday, 26th March (SAST).
If any of you have any work that needs to be done out here, please bear that in mind.
Mark.
--------------------------------------------------------------------------- Peter Beckman Internet Guy beckman@angryox.com http://www.angryox.com/ ---------------------------------------------------------------------------
On 23/Mar/20 21:20, Peter Beckman wrote:
But also:
"The categories of people who will be exempted from this lockdown are... those involved in the production, distribution and supply of... telecommunications services"
https://www.cnbcafrica.com/news/2020/03/23/breaking-nationwide-lockdown-anno...
I think most anyone on this list could be considered exempt.
I do hope the same will be true should our respective local and national governments take similar action.
Yes, a number of "essential services" have been identified as needing to continue to operate under special dispensation during the lockdown, and telecoms falls within that. The details of the implementation of the dispensation may be nuanced. Experience will tell us more in the coming days. Mark.
I dont know where are people about supporting VPN and one-time passwords on tokens. At my work place a few people dont have tokens (OTP - One Time PAsswords). The reserve of these tokens has been exhausted. NEw ones are being on order. Until then some people cant get on VPN. Some people forgot their token on their desk and had to to travel to office to get it, a thing not good to do to go to office now. Some (not sure) might have issues with syncing these devices. An OTP token has a certain skew about clock, and a battery that lasts long. Hopefully, one's token has been synchronised recently and the battery is new. The length of time one cant go to office might be anywhere between 21 days (announced) and 2 months (experrience eg in Wuhan still closed). Some times the synching of clock can be performed remotely, and some 'coin' batteries can be replaced by the person with skill and tools, could be extracted from a quartz watch for example. An OTP device can be of many kinds. Some people keep OTPs on paper (I did some time ago). Some OTP devices are like Japanese 'tamaguchi' format, others like a credit card format. Alex, LF/HF 3 Le 23/03/2020 à 20:47, Mark Tinka a écrit :
On 23/Mar/20 21:20, Peter Beckman wrote:
But also:
"The categories of people who will be exempted from this lockdown are... those involved in the production, distribution and supply of... telecommunications services"
https://www.cnbcafrica.com/news/2020/03/23/breaking-nationwide-lockdown-anno...
I think most anyone on this list could be considered exempt.
I do hope the same will be true should our respective local and national governments take similar action. Yes, a number of "essential services" have been identified as needing to continue to operate under special dispensation during the lockdown, and telecoms falls within that.
The details of the implementation of the dispensation may be nuanced. Experience will tell us more in the coming days.
Mark.
Software-based TOTP offer more security than no one-time passwords, but admittedly less than the physical tokens. Google Authenticator, Authy, 1Password, LastPass all support TOTP. On Mon, 23 Mar 2020, Alexandre Petrescu wrote:
I dont know where are people about supporting VPN and one-time passwords on tokens.
At my work place a few people dont have tokens (OTP - One Time PAsswords). The reserve of these tokens has been exhausted. NEw ones are being on order. Until then some people cant get on VPN.
Some people forgot their token on their desk and had to to travel to office to get it, a thing not good to do to go to office now.
Some (not sure) might have issues with syncing these devices. An OTP token has a certain skew about clock, and a battery that lasts long. Hopefully, one's token has been synchronised recently and the battery is new. The length of time one cant go to office might be anywhere between 21 days (announced) and 2 months (experrience eg in Wuhan still closed). Some times the synching of clock can be performed remotely, and some 'coin' batteries can be replaced by the person with skill and tools, could be extracted from a quartz watch for example.
An OTP device can be of many kinds. Some people keep OTPs on paper (I did some time ago). Some OTP devices are like Japanese 'tamaguchi' format, others like a credit card format.
Alex, LF/HF 3
Le 23/03/2020 à 20:47, Mark Tinka a écrit :
On 23/Mar/20 21:20, Peter Beckman wrote:
But also:
"The categories of people who will be exempted from this lockdown are... those involved in the production, distribution and supply of... telecommunications services"
https://www.cnbcafrica.com/news/2020/03/23/breaking-nationwide-lockdown-anno...
I think most anyone on this list could be considered exempt.
I do hope the same will be true should our respective local and national governments take similar action. Yes, a number of "essential services" have been identified as needing to continue to operate under special dispensation during the lockdown, and telecoms falls within that.
The details of the implementation of the dispensation may be nuanced. Experience will tell us more in the coming days.
Mark.
--------------------------------------------------------------------------- Peter Beckman Internet Guy beckman@angryox.com http://www.angryox.com/ ---------------------------------------------------------------------------
I’ve already been playing with YubiKeys, but sadly Google Titan wouldn't work with Windows Hello. Might be something I was doing wrong... Sincerely, Eric Tykwinski TrueNet, Inc. P: 610-429-8300
On Mar 23, 2020, at 4:21 PM, Peter Beckman <beckman@angryox.com> wrote:
Software-based TOTP offer more security than no one-time passwords, but admittedly less than the physical tokens. Google Authenticator, Authy, 1Password, LastPass all support TOTP.
On Mon, 23 Mar 2020, Alexandre Petrescu wrote:
I dont know where are people about supporting VPN and one-time passwords on tokens.
At my work place a few people dont have tokens (OTP - One Time PAsswords). The reserve of these tokens has been exhausted. NEw ones are being on order. Until then some people cant get on VPN.
Some people forgot their token on their desk and had to to travel to office to get it, a thing not good to do to go to office now.
Some (not sure) might have issues with syncing these devices. An OTP token has a certain skew about clock, and a battery that lasts long. Hopefully, one's token has been synchronised recently and the battery is new. The length of time one cant go to office might be anywhere between 21 days (announced) and 2 months (experrience eg in Wuhan still closed). Some times the synching of clock can be performed remotely, and some 'coin' batteries can be replaced by the person with skill and tools, could be extracted from a quartz watch for example.
An OTP device can be of many kinds. Some people keep OTPs on paper (I did some time ago). Some OTP devices are like Japanese 'tamaguchi' format, others like a credit card format.
Alex, LF/HF 3
Le 23/03/2020 à 20:47, Mark Tinka a écrit :
On 23/Mar/20 21:20, Peter Beckman wrote:
But also:
"The categories of people who will be exempted from this lockdown are... those involved in the production, distribution and supply of... telecommunications services"
https://www.cnbcafrica.com/news/2020/03/23/breaking-nationwide-lockdown-anno... I think most anyone on this list could be considered exempt. I do hope the same will be true should our respective local and national governments take similar action. Yes, a number of "essential services" have been identified as needing to continue to operate under special dispensation during the lockdown, and telecoms falls within that. The details of the implementation of the dispensation may be nuanced. Experience will tell us more in the coming days. Mark.
--------------------------------------------------------------------------- Peter Beckman Internet Guy beckman@angryox.com http://www.angryox.com/ ---------------------------------------------------------------------------
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. Thanks, Sabri ----- On Mar 23, 2020, at 1:26 PM, Eric Tykwinski <eric-list@truenet.com> wrote:
I’ve already been playing with YubiKeys, but sadly Google Titan wouldn't work with Windows Hello. Might be something I was doing wrong...
Sincerely,
Eric Tykwinski TrueNet, Inc. P: 610-429-8300
On Mar 23, 2020, at 4:21 PM, Peter Beckman < [ mailto:beckman@angryox.com | beckman@angryox.com ] > wrote:
Software-based TOTP offer more security than no one-time passwords, but admittedly less than the physical tokens. Google Authenticator, Authy, 1Password, LastPass all support TOTP.
On Mon, 23 Mar 2020, Alexandre Petrescu wrote:
I dont know where are people about supporting VPN and one-time passwords on tokens.
At my work place a few people dont have tokens (OTP - One Time PAsswords). The reserve of these tokens has been exhausted. NEw ones are being on order. Until then some people cant get on VPN.
Some people forgot their token on their desk and had to to travel to office to get it, a thing not good to do to go to office now.
Some (not sure) might have issues with syncing these devices. An OTP token has a certain skew about clock, and a battery that lasts long. Hopefully, one's token has been synchronised recently and the battery is new. The length of time one cant go to office might be anywhere between 21 days (announced) and 2 months (experrience eg in Wuhan still closed). Some times the synching of clock can be performed remotely, and some 'coin' batteries can be replaced by the person with skill and tools, could be extracted from a quartz watch for example.
An OTP device can be of many kinds. Some people keep OTPs on paper (I did some time ago). Some OTP devices are like Japanese 'tamaguchi' format, others like a credit card format.
Alex, LF/HF 3
Le 23/03/2020 à 20:47, Mark Tinka a écrit :
On 23/Mar/20 21:20, Peter Beckman wrote:
But also:
"The categories of people who will be exempted from this lockdown are... those involved in the production, distribution and supply of... telecommunications services"
[ https://www.cnbcafrica.com/news/2020/03/23/breaking-nationwide-lockdown-anno... | https://www.cnbcafrica.com/news/2020/03/23/breaking-nationwide-lockdown-anno... ] I think most anyone on this list could be considered exempt. I do hope the same will be true should our respective local and national governments take similar action.
Yes, a number of "essential services" have been identified as needing to continue to operate under special dispensation during the lockdown, and telecoms falls within that. The details of the implementation of the dispensation may be nuanced. Experience will tell us more in the coming days. Mark.
--------------------------------------------------------------------------- Peter Beckman Internet Guy [ mailto:beckman@angryox.com | beckman@angryox.com ] [ http://www.angryox.com/ | http://www.angryox.com/ ] ---------------------------------------------------------------------------
On 3/23/20 3:53 PM, Sabri Berisha wrote:
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.
One of the things that got lost in the Webauthn stuff is that passwords per se are not bad. It's passwords being sent over the wire. In combination with reuse, that is the actual problem. Webauthn supposedly allows use of passwords to unlock a local credential store, but it is so heavily focused dongles that it's really hard to figure out for a normal website that just want to get rid of the burden of remote passwords. Mike
On Mon, Mar 23, 2020 at 7:00 PM Michael Thomas <mike@mtcc.com> wrote:
On 3/23/20 3:53 PM, Sabri Berisha wrote:
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.
this is not: "yubikey is bad" as much as: "The user using the yubikey is bad" Admittedly perhaps: "every time new token" sucks, and that's what (I think michael thomas is saying below), but certainly the yubikey could have been used for TOTP instead of HOTP and the user in question would have been out of luck, right? :) Almost all security 'features' are a trade-off between: "get stuff done" and "get stuff done with an extra hop", making the 'extra hop' as simple and natural as possible makes people less likely to do dumb things like: 1) pregen a crapload of tokens, store them on their probably compromised laptop... 2) aim a webcam at their rsa token and watch the change remotely 3) hot-dog and sipping-bird toy to touch the thingy on their yubikey token every X seconds...
One of the things that got lost in the Webauthn stuff is that passwords per se are not bad. It's passwords being sent over the wire. In combination with reuse, that is the actual problem. Webauthn supposedly allows use of passwords to unlock a local credential store, but it is so heavily focused dongles that it's really hard to figure out for a normal website that just want to get rid of the burden of remote passwords.
Mike
I don't see SKEY style OTP lists as inherently bad. "its how you do it" which concerns me, not that it is done. -G On Tue, Mar 24, 2020 at 9:33 AM Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Mon, Mar 23, 2020 at 7:00 PM Michael Thomas <mike@mtcc.com> wrote:
On 3/23/20 3:53 PM, Sabri Berisha wrote:
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.
this is not: "yubikey is bad" as much as: "The user using the yubikey is bad" Admittedly perhaps: "every time new token" sucks, and that's what (I think michael thomas is saying below), but certainly the yubikey could have been used for TOTP instead of HOTP and the user in question would have been out of luck, right? :)
Almost all security 'features' are a trade-off between: "get stuff done" and "get stuff done with an extra hop", making the 'extra hop' as simple and natural as possible makes people less likely to do dumb things like: 1) pregen a crapload of tokens, store them on their probably compromised laptop... 2) aim a webcam at their rsa token and watch the change remotely 3) hot-dog and sipping-bird toy to touch the thingy on their yubikey token every X seconds...
One of the things that got lost in the Webauthn stuff is that passwords per se are not bad. It's passwords being sent over the wire. In combination with reuse, that is the actual problem. Webauthn supposedly allows use of passwords to unlock a local credential store, but it is so heavily focused dongles that it's really hard to figure out for a normal website that just want to get rid of the burden of remote passwords.
Mike
On Mon, Mar 23, 2020 at 7:34 PM George Michaelson <ggm@algebras.org> wrote:
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 :(
-G
On Tue, Mar 24, 2020 at 9:33 AM Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Mon, Mar 23, 2020 at 7:00 PM Michael Thomas <mike@mtcc.com> wrote:
On 3/23/20 3:53 PM, Sabri Berisha wrote:
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.
this is not: "yubikey is bad" as much as: "The user using the yubikey is bad" Admittedly perhaps: "every time new token" sucks, and that's what (I think michael thomas is saying below), but certainly the yubikey could have been used for TOTP instead of HOTP and the user in question would have been out of luck, right? :)
Almost all security 'features' are a trade-off between: "get stuff done" and "get stuff done with an extra hop", making the 'extra hop' as simple and natural as possible makes people less likely to do dumb things like: 1) pregen a crapload of tokens, store them on their probably compromised laptop... 2) aim a webcam at their rsa token and watch the change remotely 3) hot-dog and sipping-bird toy to touch the thingy on their yubikey token every X seconds...
One of the things that got lost in the Webauthn stuff is that passwords per se are not bad. It's passwords being sent over the wire. In combination with reuse, that is the actual problem. Webauthn supposedly allows use of passwords to unlock a local credential store, but it is so heavily focused dongles that it's really hard to figure out for a normal website that just want to get rid of the burden of remote passwords.
Mike
On 3/23/20 3:53 PM, Sabri Berisha wrote: 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. 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 -- William Herrin bill@herrin.us https://bill.herrin.us/
On Mon, Mar 23, 2020 at 7:57 PM William Herrin <bill@herrin.us> wrote:
On 3/23/20 3:53 PM, Sabri Berisha wrote: 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...
Regards, Bill Herrin
-- William Herrin bill@herrin.us https://bill.herrin.us/
-- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf
On Mon, Mar 23, 2020 at 5:16 PM Warren Kumari <warren@kumari.net> wrote:
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 -- William Herrin bill@herrin.us https://bill.herrin.us/
On Mon, Mar 23, 2020 at 18:50 William Herrin <bill@herrin.us> wrote:
On Mon, Mar 23, 2020 at 5:16 PM Warren Kumari <warren@kumari.net> wrote:
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)
Regards, Bill Herrin
-- William Herrin bill@herrin.us https://bill.herrin.us/
-- "Genius might be described as a supreme capacity for getting its possessors into trouble of all kinds." -- Samuel Butler
On Mon, Mar 23, 2020 at 20:08 Michael Loftis <mloftis@wgops.com> wrote:
On Mon, Mar 23, 2020 at 18:50 William Herrin <bill@herrin.us> wrote:
On Mon, Mar 23, 2020 at 5:16 PM Warren Kumari <warren@kumari.net> wrote:
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.
Regards, Bill Herrin
-- William Herrin bill@herrin.us https://bill.herrin.us/
--
"Genius might be described as a supreme capacity for getting its possessors into trouble of all kinds." -- Samuel Butler
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. On Mon, 23 Mar 2020 22:22:18 -0400, Michael Loftis wrote:
[1 <text/plain; UTF-8 (quoted-printable)>] On Mon, Mar 23, 2020 at 20:08 Michael Loftis <mloftis@wgops.com> wrote:
On Mon, Mar 23, 2020 at 18:50 William Herrin <bill@herrin.us> wrote:
On Mon, Mar 23, 2020 at 5:16 PM Warren Kumari <warren@kumari.net> wrote:
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.
Regards, Bill Herrin
-- William Herrin bill@herrin.us https://bill.herrin.us/
--
"Genius might be described as a supreme capacity for getting its possessors into trouble of all kinds." -- Samuel Butler [2 <text/html; UTF-8 (quoted-printable)>]
-- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici wb2una covici@ccs.covici.com
To give it a mention, I’m a big fan of Duo Security. Auth requests are sent out-of-band to an authenticated app on your mobile device, you verify the request, then that’s sent back to the duo server and then to the requestor. I’ve used it with ssh and radius and it worked well. Microsoft’s Authenticator app is interesting - a number is displayed in the app you’re trying to authenticate to, and you have to pick the same number in the app to prove before the app authenticates the request…but I don’t see that tech as being adopted by the networking folks... In the end it comes down to what you need to secure, and how much effort you’re going to put into it. A yubikey/etc mitigates a risk of credential theft in a cheap, portable way that is frequently Good Enough. John
On Mar 24, 2020, at 2:55 AM, John Covici <covici@ccs.covici.com> wrote:
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.
On Mon, 23 Mar 2020 22:22:18 -0400, Michael Loftis wrote:
[1 <text/plain; UTF-8 (quoted-printable)>] On Mon, Mar 23, 2020 at 20:08 Michael Loftis <mloftis@wgops.com> wrote:
On Mon, Mar 23, 2020 at 18:50 William Herrin <bill@herrin.us> wrote:
On Mon, Mar 23, 2020 at 5:16 PM Warren Kumari <warren@kumari.net> wrote:
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.
Regards, Bill Herrin
-- William Herrin bill@herrin.us https://bill.herrin.us/
--
"Genius might be described as a supreme capacity for getting its possessors into trouble of all kinds." -- Samuel Butler [2 <text/html; UTF-8 (quoted-printable)>]
-- Your life is like a penny. You're going to lose it. The question is: How do you spend it?
John Covici wb2una covici@ccs.covici.com
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. On Mon, Mar 23, 2020 at 8:51 PM William Herrin <bill@herrin.us> wrote:
On Mon, Mar 23, 2020 at 5:16 PM Warren Kumari <warren@kumari.net> wrote:
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
-- William Herrin bill@herrin.us https://bill.herrin.us/
On Mar 23, 2020, at 8:48 PM, William Herrin <bill@herrin.us> wrote:
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.
https://www.yubico.com/products/identifying-your-yubikey/ <https://www.yubico.com/products/identifying-your-yubikey/> The (presumably) Yubico OTP/OATH/HOTP string from a Yubikey that you may have picked up six years ago on a lark doesn’t even begin to scratch the surface. The integration with FIDO2 in the low-end models in OpenSSH 8.2 in particular is very spiffy (and not to be confused with PIV or OpenPGP mode. -r
On Mon, Mar 23, 2020 at 4:53 PM Sabri Berisha <sabri@cluecentral.net> wrote:
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.
Thanks,
This is an artifact of a poor implementation, not of a yubikey or any other security. Yubikeys support MANY methods of authentication. I have a number of them, a couple of them are setup for TOTP (using yubico authenticator), FIDO (native), and use the GPG functionality for ssh public key auth via agent. Pre-generating or replaying will not work with any of those methods. So saying "Yubikeys are not very secure" is very incorrect. The specific deployment decisions weren't great in your specific case. Any OTP system based on incrementing counters could be abused in this manner if the OTP keys can be generated rapidly and saved. TOTP is the common method for solving this with 2FA. Yubikeys also support a number of challenge/response type authentications (which is effectively what my GPG setup does, and what FIDO sort of does)
On Mon, Mar 23, 2020 at 6:53 PM Sabri Berisha <sabri@cluecentral.net> wrote:
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
Thanks,
Sabri
----- On Mar 23, 2020, at 1:26 PM, Eric Tykwinski <eric-list@truenet.com> wrote:
I’ve already been playing with YubiKeys, but sadly Google Titan wouldn't work with Windows Hello. Might be something I was doing wrong...
Sincerely,
Eric Tykwinski TrueNet, Inc. P: 610-429-8300
On Mar 23, 2020, at 4:21 PM, Peter Beckman <beckman@angryox.com> wrote:
Software-based TOTP offer more security than no one-time passwords, but admittedly less than the physical tokens. Google Authenticator, Authy, 1Password, LastPass all support TOTP.
On Mon, 23 Mar 2020, Alexandre Petrescu wrote:
I dont know where are people about supporting VPN and one-time passwords on tokens.
At my work place a few people dont have tokens (OTP - One Time PAsswords). The reserve of these tokens has been exhausted. NEw ones are being on order. Until then some people cant get on VPN.
Some people forgot their token on their desk and had to to travel to office to get it, a thing not good to do to go to office now.
Some (not sure) might have issues with syncing these devices. An OTP token has a certain skew about clock, and a battery that lasts long. Hopefully, one's token has been synchronised recently and the battery is new. The length of time one cant go to office might be anywhere between 21 days (announced) and 2 months (experrience eg in Wuhan still closed). Some times the synching of clock can be performed remotely, and some 'coin' batteries can be replaced by the person with skill and tools, could be extracted from a quartz watch for example.
An OTP device can be of many kinds. Some people keep OTPs on paper (I did some time ago). Some OTP devices are like Japanese 'tamaguchi' format, others like a credit card format.
Alex, LF/HF 3
Le 23/03/2020 à 20:47, Mark Tinka a écrit :
On 23/Mar/20 21:20, Peter Beckman wrote:
But also:
"The categories of people who will be exempted from this lockdown are... those involved in the production, distribution and supply of... telecommunications services"
https://www.cnbcafrica.com/news/2020/03/23/breaking-nationwide-lockdown-anno... I think most anyone on this list could be considered exempt. I do hope the same will be true should our respective local and national governments take similar action.
Yes, a number of "essential services" have been identified as needing to continue to operate under special dispensation during the lockdown, and telecoms falls within that. The details of the implementation of the dispensation may be nuanced. Experience will tell us more in the coming days. Mark.
--------------------------------------------------------------------------- Peter Beckman Internet Guy beckman@angryox.com http://www.angryox.com/ ---------------------------------------------------------------------------
-- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf
On Mar 23, 2020, at 16:50 , Warren Kumari <warren@kumari.net> wrote:
On Mon, Mar 23, 2020 at 6:53 PM Sabri Berisha <sabri@cluecentral.net> wrote:
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. 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
On Mon, Mar 23, 2020 at 8:03 PM Owen DeLong <owen@delong.com> wrote:
On Mar 23, 2020, at 16:50 , Warren Kumari <warren@kumari.net> wrote:
On Mon, Mar 23, 2020 at 6:53 PM Sabri Berisha <sabri@cluecentral.net> wrote:
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
Owen
-- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf
On Mar 23, 2020, at 17:24 , Warren Kumari <warren@kumari.net> wrote:
On Mon, Mar 23, 2020 at 8:03 PM Owen DeLong <owen@delong.com <mailto:owen@delong.com>> wrote:
On Mar 23, 2020, at 16:50 , Warren Kumari <warren@kumari.net> wrote:
On Mon, Mar 23, 2020 at 6:53 PM Sabri Berisha <sabri@cluecentral.net> wrote:
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 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.
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 ….
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. On Mon, Mar 23, 2020 at 9:24 PM Owen DeLong <owen@delong.com> wrote:
On Mar 23, 2020, at 17:24 , Warren Kumari <warren@kumari.net> wrote:
On Mon, Mar 23, 2020 at 8:03 PM Owen DeLong <owen@delong.com> wrote:
On Mar 23, 2020, at 16:50 , Warren Kumari <warren@kumari.net> wrote:
On Mon, Mar 23, 2020 at 6:53 PM Sabri Berisha <sabri@cluecentral.net> wrote:
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
On Mon, Mar 23, 2020 at 19:25 Owen DeLong <owen@delong.com> wrote:
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.
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.
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 ….
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
--
"Genius might be described as a supreme capacity for getting its possessors into trouble of all kinds." -- Samuel Butler
On Tue, 24 Mar 2020 at 06:50, Mark Tinka <mark.tinka@seacom.mu> wrote:
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? On Tue, 24 Mar 2020 at 10:54, Warren Kumari <warren@kumari.net> wrote:
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....
Wow, update to post-it note password in the top drawer.. hilarious and sad
On 24/Mar/20 02:10, Joshua D'Alton wrote:
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?
Well, lockdown basically means all civil aviation is shutdown, with the exception of cargo transport. But if you have infrastructure down here, you probably have local hands that you can call on to support you, which is what I was relaying to those it may concern. At any rate, I'm not sure anyone should (or wants to) be traveling anywhere at this time, national and international. But that's just me :-). Mark
On Monday, 23 March, 2020 14:21, Peter Beckman <beckman@angryox.com> wrote:
Software-based TOTP offer more security than no one-time passwords, but admittedly less than the physical tokens. Google Authenticator, Authy, 1Password, LastPass all support TOTP.
Hardware tokens are nothing more than dedicated hardware TOTP devices with perhaps a few additional parameters programmed at manufacturing time. Example, RSAID keyfobs are nothing more than TOTP generators with manufacturer programmed secrets and dedicated clock and display hardware with no external interface which permits access to the secret. -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.
On 23/Mar/20 22:39, Keith Medcalf wrote:
Hardware tokens are nothing more than dedicated hardware TOTP devices with perhaps a few additional parameters programmed at manufacturing time. Example, RSAID keyfobs are nothing more than TOTP generators with manufacturer programmed secrets and dedicated clock and display hardware with no external interface which permits access to the secret.
For some of my banks, OTP tokens are issued via their device apps. I used to have physical key fobs for that; those are now gone. Admittedly, not all of my banks have made the transition. On the other hand, many of the banks have moved on to support Face ID and QR code verification via device apps. Not specific to VPN access management, but in the same vein. Mark.
I think that’s the major sticky point, I would hope we could all agree on one thing, but that also leaves one entry point of failure. Hopefully we can all agree that FIDO2, OAUTH2, et al, with be a winner in the long run so everything can just use one simple authentication mechanism. Sincerely, Eric Tykwinski TrueNet, Inc. P: 610-429-8300
On Mar 23, 2020, at 5:23 PM, Mark Tinka <mark.tinka@seacom.mu> wrote:
On 23/Mar/20 22:39, Keith Medcalf wrote:
Hardware tokens are nothing more than dedicated hardware TOTP devices with perhaps a few additional parameters programmed at manufacturing time. Example, RSAID keyfobs are nothing more than TOTP generators with manufacturer programmed secrets and dedicated clock and display hardware with no external interface which permits access to the secret.
For some of my banks, OTP tokens are issued via their device apps. I used to have physical key fobs for that; those are now gone.
Admittedly, not all of my banks have made the transition. On the other hand, many of the banks have moved on to support Face ID and QR code verification via device apps.
Not specific to VPN access management, but in the same vein.
Mark.
Both Fido and OAuth2 are inherently insecure. While they may be better than nothing at all, they are only very slightly better than proper password selection and management. -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.
-----Original Message----- From: NANOG <nanog-bounces@nanog.org> On Behalf Of Eric Tykwinski Sent: Monday, 23 March, 2020 15:55 To: Mark Tinka <mark.tinka@seacom.mu> Cc: nanog@nanog.org Subject: Re: South Africa On Lockdown - Coronavirus - Update!
I think that’s the major sticky point, I would hope we could all agree on one thing, but that also leaves one entry point of failure. Hopefully we can all agree that FIDO2, OAUTH2, et al, with be a winner in the long run so everything can just use one simple authentication mechanism.
Sincerely,
Eric Tykwinski TrueNet, Inc. P: 610-429-8300
On Mar 23, 2020, at 5:23 PM, Mark Tinka <mark.tinka@seacom.mu <mailto:mark.tinka@seacom.mu> > wrote:
On 23/Mar/20 22:39, Keith Medcalf wrote:
Hardware tokens are nothing more than dedicated hardware TOTP devices with perhaps a few additional parameters programmed at manufacturing time. Example, RSAID keyfobs are nothing more than TOTP generators with manufacturer programmed secrets and dedicated clock and display hardware with no external interface which permits access to the secret.
For some of my banks, OTP tokens are issued via their device apps. I used to have physical key fobs for that; those are now gone.
Admittedly, not all of my banks have made the transition. On the other hand, many of the banks have moved on to support Face ID and QR code verification via device apps.
Not specific to VPN access management, but in the same vein.
Mark.
I don't know about Fido, but i've been making that point about Oauth for a very long time. As a browser mechanism which implements a sandbox it's fine. But when you have apps that can reach out of the sandbox it is definitely not fine. Mike On 3/23/20 2:59 PM, Keith Medcalf wrote:
Both Fido and OAuth2 are inherently insecure.
While they may be better than nothing at all, they are only very slightly better than proper password selection and management.
I see no possible future outcome in which "one simple authentication mechanism" could ever be remotely close to reasonably secure. On Mon, Mar 23, 2020 at 5:57 PM Eric Tykwinski <eric-list@truenet.com> wrote:
I think that’s the major sticky point, I would hope we could all agree on one thing, but that also leaves one entry point of failure. Hopefully we can all agree that FIDO2, OAUTH2, et al, with be a winner in the long run so everything can just use one simple authentication mechanism.
Sincerely,
Eric Tykwinski TrueNet, Inc. P: 610-429-8300
On Mar 23, 2020, at 5:23 PM, Mark Tinka <mark.tinka@seacom.mu> wrote:
On 23/Mar/20 22:39, Keith Medcalf wrote:
Hardware tokens are nothing more than dedicated hardware TOTP devices with perhaps a few additional parameters programmed at manufacturing time. Example, RSAID keyfobs are nothing more than TOTP generators with manufacturer programmed secrets and dedicated clock and display hardware with no external interface which permits access to the secret.
For some of my banks, OTP tokens are issued via their device apps. I used to have physical key fobs for that; those are now gone.
Admittedly, not all of my banks have made the transition. On the other hand, many of the banks have moved on to support Face ID and QR code verification via device apps.
Not specific to VPN access management, but in the same vein.
Mark.
I guess I wasn’t as detailed as should be, multi factor authentication should hopefully have 1 standard which will work for everything. So we have an app on our phone to authenticate after a username/password which give a 6 digit key, or we use a hardware based key to sign a OTP. Really either doesn’t matter, but trying to get endu sers to switch between each for every login is going to hamper acceptance in the large scale. MailOps, would probably the best example, as the spam is generated simply from usually not having anything because it’s just too difficult to implement. Sincerely, Eric Tykwinski TrueNet, Inc. P: 610-429-8300
On Mar 23, 2020, at 6:02 PM, Tom Beecher <beecher@beecher.cc> wrote:
I see no possible future outcome in which "one simple authentication mechanism" could ever be remotely close to reasonably secure.
On Mon, Mar 23, 2020 at 5:57 PM Eric Tykwinski <eric-list@truenet.com <mailto:eric-list@truenet.com>> wrote: I think that’s the major sticky point, I would hope we could all agree on one thing, but that also leaves one entry point of failure. Hopefully we can all agree that FIDO2, OAUTH2, et al, with be a winner in the long run so everything can just use one simple authentication mechanism.
Sincerely,
Eric Tykwinski TrueNet, Inc. P: 610-429-8300
On Mar 23, 2020, at 5:23 PM, Mark Tinka <mark.tinka@seacom.mu <mailto:mark.tinka@seacom.mu>> wrote:
On 23/Mar/20 22:39, Keith Medcalf wrote:
Hardware tokens are nothing more than dedicated hardware TOTP devices with perhaps a few additional parameters programmed at manufacturing time. Example, RSAID keyfobs are nothing more than TOTP generators with manufacturer programmed secrets and dedicated clock and display hardware with no external interface which permits access to the secret.
For some of my banks, OTP tokens are issued via their device apps. I used to have physical key fobs for that; those are now gone.
Admittedly, not all of my banks have made the transition. On the other hand, many of the banks have moved on to support Face ID and QR code verification via device apps.
Not specific to VPN access management, but in the same vein.
Mark.
how did 'africa on lockdown' get sidetracked into OTP conversations?
Le 23/03/2020 à 23:37, Christopher Morrow a écrit :
how did 'africa on lockdown' get sidetracked into OTP conversations?
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
On Tue, Mar 24, 2020 at 6:21 AM Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:
Le 23/03/2020 à 23:37, Christopher Morrow a écrit :
how did 'africa on lockdown' get sidetracked into OTP conversations?
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?
third planet from the sun... so they tell me.
On Tue, Mar 24, 2020 at 6:22 AM Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote:
Mr. Morrow - where are you situated approximately?
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 <https://www.linkedin.com/in/petrescu/> to spout off massively uninformed bullshit non-stop because no one else will listen. NANOG-L mods: it's time to show some leadership.
So just to bring this back on-topic with an update - the South African gubbermint have classified telecoms as an essential service. Provided you possess the right authorization documentation, you can go out and perform tasks to that keep the bits moving. Of course, local operators may have finer details about how all this gets done without compromising health & safety for their staff, but for those with infrastructure down this way, it's not doom and gloom in our respect. Mark.
So just to bring this back on-topic with an update - the South African gubbermint have classified telecoms as an essential service. Provided you possess the right authorization documentation, you can go out and perform tasks that keep the bits moving. Of course, local operators may have finer details about how all this gets done without compromising health & safety for their staff, but for those of you with infrastructure down this way, it's not doom and gloom in our respect. Mark.
This is my last post on this email list. It is true - I am not a network operator. In honesty I think I never claimed to be one. I do not understand the word 'spout'. You think this has nothing to do with me - I unsubscrbe. Sorry for disturbing, Alex, LF/HF 1 Le 24/03/2020 à 14:47, Paul WALL a écrit :
On Tue, Mar 24, 2020 at 6:22 AM Alexandre Petrescu <alexandre.petrescu@gmail.com <mailto:alexandre.petrescu@gmail.com>> wrote:
Mr. Morrow - where are you situated approximately?
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 <https://www.linkedin.com/in/petrescu/> to spout off massively uninformed bullshit non-stop because no one else will listen.
NANOG-L mods: it's time to show some leadership.
Alexandre- I do hope that you reconsider your decision to unsubscribe. Many of us post massively uninformed bullshit here on a regular basis, myself included. I don't think anything you have posted here rose to that curious standard. Be well! On Tue, Mar 24, 2020 at 11:47 AM Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote:
This is my last post on this email list.
It is true - I am not a network operator. In honesty I think I never claimed to be one.
I do not understand the word 'spout'.
You think this has nothing to do with me - I unsubscrbe.
Sorry for disturbing,
Alex, LF/HF 1
Le 24/03/2020 à 14:47, Paul WALL a écrit :
On Tue, Mar 24, 2020 at 6:22 AM Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote:
Mr. Morrow - where are you situated approximately?
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 <https://www.linkedin.com/in/petrescu/> to spout off massively uninformed bullshit non-stop because no one else will listen.
NANOG-L mods: it's time to show some leadership.
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 not how we should act in under pressure
On 2020-03-24 18:59, Randy Bush wrote:
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 not how we should act in under pressure +1
NANOG very often inspired me and my friends as the best example of the discussion, process of solving various problems related to internet in general. And now everybody around the world got major, similar problem. And someone now says, go away from here, is this a maillist for North American operators? If this is really decision supported by the majority(which i doubt), i would like to know that. For example, a reminder that the VPN is very poorly balanced over LAG - was very useful. And like this short message about South Africa was highly useful for my country of residence, Lebanon, too. We are under full, quite severe lock-down, with fines, checkpoints and etc. Several ISPs here who kept NOC support (single person) near server room, in office - got fined too, as usual businesses, because there is no such regulation to allow them to run. This is terrible, because in such circumstances ISP cannot continue to provide reliable service, and their customers without internet might not keep isolation. Therefore, I carefully read this group, how everyone solves similar problems. And this is why, how is it solved in North America or other countries or regions can be an example for other countries.
And like this short message about South Africa was highly useful for my country of residence, Lebanon, too. We are under full, quite severe lock-down, with fines, checkpoints and etc. Several ISPs here who kept NOC support (single person) near server room, in office - got fined too, as usual businesses, because there is no such regulation to allow them to run.
while i have visited, i claim zero understanding of your culture. but gossip from friends is that there is a larger than usual communication gap between the internet industry and government. and, as far as i have been told, it is not for a lack of effort. perhaps teh culture will learn how critical the net is and what it needs to be maintained. almost all our cultures have gaps; but some worse than others. we will all learn lessons in the coming many months of plague. i know an office which lost key engineers last year because they would not let them work remotely. now the entire company is working remotely, and successfully. randy
On 24/Mar/20 22:48, Randy Bush wrote:
almost all our cultures have gaps; but some worse than others. we will all learn lessons in the coming many months of plague. i know an office which lost key engineers last year because they would not let them work remotely. now the entire company is working remotely, and successfully.
The Coronavirus is amplifying and accelerating the new economy that is burgeoning at the borders. With some luck, those that need to pay attention, are. Mark.
Don’t hold your breath :-(.
On Mar 24, 2020, at 4:55 PM, Mark Tinka <mark.tinka@seacom.mu> wrote:
On 24/Mar/20 22:48, Randy Bush wrote:
almost all our cultures have gaps; but some worse than others. we will all learn lessons in the coming many months of plague. i know an office which lost key engineers last year because they would not let them work remotely. now the entire company is working remotely, and successfully.
The Coronavirus is amplifying and accelerating the new economy that is burgeoning at the borders.
With some luck, those that need to pay attention, are.
Mark.
On 25/Mar/20 22:13, Paul Nash wrote:
Don’t hold your breath :-(.
On the plus side, I am quite pleased to see how well this Internet thing we all built is coming into its own, these past couple of weeks, taking over as the traditions we've been accustomed to are subdued. I know the VoD providers have dumbed down their streaming resolution across the board to "keep things afloat", and even though I didn't think they were going to cause any issues, it's good to see how well things are holding up, globally. Also, considering everyone is, pretty much, working from home, the Internet isn't dying as it randomly does throughout a typical working week. Human MIT (maintenance-induced trouble) continues to be the leading cause of outages, it seems :-). Mark.
On Tue, Mar 31, 2020 at 6:56 AM Mark Tinka <mark.tinka@seacom.mu> wrote:
Also, considering everyone is, pretty much, working from home, the Internet isn't dying as it randomly does throughout a typical working week. Human MIT (maintenance-induced trouble) continues to be the leading cause of outages, it seems :-).
'Provocative maintenance' is the term I recall from back in the day. Basically, "It isn't broken, but we can fix that." :-)
On Tue, Mar 24, 2020 at 10:01 AM Randy Bush <randy@psg.com> wrote:
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 not how we should act in under pressure
Returning late to the fray, so apologies for the thread necromancy if ever there was a time I wished I could upvote messages on NANOG, this would be it! ^_^; Thank you, Randy, and also to you, Beecher, for calling out the need for us to be especially mindful of the need to be liberal in what we accept, and conservative in what we send during these highly stressful and trying times. As someone who has been part of the community since the comm-priv days, I would recommend that "Paul Wall" might want to think carefully about calling on the moderators to take action. Would you want to risk them subjecting your activity on the list to the same scrutiny, and hold you to the same standard? Stay safe, stay sane, stay healthy, ...and stay home, everybody! ^_^ Matt
On 24/Mar/20 15:47, Paul WALL wrote:
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 <https://www.linkedin.com/in/petrescu/> to spout off massively uninformed bullshit non-stop because no one else will listen.
The Internet is the same version in Europe as it is in North America. Breakage on either side of the pond will impact the other side. Physical infrastructure is what separated the success of countries. The Internet is the single biggest thing that levels the playing field, globally. Mark.
On 24/Mar/20 00:19, Eric Tykwinski wrote:
I guess I wasn’t as detailed as should be, multi factor authentication should hopefully have 1 standard which will work for everything. So we have an app on our phone to authenticate after a username/password which give a 6 digit key, or we use a hardware based key to sign a OTP. Really either doesn’t matter, but trying to get endu sers to switch between each for every login is going to hamper acceptance in the large scale.
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.
participants (24)
-
Alexandre Petrescu -
Christopher Morrow -
Denys Fedoryshchenko -
Eric Tykwinski -
George Michaelson -
Jay Farrell -
John Covici -
John Kinsella -
Joshua D'Alton -
Keith Medcalf -
Mark Tinka -
Matthew Petach -
Michael Loftis -
Michael Thomas -
Owen DeLong -
Paul Nash -
Paul WALL -
Peter Beckman -
Randy Bush -
Rob Seastrom -
Sabri Berisha -
Tom Beecher -
Warren Kumari -
William Herrin