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

101–110 of 161 posts

Re: Wyze security incident update

#101

Post by pkaeding »

wutwutwat wrote: post #80
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…

There are only two hard things in Computer Science: cache invalidation and naming things. -- Phil Karlton

And off-by-one errors

Re: Wyze security incident update

#102

Post by belter »

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…

Sounds like its redis-py again...

Re: Wyze security incident update

#103

Post by lightspot21 »

wutwutwat wrote: post #80
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…

There are only two hard things in Computer Science: cache invalidation and naming things. -- Phil Karlton

...and off-by-one errors!

Re: Wyze security incident update

#104

Post by dns_snek »

avg_dev wrote: post #28
tgsovlerkhgsel wrote: post #16

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.the…

Wow. That is decidedly not a good trend. Once is definitely bad enough, but twice…

There was another, different incident reported in 2022 spanning 3 years, and a data breach in 2019.

https://www.consumerreports.org/home-garden/home-security-ca...

Re: Wyze security incident update

#105

Post by myself248 »

Cheer2171 wrote: post #69
prmoustache wrote: post #48

Earlier quoted context omitted.

Why would your insurance require a proof of the theft? That is not how insurances work usually.

My home insurance requires proof of theft. Often you use a police report. My local police department is on an unofficial slowdown strike because they don't feel appreciated post-BLM. Possibly also because if they "forget" to file police reports or they "get lost in the system" then the official crime rate goes down. It took me over a month to get a police report I could send to insurance for a simple break in, and sp…

Similar, but 6 or 7 years ago and with no discernible reason. The process of filing a police report and then compiling all the documentation required by insurance took longer and cost more by wage than I ultimately recovered through insurance.

I wish I could say it was still worth it because filing the report and providing the information about the theft gave the police additional info to use if they ever caught the thief, but nope. They didn't even want a copy of the video from the security cameras at the store in whose parking lot it happened. They made it acutely obvious that I was wasting their time by being there and that they had no interest whatsoever in doing what I naïvely thought was their job.

What an absolute waste of time.

Re: Wyze security incident update

#107

Post by ra »

urbandw311er wrote: post #106

Initially I thought this was about the money transfer company. Curious how there are two software companies with the same name and one hasn’t sued the other.

Initially, I thought it was the turn-by-turn mapping app. Apparently, there are three wise companies.

Re: Wyze security incident update

#109

Post by jt2190 »

sponaugle wrote: post #74
jt2190 wrote: post #66

Earlier quoted context omitted.

> Of course you need to provide proof of theft. Generally filing a police report will suffice, if I’m not mistaken. Could you lie? Of course, but (1) it’s generally not in your best interest because the insurer might raise your rates and/or discontinue coverage, and (2) you’d be making a decision to make false statements to the police for purpose of fraud, which most reasonable people won’t do. Other than perhaps usi…

"Other than perhaps using cameras as a means to deter thieves, I’m not sure that low-value (under USD 5000) items like bicycles are worth the time and effort for insurers to launch full investigations over." I would agree, yet I have seen it happen. It is a somewhat difficult to predict path. I have seen some smaller claims (~$2000) take significantly longer and with more investigation than other very large (>$50,000…

> I would agree, yet I have seen it happen.

You've seen insurance claims denied because someone didn't have an unverified video that allegedly showed a theft taking place, even with a police report in hand? (Seriously: How would an insurer know that you hadn't arranged to have your brother-in-law pretend to steal your bike for the camera?)

Re: Wyze security incident update

#110

Post by cromka »

bhhaskin wrote: post #99
spullara wrote: post #88

This actually looks like a concurrency bug in their request handling code that may have stored the user id and camera id in shared variables, under load the wrong camera id is seen by a user. At least based on the description of what they say happened.

Yeah sounds like an issue with garbage collection/freeing up memory.

These are the kind of security gimmicks that I am terrified I will never fully internalize and, as a result, the code I might be proud of may in fact be a ticking bomb.
Post reply on HN