qw3rty01

I really wish this was included in the article, his conclusion makes a lot more sense in that context (though I still disagree with it).

Calling out an article for being misleading is not the same as misrepresenting it.

The article implied he wasn't the only one they talked with. There isn't anything he said that was explicitly incorrect (unlike some of the other unnamed security researchers), but he must not have much experience with credential stuffing incidents given his responses.

The Amazon spokesperson directly said it was credential stuffing--the article was trying to argue that it was more than that in an extremely misleading way.

All of that information is extremely common when it comes to aggregated information sold/shared for credential stuffing, there's nothing that sticks out as odd or out of place in any of this. It can all be pulled through scripts, there's no extra effort needed.

After reading the article, it's pretty clear that it was credential stuffing and that the writer didn't take the time to understand how it worked. Not sure what security experts they talked to, but credential stuffing absolutely can get all the information described, and the whole part about wifi connected devices is completely unrelated.

Even if it was the official article title, "Data Leak" is extremely misleading; the attack is called credential stuffing and is unrelated to any sort of breach on Ring's end.

Edit: finished reading the article, and the entire text is just as misleading as the title, credential stuffing happens all the time and really isn't newsworthy.

You're saying we shouldn't spend time to make sure the algorithm is mathematically sound...because the implementation will have side channels? Using your metaphor, that's like saying we should never bother designing a secure lock because someone will just break a window to get in anyway.

That's because...they can. Because the behavior of the statement is undefined.

It says everything. Even if undefined behavior works one way on all platforms today, it could work differently tomorrow in a way that introduces bugs. It's nonsensical to blame the compiler for conforming to the standard in a way that breaks code using undefined behavior.

There is no guarantee it would work if it relies on undefined behavior--that's what undefined means, and also the reason the optimizer acted the way it did. In that case, adding flags that defines what happens when particular undefined behavior hits would probably be the way to go, or rewrite it in a way that doesn't rely on undefined behavior.

A better title would be security flaws caused by relying on undefined behavior.