No. You take the compromised plaintext password, hash it using the same algorithm you typically do for your customers, then you check the hash for matches in your database of existing customer password hashes.
Not if your only checking 1 possibility rather than a few million.
It could take on the order of a few seconds per password in the worst case. Normally a few Milliseconds.
So 1,000,000 breached passwords * 100ms per check is 100,000 CPU seconds or about 30 CPU hours to check all passwords. The is easily paraliseable so imagine more like 10-20 minutes in parallel.
If they have a hash, but there is no indication this is due to a breach of Amazon but likely people getting viruses by installing EXE porn and what not.
You would think so, but, it seems that rainbow tables are surprisingly effective, so that tells you that a lot of corporations -I suspect IoT are the worst offenders- are on low-sodium diets.
Do you have a source for rainbow tables are surprisingly effective?
I was actually under the impression that they're generally overhyped and not useful in most situations.
Even if most IoT companies don't use per-user salts, Ring is one of the most respected ones, since it's run by Amazon. So it likely has salts.
Actually, thinking about this more, I don't think rainbow tables are useful here even without per-user salts. The purpose of rainbow tables is to be a storage optimization, so that you can use less storage than a hash table, while still having a lot of the benefits of a hash table. But this specific use case discussed here is "passwords compromised in non-Ring breaches", for which there is enough storage for a hash table. So a rainbow table provides no benefit over a hash table.
For more information on what rainbow tables are read this (note that the first page doesn't even explain rainbow tables, you have to click part 2 at the bottom to get to the actual explanation of rainbow tables):
What you do is: you get someone's password from a hacked website that did store passwords in plaintext. Then you try using that same username/password combo to log into Ring.
Sure. But how many passwords do you check? Any how many users does Ring have? Multiply those 2 numbers, then multiply that by how slow the password hash is. That's a lot of CPU usage.
If Ring has per-user salts, which I assume they do, they'll have to hash each breached password individually for each Ring user. So multiply the number of breached passwords by the number of Ring users by the time a hash takes (slower is better) and you get a huge amount of CPU cost.