Hacker News Reader

Comment by Kibae | Hacker News Reader

> conduct regular scans for Ring passwords compromised in non-Ring breaches

Does this mean that Ring stores plaintext passwords?

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.

Shouldn't salting make that expensive?

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.

>So 1,000,000 breached passwords * 100ms per check is 100,000 CPU seconds or about 30 CPU hours to check all passwords.

For a single user's account. Multiply that by 1 million ring users and you get 30 million CPU hours.

More likely shared passwords, I think

Yes. But how does Ring perform the scan? It'll take quite a lot of CPU.

No. They use rainbow tables: https://en.wikipedia.org/wiki/Rainbow_table

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.

Rainbow tables only work if there aren't per-user salts. I assume Ring uses per-user salts, meaning rainbow tables won't work.

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):

https://rsheasby.medium.com/rainbow-tables-probably-arent-wh...

It's entirely possible that my information (not really worth it for me to dig through years of browsing history to find it) is dated.

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.

No, it means that they hash the breached passwords and compare those hashes to the stored hashes of customer passwords.

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.

Maybe they just do the scan at login time.

Maybe that counts as "regular".

Reply on news.ycombinator.com