This is not secure

Oh, right lol… yes I read it all. :slight_smile:

1 Like

Ten years happened about 3 years ago :sunglasses:

2 Likes

Updates:

Now addressed in the manual:

https://support.wyzecam.com/hc/en-us/articles/360027279571-ThroughTek-User-Privacy

Here’s an interesting talk about security delivered to professionals but kept at a “high-level” (accessible) by the speaker.

Most memorable to me is this slide:

A culture generally pays the best those it values the most. A shortage of professionals in a field may imply that the:

  • pay is low (relatively)
  • status is low (relatively)
  • size of threat is large (and growing)

Business has a profit motive to keep the perception of risk at manageable levels.:

Since we live in a world of hyper-managed perceptions:

  • Public Relations (consumer)
  • Public Affairs (citizen)

and public education is mediocre at best, how do we escape this box (of ignorance) and others like it?

well i was sent here by someone as i had the same concerns. The fact that wyze doesnt give the option to run in local LAN is puzzling, the camera keeps “ESTABLISHED” connections to Amazon servers and other servers in Texas, NY, etc. No idea what happens after that. I like the product and the price, and also willing to pay more for more features.

However the fact that they BLOCK the option to stream locally in LAN, saying that for “security reasons” it needs to go to the cloud doesnt give me any trust.

I can’t run these cameras on my network with the firewall on. Or they wont “authenticate” to connect.

RTSP works for this usage but it is currently capped @ 10FPS, that just doesnt make it either.

I’ll come back when LAN-only mode is enabled or RTSP goes to 15 FPS at least, even if i have to pay more.

On the meantime i am thinking of returning them. They phone “somewhere” no way to know if that is in china or not as they could be proxy servers. And the lack of technical explanations on why they need to go to the cloud to authenticate is a problem for me that doesn’t win my trust for now.

Data is king, answers are key to earn trust. So far we dont have the data or the answers

I just sent you here a minute ago, did you even read this conversation?

yes i did, that is why i posted. NO one has answered those questions,

this is very true. you are not paying $20, you are paying $20 + how much you value your data and privacy

It’s not just a matter of it being a camera that others can view. It’s basically a low-power Linux box. If you hack into that, you can get into other things on the local network.

1 Like

tinyCam now fully supports Wyze 2FA.

2 Likes

I am blown away with your response, this proves to me beyond every reasonable doubt that Wyze Labs is transparent. I love you guys.

3 Likes

Are we using 3rd party called ThroughTek: Yes we are.
to transfer video: False. Used to do live streaming only, I’m pretty sure, Live streaming is initiated only by our cloud and ThoughTek cannot start a live streaming session by themselves but I need to verify that particular point.

I would like to focus on certainties… from a privacy perspective, if you’re not sure, you’re not safe.

video transferred securely: We are encrypting the channels for the communication between the camera and the AWS server. I did not verified the implementation but I’m pretty sure that the actual transfer of the content goes straight from the camera to AWS.

Can you please confirm this…

First… can you verify that the video in transit is always encrypted?

Can you please provide details of the encryption used (what algorithm, etc)

What is the state of the data at rest? … What happens to the video stream when it reaches the AWS server? Is the video encrypted at rest? (this is VERY important) If so, who has the encryption keys?

Using NTP servers in Russia: does it really matter which server is used to get the time?

Yes it does - a lot… Why Russian NTP servers? Can this be modified? what happens if the network is restricted / firewalled?

Providing your own encryption:
Extremely complicated and beyond what most people are comfortable setting up. More over, if we are using a 128 bits key and you are using a 128 bits key. What would it make your key more secure than ours?
It would reduce the impact in case of an attack but would not make it more secure if you are targeted.

Yes, it’s complicated, but it allows you to control the points of attack… in particular, if you are providing a firmware which allows RTSP streams, I would think it not too onerous a task to allow the firmware to shut down any other communication or network access,

Or more desirable, in the case of the RTSP firmware, would it not be possible, as you have discontinued development of the RTSP firmware, to release the source for that firmware (even under nondisclosure) so that other more security conscious or application-specific users can take a very good piece of hardware and run with the software. We win, you win… everyone’s happy!

RG

Why does the use of NTP servers in Russia actually matter? As long as it’s sync’ed to the atomic clock, all drift and strata are accounted for. You are much more susceptible to an issue of NTP data that’s IN TRANSIT than you are based on the specific clock you’re using. Further, the use of MULTIPLE sources for time sync that are geographically diverse and run by different organizations entirely should be the goal… not just “not using the ones in Russia.”

With regard to encryption of videos at rest in AWS… This is a generally irrelevant thing to be concerned about. Data at Rest refers specifically to data when it is written to disk ONLY. This means that any open services, daemons, processes, etc. that are able to access the data will have the keys to unencrypt it. Data at Rest is something scrutinize from an encryption perspective ONLY when you are dealing the data being disconnected or removed from the original device that stored it. For example: A USB thumb drive that you’ll ship through the mail. Full Disk Encryption of your local hard drive with specific keys or passwords required at boot time to unlock it (although once it’s unlocked, the Data at Rest part is negated until the machine is again powered off).

Being concerned with Data in Motion encryption is legitimate.

Releasing source code from discontinued streams of development would still mean making their private code and potentially coding practices public. Unless the company is shutting down and NO ONE will be doing further development for any of it, this is often difficult to make happen.

1 Like

My understanding was, anything that is placed over Radio wave or on the internet is hackable.
Like your Front door, you just need the right tool to break it. Giving you a false sense of security.

Be aware, Wyze sells this device as not a Security device.

Plus all your video feeds is able to be viewed by WyZE support as the images go to WyZe Cloud server. Even if you trust WYZE, this makes it vulnerable.

Oddly enough, every time i comment on Wyze Comment board, all my Wyze camera’s always seems to need to be power cycled and go offline. Coincidence, ?..

It really isn’t secure. I’m watching all of you right now from the app. :face_with_hand_over_mouth:

How many fingers am I holding up?

1 Like

Just the one

MOD NOTE: Post edited to conform to the Community Guidelines

Wrong. :slight_smile:

Hey, blame Apple for the emoji.

Nicely said!