4 ms·

It's a hardcoded default password, not a permanent backdoor. If I'm understanding the post correctly, the user changes it as part of the onboarding flow. This

It's a hardcoded default password, not a permanent backdoor. If I'm understanding the post correctly, the user changes it as part of the onboarding flow. This is the way most apps work if they have a default password the user is supposed to change.

bri3d 1y ago
The device should ideally have some kind of secret material derived per device, like a passphrase generated from an MCU serial number or provisioned into EEPROM and printed on a label on the device. Some form of "enter the code on the device" or "scan the QR code on the device" could then mutually authenticate the app using proof-of-presence rather than hardcoded passwords. This can still be done completely offline with no "cloud" or other access, or "lock in"; the app just uses the device secret to authenticate with the device locally. Then the user can set a raw RTSP password if desired. This way unprovisioned devices are not nearly as vulnerable to network-level attacks. I agree that this is Not Awful but it's also Not Good. Right now, if you buy this camera and plug it into a network and _forget_ to set it up, it's a sitting duck for the time window between network connection and setup.
- yannyu 1y ago
  AT&T routers, for example, ship like this. There's a wifi network and a wifi password printed onto the device. But that also means then that often anyone with physical access can easily get into the device. The complicated password provides an additional layer of illusion of security, because people then figure "it's not a default admin password, it should be good". The fundamental problem seems to be "many people are bad at passwords and onboarding flows", and so trying variations on shipping passwords seem to result in mostly the same problems.
  - some_random 1y ago
    If you have physical access you can just factory reset the device and onboard it with the normal flow though
    - deleted 1y ago
      [deleted]
    - yannyu 1y ago
      That's fair, though at least resetting would indicate that an attack happened. Default passwords and printed passwords can result in undetected attacks, which are arguably worse.
      - some_random 1y ago
        It doesn't change anything in this case though, you can't use the default password against a tp-link device after it's been onboarded.
  - mystifyingpoi 1y ago
    Same with Orange branded ones. There is even a QR code that you can scan on your phone - no more typing 16-24 hex characters. It's hard to decide whether it's good or bad. It is definitely easier. Which I guess matters most in consumer grade routers.
  - recursive 1y ago
    I feel seen. Why is the security illusory? I still don't understand the problem with this. Is the concern that someone will break into my house to covertly get access to my wifi password?
- some_random 1y ago
  If you buy the camera, plug it in, and forget to set it up, you just flat out can't use it right? I agree that proof of presence is way better but how many people are seriously going to be affected?
  - bri3d 1y ago
    No, if you buy the camera, plug it in, and forget to set it up, then someone can use the default password and key material stored in the app to pretend to be the app and provision it on your behalf. That's the only real vulnerability here, and it's no big deal, but it is A Thing and there is definitely a better way to do this that doesn't lose the freedom of full-offline.
    - some_random 1y ago
      Ok yeah I think we're in agreement then.
    - 2rsf 1y ago
      There could be another scenario. I assume that factory resetting the camera will bring back the default password. Factory reset is a long press on the power button (in some cheap TPlink camera), so in theory someone with physical access can take control over the camera without you noticing until you try and use it.
- mtlynch 1y ago
  I agree that would be nice, but it also doesn't sound all that practical for a small vendor. I used to sell a home networking device,[0] and I wouldn't do what you're describing. If there were an issue where the labels calculate the wrong password or the manufacturer screws up which device gets which label, you don't find out until months later when they're in customer hands and they start complaining, and now you have to unwind your manufacturing and fulfillment pipeline to get back all the devices you've shipped. All that to protect against what attack? One where there's malicious software on the user's network that changes the device password before the user can? In that case, the user would just not use the camera because they can't access the feed. [0] https://mtlynch.io/i-sold-tinypilot/ https://mtlynch.io/i-sold-tinypilot/
  - kelnos 1y ago
    TP-Link is far from being a small vendor, though.
    - mtlynch 1y ago
      Ah, I see. I thought OP used TP-Link for their router. I missed that Tapo (the camera manufacturer) is a subsidiary of TP-Link.
    - creeble 1y ago
      I think he has it backwards: Easy for a small vendor, very hard for a large one.
      - stephen_g 1y ago
        For a large manufacturer, it can be flashed onto the device automatically by a machine as part of the production line. That's not easy to set up, but basically something they already need to have set up (you don't want to have humans have to plug in boards to flash firmware and load serial numbers, etc. on to every unit).
  - bri3d 1y ago
    Ha! I actually use TinyPilot all the time, nice! > I agree that would be nice, but it also doesn't sound all that practical for a small vendor. Personalizing / customizing per device always introduces a huge amount of complexity (and thus cost). However, this is TP-Link we're talking about, who definitely have the ability to personalize credentials at scale on other product lines. And again, to be clear, I'm not trying to argue that the current way is some horrible disaster from TP-Link, just advocating for a better solution where possible. I think the current system reads as fine, honestly, it sounds like typical cobbled together hardware vendor junk that probably has some huge amount of "real" vulnerability in it too, but this particular bit of the architecture doesn't offend me badly. > now you have to unwind your manufacturing and fulfillment pipeline to get back all the devices you've shipped. This can be avoided with some other type of proof-of-presence side channel which doesn't rely on manufacturing personalization - for example, a physical side-channel like "hold button to enable some PKI-based backup pairing or firmware update mode." For a camera, there should probably be an option to make this go away once provisioning is successful, since you don't want an attacker performing an evil maid attack on the device, but for pre-provisioning, it's a good option.
- miki123211 1y ago
  These may be illegal in some jurisdictions due to accessibility laws, and are a bad idea in general, for these reasons as well as unattended configuration scenarios.
- crowfunder 1y ago
  > The device should ideally have some kind of secret material derived per device, like a passphrase generated from an MCU serial number or provisioned into EEPROM and printed on a label on the device. It is better than simple secret like 12345678 but it can go wrong too, like in the case of UPC UBEE routers where the list of potential passwords can be narrowed down to like ~60 possibilities using a googled generator [1] whilst knowing only the SSID. It did require firmware reverse engineering to figure out [2][3] but applies to most devices I've encountered. User should ideally always change the default password regardless. [1] https://upcwifikeys.com/UPC1236567 https://upcwifikeys.com/UPC1236567 [2] https://deadcode.me/blog/2016/07/01/UPC-UBEE-EVW3226-WPA2-Reversing.html https://deadcode.me/blog/2016/07/01/UPC-UBEE-EVW3226-WPA2-Re... [3] https://web.archive.org/web/20161127232750/http://haxx.in/upc_keys.c https://web.archive.org/web/20161127232750/http://haxx.in/up...
- pabs3 1y ago
  > The device should ideally have some kind of secret material derived per device Thats the wrong way to do it, just require the user create a secret on first boot, and have factory reset functionality for when you forget it.
- otikik 1y ago
  Well it was "the cheapest cam in Amazon" according to the article so my expectations were that this would not be "ideal".
m463 1y ago
on the other hand "onboarding" seems to be a less offensive normalizing word which really means "ask permission to use device"...
lo0dot0 1y ago
"if you don't know what you're doing don't do it" vs. "Secure out of the box"

bri3d 1y ago

The device should ideally have some kind of secret material derived per device, like a passphrase generated from an MCU serial number or provisioned into EEPROM and printed on a label on the device. Some form of "enter the code on the device" or "scan the QR code on the device" could then mutually authenticate the app using proof-of-presence rather than hardcoded passwords. This can still be done completely offline with no "cloud" or other access, or "lock in"; the app just uses the device secret to authenticate with the device locally. Then the user can set a raw RTSP password if desired. This way unprovisioned devices are not nearly as vulnerable to network-level attacks. I agree that this is Not Awful but it's also Not Good. Right now, if you buy this camera and plug it into a network and _forget_ to set it up, it's a sitting duck for the time window between network connection and setup.

yannyu 1y ago
AT&T routers, for example, ship like this. There's a wifi network and a wifi password printed onto the device. But that also means then that often anyone with physical access can easily get into the device. The complicated password provides an additional layer of illusion of security, because people then figure "it's not a default admin password, it should be good". The fundamental problem seems to be "many people are bad at passwords and onboarding flows", and so trying variations on shipping passwords seem to result in mostly the same problems.
- some_random 1y ago
  If you have physical access you can just factory reset the device and onboard it with the normal flow though
  - deleted 1y ago
    [deleted]
  - yannyu 1y ago
    That's fair, though at least resetting would indicate that an attack happened. Default passwords and printed passwords can result in undetected attacks, which are arguably worse.
    - some_random 1y ago
      It doesn't change anything in this case though, you can't use the default password against a tp-link device after it's been onboarded.
- mystifyingpoi 1y ago
  Same with Orange branded ones. There is even a QR code that you can scan on your phone - no more typing 16-24 hex characters. It's hard to decide whether it's good or bad. It is definitely easier. Which I guess matters most in consumer grade routers.
- recursive 1y ago
  I feel seen. Why is the security illusory? I still don't understand the problem with this. Is the concern that someone will break into my house to covertly get access to my wifi password?
some_random 1y ago
If you buy the camera, plug it in, and forget to set it up, you just flat out can't use it right? I agree that proof of presence is way better but how many people are seriously going to be affected?
- bri3d 1y ago
  No, if you buy the camera, plug it in, and forget to set it up, then someone can use the default password and key material stored in the app to pretend to be the app and provision it on your behalf. That's the only real vulnerability here, and it's no big deal, but it is A Thing and there is definitely a better way to do this that doesn't lose the freedom of full-offline.
  - some_random 1y ago
    Ok yeah I think we're in agreement then.
  - 2rsf 1y ago
    There could be another scenario. I assume that factory resetting the camera will bring back the default password. Factory reset is a long press on the power button (in some cheap TPlink camera), so in theory someone with physical access can take control over the camera without you noticing until you try and use it.
mtlynch 1y ago
I agree that would be nice, but it also doesn't sound all that practical for a small vendor. I used to sell a home networking device,[0] and I wouldn't do what you're describing. If there were an issue where the labels calculate the wrong password or the manufacturer screws up which device gets which label, you don't find out until months later when they're in customer hands and they start complaining, and now you have to unwind your manufacturing and fulfillment pipeline to get back all the devices you've shipped. All that to protect against what attack? One where there's malicious software on the user's network that changes the device password before the user can? In that case, the user would just not use the camera because they can't access the feed. [0] https://mtlynch.io/i-sold-tinypilot/ https://mtlynch.io/i-sold-tinypilot/
- kelnos 1y ago
  TP-Link is far from being a small vendor, though.
  - mtlynch 1y ago
    Ah, I see. I thought OP used TP-Link for their router. I missed that Tapo (the camera manufacturer) is a subsidiary of TP-Link.
  - creeble 1y ago
    I think he has it backwards: Easy for a small vendor, very hard for a large one.
    - stephen_g 1y ago
      For a large manufacturer, it can be flashed onto the device automatically by a machine as part of the production line. That's not easy to set up, but basically something they already need to have set up (you don't want to have humans have to plug in boards to flash firmware and load serial numbers, etc. on to every unit).
- bri3d 1y ago
  Ha! I actually use TinyPilot all the time, nice! > I agree that would be nice, but it also doesn't sound all that practical for a small vendor. Personalizing / customizing per device always introduces a huge amount of complexity (and thus cost). However, this is TP-Link we're talking about, who definitely have the ability to personalize credentials at scale on other product lines. And again, to be clear, I'm not trying to argue that the current way is some horrible disaster from TP-Link, just advocating for a better solution where possible. I think the current system reads as fine, honestly, it sounds like typical cobbled together hardware vendor junk that probably has some huge amount of "real" vulnerability in it too, but this particular bit of the architecture doesn't offend me badly. > now you have to unwind your manufacturing and fulfillment pipeline to get back all the devices you've shipped. This can be avoided with some other type of proof-of-presence side channel which doesn't rely on manufacturing personalization - for example, a physical side-channel like "hold button to enable some PKI-based backup pairing or firmware update mode." For a camera, there should probably be an option to make this go away once provisioning is successful, since you don't want an attacker performing an evil maid attack on the device, but for pre-provisioning, it's a good option.
miki123211 1y ago
These may be illegal in some jurisdictions due to accessibility laws, and are a bad idea in general, for these reasons as well as unattended configuration scenarios.
crowfunder 1y ago
> The device should ideally have some kind of secret material derived per device, like a passphrase generated from an MCU serial number or provisioned into EEPROM and printed on a label on the device. It is better than simple secret like 12345678 but it can go wrong too, like in the case of UPC UBEE routers where the list of potential passwords can be narrowed down to like ~60 possibilities using a googled generator [1] whilst knowing only the SSID. It did require firmware reverse engineering to figure out [2][3] but applies to most devices I've encountered. User should ideally always change the default password regardless. [1] https://upcwifikeys.com/UPC1236567 https://upcwifikeys.com/UPC1236567 [2] https://deadcode.me/blog/2016/07/01/UPC-UBEE-EVW3226-WPA2-Reversing.html https://deadcode.me/blog/2016/07/01/UPC-UBEE-EVW3226-WPA2-Re... [3] https://web.archive.org/web/20161127232750/http://haxx.in/upc_keys.c https://web.archive.org/web/20161127232750/http://haxx.in/up...
pabs3 1y ago
> The device should ideally have some kind of secret material derived per device Thats the wrong way to do it, just require the user create a secret on first boot, and have factory reset functionality for when you forget it.
otikik 1y ago
Well it was "the cheapest cam in Amazon" according to the article so my expectations were that this would not be "ideal".

m463 1y ago

on the other hand "onboarding" seems to be a less offensive normalizing word which really means "ask permission to use device"...

lo0dot0 1y ago

"if you don't know what you're doing don't do it" vs. "Secure out of the box"