Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Wyze security incident update

forums.wyze.com

Post reply on HN
Print view View original

11–20 of 161 posts

Re: Wyze security incident update

#11

Post by skipkey »

psanford wrote: post #5

There's a bunch of things in here that don't really make sense: > The incident was caused by a third-party caching client library that was recently integrated into our system. This client library received unprecedented load conditions caused by devices coming back online all at once. As a result of increased demand, it mixed up device ID and user ID mapping and connected some data to incorrect accounts. What? How doe…

It’s just a WAG, but I bet someone used a timestamp as a unique key, or at least part of one, so you were unlikely to get collisions except under load.

Re: Wyze security incident update

#12

Post by Twirrim »

twisteriffic wrote: post #2

> The incident was caused by a third-party caching client library that was recently integrated into our system. This client library received unprecedented load conditions caused by devices coming back online all at once. As a result of increased demand, it mixed up device ID and user ID mapping and connected some data to incorrect accounts. That seems like enough of a line of bullshit to steer me away from ever using…

How so? I've seen caching clients exhibit some really weird behaviour under heavy load. It's not beyond the pale that, eg, the caching library doesn't do proper locking before writing, resulting in writes stomping all over each other.

Caching is normally read heavy, not write heavy, so it's plausible it wouldn't be something you'd see much under typical operation. After an outage, they'd be dealing with a thundering herd level of traffic as everything tries to reconnect, that'd be very different from normal write loads, even different than the write load they'd have seen when they first enabled caching.

Re: Wyze security incident update

#13

Post by 1letterunixname »

sneak wrote: post #4

Nobody should ever be surprised that sending video to someone else’s computer (ie “the cloud”) results in third parties viewing that video.

Or buying cheap, no-brand or upstart brand cameras with cloud capabilities.

I had a heck of a time finding a proper POE recording DVR camera system for my mom's house without online or cloud bullshit, but still I isolated it on the network to not take any chances of UPnP port opening or dial-home crap.

The only system I would trust would be one that laid out their security model, source to their apps, and had a self-hosted server DVR option. The captological signals of 99.9% of security system websites do not instill confidence in my mind.

Re: Wyze security incident update

#14

Post by sigden »

twisteriffic wrote: post #2

> The incident was caused by a third-party caching client library that was recently integrated into our system. This client library received unprecedented load conditions caused by devices coming back online all at once. As a result of increased demand, it mixed up device ID and user ID mapping and connected some data to incorrect accounts. That seems like enough of a line of bullshit to steer me away from ever using…

[dead]

Re: Wyze security incident update

#15

Post by CodesInChaos »

psanford wrote: post #5

There's a bunch of things in here that don't really make sense: > The incident was caused by a third-party caching client library that was recently integrated into our system. This client library received unprecedented load conditions caused by devices coming back online all at once. As a result of increased demand, it mixed up device ID and user ID mapping and connected some data to incorrect accounts. What? How doe…

I assume the code was always incorrect, but only exhibits the problem in practice under high load. This could be a race-condition/data-race, or treating short hashes as unique.

Re: Wyze security incident update

#16

Post by tgsovlerkhgsel »

This is one of the reasons why you want end-to-end encryption wherever possible.

Even a bad implementation with cloud-synced encryption keys (which defeats most of the benefits of e2e) would have stopped this.

The response in this case (notifying customers and specifically stating whether they were affected or not) is excellent, but this seems to be a repeat of a previous incident from September 2023: https://www.theverge.com/2023/9/8/23865255/wyze-security-cam...

Re: Wyze security incident update

#17

Post by mistrial9 »

pylua wrote: post #6
twisteriffic wrote: post #2

> The incident was caused by a third-party caching client library that was recently integrated into our system. This client library received unprecedented load conditions caused by devices coming back online all at once. As a result of increased demand, it mixed up device ID and user ID mapping and connected some data to incorrect accounts. That seems like enough of a line of bullshit to steer me away from ever using…

Device id and user ids are non unique?

hash collisions?

Re: Wyze security incident update

#18

Post by [deleted] »

twisteriffic wrote: post #2

> The incident was caused by a third-party caching client library that was recently integrated into our system. This client library received unprecedented load conditions caused by devices coming back online all at once. As a result of increased demand, it mixed up device ID and user ID mapping and connected some data to incorrect accounts. That seems like enough of a line of bullshit to steer me away from ever using…

[deleted]

Re: Wyze security incident update

#19

Post by syntaxing »

This is one of the things Apple does right. HomeKit working local is a pretty great setup and just works. I put my HomeKit cameras on a VLAN without internet and device isolation and they still work seamlessly. The hard part is getting cameras that are wireless. I use scrypted but even then, getting ONVIF or RTSP isn’t as straight forward nowadays. I also have a local frigate backup which works great too. You can pipe in the detection to scrypted with MQTT.

Re: Wyze security incident update

#20

Post by SigmundA »

twisteriffic wrote: post #2

> The incident was caused by a third-party caching client library that was recently integrated into our system. This client library received unprecedented load conditions caused by devices coming back online all at once. As a result of increased demand, it mixed up device ID and user ID mapping and connected some data to incorrect accounts. That seems like enough of a line of bullshit to steer me away from ever using…

I would at least want to know the client library so I can never use it for anything. Also never trust the client and I hope they don't mean the actual client app such that it can access other user id without server validation...
Post reply on HN