5 ms·

No, it's not. We need less shoddy practices to develop software, e.g. mandatory 4-eyes process for security-critical changes, thread modelling, and maybe more H

by v1ne 2y ago

No, it's not. We need less shoddy practices to develop software, e.g. mandatory 4-eyes process for security-critical changes, thread modelling, and maybe more Hardware Security Modules that encrypt critical information. And if you need a second factor, I'm sure any smartphone-based TOTP will do. People already guard their smartphone well. No extra key fob needed.

brnt 2y ago
> People already guard their smartphone well. Keychain too. Something irks me about concentrating all access management on a device that people also use for tons of commercial, data slurping apps and games. Banks, national governments, shops; they all want me to use their app as 2F. To me it seems precisely the opposite: the phone is not a good place for this.
- Terr_ 2y ago
  Amen: TOTP should be on a device with a much much smaller attack surface and supply-chain vulnerabilities. This was many years back, but I remember searching to see if there was some kind of hardened not-a-phone appliance, without much luck.
  - rightbyte 2y ago
    The banks used to hand out key response generation devices for that. No interface at all but the buttons. There even was a paper version where you scratched to get the key. Like, it was way better.
    - fph 2y ago
      In the EU these hardware keyfobs are now forbidden for banking because they are considered less secure than app-based 2FA. The reason is that an app-based confirmation gives you the opportunity to review the transaction you are confirming; they can display "Are you sure you want to send 19.99 € to website.com with payment description 'subscription'?".
      - rightbyte 2y ago
        You could have a keyfob to identify and app to confirm.
      - AndyMcConachie 2y ago
        This is false. I use a hardware thingy that I put my Dutch bank card into that generates numbers for logins and purchases. I have the option of using an app or the hardware card reader. I use a one time generating password hardware keyfob to login to the Dutch Belastingdienst. They require it and I don't think there is an app I can use for this purpose.
        fph 2y ago
        If it requires a smartcard I assume this is a different protocol, CAP. The introduction to this paper https://www.researchgate.net/publication/355241124_PSD2_Compliant_Hardware_Token_for_Digital_Banking https://www.researchgate.net/publication/355241124_PSD2_Comp... (not mine) explains the system a little: the old hardware tokens in fig. 1 and 2 are those that cannot be used anymore; I assume you have something like the device in fig. 4?
        brnt 2y ago
        All Dutch Banks are moving customers to their apps now.
        kseistrup 2y ago
        I agree. Danish banks, because they use the national MitID authorisation, accept MFA via app, code generator, or a chip device: https://www.mitid.dk/en-gb/get-started-with-mitid/mitid-authenticators/ https://www.mitid.dk/en-gb/get-started-with-mitid/mitid-auth...
        eythian 2y ago
        There's a DigID app that I use for the Belastingdienst (and all other overheid things), I don't have a OTP keyfob at all.
      - Terr_ 2y ago
        > In the EU these hardware keyfobs are now forbidden for banking [...] an app-based confirmation gives you the opportunity to review the transaction you are confirming; I'm confused, that seems like it confuses two independent aspects: 1. Whether the TOTP code comes from a fob-device versus a phone-device. 2. Whether some interactive interface you're using gives you a chance to see/confirm what you're about to authorize or not. A phone app can lie to you about the transaction you're about to authorize regardless of whether the TOTP code was transcribed from an external device, transcribed from another app on the same phone, or auto-filled by itself.
- amne 2y ago
  I can unlock and drive my car with my phone and the house has smart locks. What is this keychain you keep mentioning? I know the app but I don't think that's what you mean.
dns_snek 2y ago
> I'm sure any smartphone-based TOTP will do No it won't. Like the article states, I also believe that phishing resistance is a critical property of 2FA systems. This is something that TOTP will never be able to provide. We don't need Yubikey the brand, but we do need security keys (i.e. FIDO) as a concept.
Delphiza 2y ago
I have a yubikey. It's okay but I don't take it with me. When I'm out I use my phone with a MFA app, and would never tie my MFA to a hardware dongle that is likely not to be on my person when I need it.
- krisoft 2y ago
  > It's okay but I don't take it with me. Sounds like that is the problem? I have mine on my keyring. (and have a backup in a safe.) > would never tie my MFA to a hardware dongle that is likely not to be on my person when I need it. The solution is to have it with you.
  - attendant3446 2y ago
    The problem is that you need at least hardware tokens, one on you and one in a safe place as a backup. And I can't justify the cost of that.
    - jamesmotherway 2y ago
      I wasn't able to justify the potential cost of not having them.
kstenerud 2y ago
... Until you drop your phone and it breaks. And now you can't set up a new phone because you need to tap the notification sent to your old (now broken) phone in order to set up your new phone. I've already had this happen, which is why I use hardware keys now, and a backup phone.
- nine_k 2y ago
  Do you mean, you don't print these rescue codes which every 2FA thing keeps nagging you about? You don't have a printout in your wallet, or in your folder with important papers? Not even as a secure not in your password manager?..
  - kstenerud 2y ago
    Nope, because I was grandfathered into it when Google switched it on for everyone without saying anything. You can still access gmail and such; you just can't set up any more devices without having some kind of 2fa. Now I have a hardware key. I wouldn't dare keep rescue key codes (which can't be revoked) in my wallet.
    - nh2 2y ago
      Can't you just use them to revoke them?
      - nine_k 2y ago
        You can't revoke them if the paper is in the wrong hands, and you don't have a normal access to your account. (Well, they are much like a password in this regard.) It's just different risk profiles. Your biggest risk might be to drop your phone and lose all the 2FAs in a Google Auth app. Or your biggest risk might be losing your wallet to a thief or robber who is going to hijack your accounts.
        bootlooped 2y ago
        I think the chances of the kind of person who steals your wallet also being able to leverage pilfered two-factor authentication codes to hijack your accounts is almost zero.
whywhywhywhy 2y ago
> People already guard their smartphone well You guard it well, your carrier barely even tries to guard your number from being stolen. Once you have that you can get into Apple account SMS auth/iCloud passwords and keys.
donatj 2y ago
You can get as many eyes as you want on all changes. I don't think it will help much. This sort of thing usually happens because of a change in something completely benign, rather than "security-critical changes". We recently had a pretty major vulnerability exposed by a PEN test (thankfully) that was caused by a single misplaced NOT ! operator in a pretty simple function, maybe 20loc with 100% test coverage as counted by line. The problem case was untested because while tests touched 100% of lines, not all combinations of paths through the code were tested. The code had been written by myself about a year ago, and reviewed by four seasoned developers, none of whom spotted the issue. How many thousands of eyes are on OpenSSL and yet major world ending vulnerabilities still crop up? This might be a hot take, but you can make the process as painful as you like but at the end of the day, building secure software is nigh impossible. We should be putting less trust in software.
- OptionOfT 2y ago
  Would branch coverage have helped you here? And I think one of the approaches that helped me to write safer code is to parse, and not validate. That way drastically limit the situations we can get into where we forget to validate certain conditions. e.g. you have a User struct, and you want to do an action which requires you to validate whether the user is an admin. 2 options here * validate whether the user is an admin (which could happen multiple times when you're invoking distinct functions as part of a workflow) * parse the User into an AdminUser. If the user is an admin, the function will work, and then you can pass on your new struct into places that require an admin. If it fails, the user is not an admin. Now you have merged all your checks into 1 place.
  - donatj 2y ago
    Yeah, almost certainly. We had looked into enabling branch detection several years ago, but it had slowed our suite down to the point where we were not sure it was worth it. Maybe worth looking into again. I do generally like that technique of returning more vetted objects, but I'm not sure that it scales. Our users have close to one hundred different permissions based on the features their admin pays for, having an object for every type seems like a lot. Every combination of types is straight out. The original issue I was talking about I don't think could have been helped. It was an encoding problem that could have potentially lead to XSS injection with a very specific set of GET parameters. I was frankly surprised that the PEN testers managed to find it.
wepple 2y ago
TOTP is trivially phishable. Code security is orthogonal to end-user authentication methods. So, wrong on every count.
VoodooJuJu 2y ago
>And if you need a second factor, I'm sure any smartphone-based TOTP will do No, it won't, because TOTP doesn't protect against phishing, which remains a threat even if randomly-generated unique passwords are used. That's what U2F protects against, is phishing.
nobrains 2y ago
> 4-eyes process for security-critical changes Sounds good on paper, but not practical. Who decides what is a security-critical change?

by v1ne 2y ago

brnt 2y ago

> People already guard their smartphone well. Keychain too. Something irks me about concentrating all access management on a device that people also use for tons of commercial, data slurping apps and games. Banks, national governments, shops; they all want me to use their app as 2F. To me it seems precisely the opposite: the phone is not a good place for this.

Terr_ 2y ago
Amen: TOTP should be on a device with a much much smaller attack surface and supply-chain vulnerabilities. This was many years back, but I remember searching to see if there was some kind of hardened not-a-phone appliance, without much luck.
- rightbyte 2y ago
  The banks used to hand out key response generation devices for that. No interface at all but the buttons. There even was a paper version where you scratched to get the key. Like, it was way better.
  - fph 2y ago
    In the EU these hardware keyfobs are now forbidden for banking because they are considered less secure than app-based 2FA. The reason is that an app-based confirmation gives you the opportunity to review the transaction you are confirming; they can display "Are you sure you want to send 19.99 € to website.com with payment description 'subscription'?".
    - rightbyte 2y ago
      You could have a keyfob to identify and app to confirm.
    - AndyMcConachie 2y ago
      This is false. I use a hardware thingy that I put my Dutch bank card into that generates numbers for logins and purchases. I have the option of using an app or the hardware card reader. I use a one time generating password hardware keyfob to login to the Dutch Belastingdienst. They require it and I don't think there is an app I can use for this purpose.
      - fph 2y ago
        If it requires a smartcard I assume this is a different protocol, CAP. The introduction to this paper https://www.researchgate.net/publication/355241124_PSD2_Compliant_Hardware_Token_for_Digital_Banking https://www.researchgate.net/publication/355241124_PSD2_Comp... (not mine) explains the system a little: the old hardware tokens in fig. 1 and 2 are those that cannot be used anymore; I assume you have something like the device in fig. 4?
      - brnt 2y ago
        All Dutch Banks are moving customers to their apps now.
      - kseistrup 2y ago
        I agree. Danish banks, because they use the national MitID authorisation, accept MFA via app, code generator, or a chip device: https://www.mitid.dk/en-gb/get-started-with-mitid/mitid-authenticators/ https://www.mitid.dk/en-gb/get-started-with-mitid/mitid-auth...
      - eythian 2y ago
        There's a DigID app that I use for the Belastingdienst (and all other overheid things), I don't have a OTP keyfob at all.
    - Terr_ 2y ago
      > In the EU these hardware keyfobs are now forbidden for banking [...] an app-based confirmation gives you the opportunity to review the transaction you are confirming; I'm confused, that seems like it confuses two independent aspects: 1. Whether the TOTP code comes from a fob-device versus a phone-device. 2. Whether some interactive interface you're using gives you a chance to see/confirm what you're about to authorize or not. A phone app can lie to you about the transaction you're about to authorize regardless of whether the TOTP code was transcribed from an external device, transcribed from another app on the same phone, or auto-filled by itself.
amne 2y ago
I can unlock and drive my car with my phone and the house has smart locks. What is this keychain you keep mentioning? I know the app but I don't think that's what you mean.

dns_snek 2y ago

> I'm sure any smartphone-based TOTP will do No it won't. Like the article states, I also believe that phishing resistance is a critical property of 2FA systems. This is something that TOTP will never be able to provide. We don't need Yubikey the brand, but we do need security keys (i.e. FIDO) as a concept.

Delphiza 2y ago

I have a yubikey. It's okay but I don't take it with me. When I'm out I use my phone with a MFA app, and would never tie my MFA to a hardware dongle that is likely not to be on my person when I need it.

krisoft 2y ago
> It's okay but I don't take it with me. Sounds like that is the problem? I have mine on my keyring. (and have a backup in a safe.) > would never tie my MFA to a hardware dongle that is likely not to be on my person when I need it. The solution is to have it with you.
- attendant3446 2y ago
  The problem is that you need at least hardware tokens, one on you and one in a safe place as a backup. And I can't justify the cost of that.
  - jamesmotherway 2y ago
    I wasn't able to justify the potential cost of not having them.

kstenerud 2y ago

... Until you drop your phone and it breaks. And now you can't set up a new phone because you need to tap the notification sent to your old (now broken) phone in order to set up your new phone. I've already had this happen, which is why I use hardware keys now, and a backup phone.

nine_k 2y ago
Do you mean, you don't print these rescue codes which every 2FA thing keeps nagging you about? You don't have a printout in your wallet, or in your folder with important papers? Not even as a secure not in your password manager?..
- kstenerud 2y ago
  Nope, because I was grandfathered into it when Google switched it on for everyone without saying anything. You can still access gmail and such; you just can't set up any more devices without having some kind of 2fa. Now I have a hardware key. I wouldn't dare keep rescue key codes (which can't be revoked) in my wallet.
  - nh2 2y ago
    Can't you just use them to revoke them?
    - nine_k 2y ago
      You can't revoke them if the paper is in the wrong hands, and you don't have a normal access to your account. (Well, they are much like a password in this regard.) It's just different risk profiles. Your biggest risk might be to drop your phone and lose all the 2FAs in a Google Auth app. Or your biggest risk might be losing your wallet to a thief or robber who is going to hijack your accounts.
      - bootlooped 2y ago
        I think the chances of the kind of person who steals your wallet also being able to leverage pilfered two-factor authentication codes to hijack your accounts is almost zero.

whywhywhywhy 2y ago

> People already guard their smartphone well You guard it well, your carrier barely even tries to guard your number from being stolen. Once you have that you can get into Apple account SMS auth/iCloud passwords and keys.

donatj 2y ago

You can get as many eyes as you want on all changes. I don't think it will help much. This sort of thing usually happens because of a change in something completely benign, rather than "security-critical changes". We recently had a pretty major vulnerability exposed by a PEN test (thankfully) that was caused by a single misplaced NOT ! operator in a pretty simple function, maybe 20loc with 100% test coverage as counted by line. The problem case was untested because while tests touched 100% of lines, not all combinations of paths through the code were tested. The code had been written by myself about a year ago, and reviewed by four seasoned developers, none of whom spotted the issue. How many thousands of eyes are on OpenSSL and yet major world ending vulnerabilities still crop up? This might be a hot take, but you can make the process as painful as you like but at the end of the day, building secure software is nigh impossible. We should be putting less trust in software.

OptionOfT 2y ago
Would branch coverage have helped you here? And I think one of the approaches that helped me to write safer code is to parse, and not validate. That way drastically limit the situations we can get into where we forget to validate certain conditions. e.g. you have a User struct, and you want to do an action which requires you to validate whether the user is an admin. 2 options here * validate whether the user is an admin (which could happen multiple times when you're invoking distinct functions as part of a workflow) * parse the User into an AdminUser. If the user is an admin, the function will work, and then you can pass on your new struct into places that require an admin. If it fails, the user is not an admin. Now you have merged all your checks into 1 place.
- donatj 2y ago
  Yeah, almost certainly. We had looked into enabling branch detection several years ago, but it had slowed our suite down to the point where we were not sure it was worth it. Maybe worth looking into again. I do generally like that technique of returning more vetted objects, but I'm not sure that it scales. Our users have close to one hundred different permissions based on the features their admin pays for, having an object for every type seems like a lot. Every combination of types is straight out. The original issue I was talking about I don't think could have been helped. It was an encoding problem that could have potentially lead to XSS injection with a very specific set of GET parameters. I was frankly surprised that the PEN testers managed to find it.

wepple 2y ago

TOTP is trivially phishable. Code security is orthogonal to end-user authentication methods. So, wrong on every count.

VoodooJuJu 2y ago

>And if you need a second factor, I'm sure any smartphone-based TOTP will do No, it won't, because TOTP doesn't protect against phishing, which remains a threat even if randomly-generated unique passwords are used. That's what U2F protects against, is phishing.

nobrains 2y ago

> 4-eyes process for security-critical changes Sounds good on paper, but not practical. Who decides what is a security-critical change?