←back to thread

Plex Security Incident

(links.plex.tv)
104 points andyexeter | 1 comments | | HN request time: 0s | source
Show context
Someone1234 ◴[] No.45175111[source]
> Any account passwords that may have been accessed were securely hashed, in accordance with best practices, meaning they cannot be read by a third party.

I am glad they were hashed, but that's a misleading statement. The point of hashing is to slow an attacker down, even with full best security practices (e.g. salt + pepper + argon2 w/high factors) they can still be reverse engineered. It is a matter of when, not if.

replies(6): >>45175194 #>>45175199 #>>45175211 #>>45175220 #>>45175316 #>>45175644 #
Dedime ◴[] No.45175220[source]
Maybe this is naive, but in a good crypto system, I would hope "when" is measured in millions or billions of years given current hardware capabilities.
replies(1): >>45175284 #
smallerize ◴[] No.45175284[source]
If you have a long enough and random enough password, you're probably good. The trouble with short passwords is that there just aren't that many of them. An attacker can just compute the hash of all of them.
replies(1): >>45175382 #
jcgl ◴[] No.45175382[source]
As long as the salt is secret from the attackers (which is not a given, of course), the length of the passwords shouldn't matter all too much; the input to the hash (i.e. password + hash) would still have enough entropy to not be brute-force-able.
replies(2): >>45175532 #>>45175533 #
OkayPhysicist ◴[] No.45175532{3}[source]
If you have the hashed password, in most systems you have the salt. Salt+hash is for preventing the attackers from getting to try all your passwords in parallel.
replies(2): >>45175980 #>>45176024 #
1. fluidcruft ◴[] No.45175980{4}[source]
You can also have a system salt(s) that are not stored with the database, so that if someone accesses the database they have to guess password and two salts, one of which they hopefully do not have via the same penetration.