131–140 of 207 posts
What tends to be the first indication of breaches? It's one thing to do a forensic analysis after learning of a breach, and it's another to detect it in the first place.
> Finding suspicious outbound network activity
https://blog.rapid7.com/2016/05/09/introduction-to-osquery-f...
Earlier quoted context omitted.
>There are plenty of publicly leaked hash tables running MD5 and the like. Not related to stackoverflow though. >You need a reused password from a weak one. If the weak password is already public, what is gained by finding out that it's a weak password in a strong DB? You've just described a dictionary attack.
My mention of MD5 was just a benchmark reference. I can see from the downvotes the very idea that it is in regular use as triggering for some folks—-but md5 and other weak hashing algos are not just in obscure anime forums but in systems everywhere. “They don’t like to think it be like it is, but it do.” And it isn’t about md5 hash rate it’s about the ease of cracking in general due to low cost of compute. If the SO…
Nobody here disagrees with this premise. I just disagree that "low cost of compute" changes the fact that functions like Argon2 can be tuned to become more expensive to crack based on changes in computation cost. If you're worried about someone spinning up something on AWS to crack hashes, bump up the memory and CPU hardness and now they'll have to spend much more money to crack your passwords. In addition, the design of most modern password hashing functions is such that you get poor parallelism on GPUs.
Earlier quoted context omitted.
What makes you say that? bcrypt's been the defacto best practice for user password "storage" for probably 10 years now. MD5's been known to be inadequate for much longer. Even if they had a legacy implementation in MD5, gradually migrating from storing MD5 hashes to storing bcrypt hashes is trivial to do.
From what I understand, many systems do not choose to implement strong hashing algos.
Earlier quoted context omitted.
>There are plenty of publicly leaked hash tables running MD5 and the like. Not related to stackoverflow though. >You need a reused password from a weak one. If the weak password is already public, what is gained by finding out that it's a weak password in a strong DB? You've just described a dictionary attack.
My mention of MD5 was just a benchmark reference. I can see from the downvotes the very idea that it is in regular use as triggering for some folks—-but md5 and other weak hashing algos are not just in obscure anime forums but in systems everywhere. “They don’t like to think it be like it is, but it do.” And it isn’t about md5 hash rate it’s about the ease of cracking in general due to low cost of compute. If the SO…
Earlier quoted context omitted.
MD5 is one thing as a password can be retrieved from a hash table. But pulling out passwords from a hashed + salted value (e.g. via bcrypt) is many orders of magnitude more infeasible, no?
I would be impressed if SO's user password table is in bcrypt.
Earlier quoted context omitted.
They don't have to store them as plain text for it to be a problem. If they're not salted it's trivial to crack the hashes, and if they are all uniquely salted, while it's time consuming, they can still gradually crack them. Given that you could probably sift through the users to find particularly juicy targets (usernames of maintainers of top open source projects with github repos for example?) that could justify th…
I haven't checked in a while, what's the cost of cracking a single salted password that is stored properly, e.g. with pbkdf2 or bcrypt or whatever is currently state of the art?
In a good case, it takes 50ms per hash on a modern system, so that's 20 attempts per second (instead of 20 billion per second for a plain md5 or so). I don't really expect a popular site to do much more than that, so that's the best case. From experience, most sites will be more around the 20 billion mark than the 20 mark, but I expect stackoverflow to be on the good end.
The current state of the art is Argon2, with scrypt second and bcrypt/pbkdf2 tied for third. The first two have memory hardness, and the first one is the standard chosen in the password hashing algorithm competition. The third is still acceptable because most developers still go for a salted single hash like sha256. Somehow they got the salting method, but I'd rather they break all identical passwords at the same time (they weren't that strong anyway if they're shared between more than one person) than that they crack only a tiny percentage because of the cost. Slowness helps more than salting, yet as a pentester I see more of the latter than the former. So I'd rather recommend something available for their platform as a good third choice than them going "meh, effort" and not implementing the recommendation.
Earlier quoted context omitted.
They don't have to store them as plain text for it to be a problem. If they're not salted it's trivial to crack the hashes, and if they are all uniquely salted, while it's time consuming, they can still gradually crack them. Given that you could probably sift through the users to find particularly juicy targets (usernames of maintainers of top open source projects with github repos for example?) that could justify th…
I haven't checked in a while, what's the cost of cracking a single salted password that is stored properly, e.g. with pbkdf2 or bcrypt or whatever is currently state of the art?
If my password is "password" you can probably guess that almost instantly no matter what scheme is used. If my password is 32 characters of random base64 output then it wouldn't matter if the scheme is MD5($password) you won't guess it.
Schemes like PBKDF2 and bcrypt trade something useful in the middle, if your password is mediocre they make it too hard to bother guessing. But you'd need to define how mediocre it is to get a meaningful estimate.
Earlier quoted context omitted.
> It is a question of when not if a hash table is fully cracked. ...? At 48 trillion hashes / second, you could get the entire hash space in as little as 224 quadrillion years. Of course, if you had any collisions, it would take longer. A lot longer. This suggests that strong passwords are still just as strong under md5 as under a more modern hash. No? Use of md5 is a problem because people use passwords that are eas…
No, MD5 has about 18 bit collision strength. Combined with predictable salting practice, this is crackable with a calculator. Welcome to Merkle-Damgard construction allowing any prefix or suffix. Given random salt (random placed or mixed) or HMAC, you have to use the more complex preimage attack at 123 bits. This is crackable with a medium sized botnet or a supercomputer. 48 THash is an underestimate. Specialized har…
What problem are you trying to solve? As I understand it, we're discussing enumerating the hash space, such that:
1. You are given a hashed value, such as 2b0f4e60b80da7ef1e84573d764f1bf4 .
2. The value is someone's hashed password. You need to find any string which hashes to this particular fixed value, but you don't know of any such string to start with.
You can do this by brute force, but it will take you a long, long time.
The problem is NOT:
1. You have a string which hashes to a particular value.
2. You want other strings which hash to the same value.
And it also isn't:
1. You have a string which, with an unknown prefix, hashes to a particular known value.
2. You want to identify hashes which represent the same string with other prefixes applied.
I don't see where salting is relevant to the question. It's a defense against the phenomenon that cracking one user's password automatically also cracks everyone else who uses the same password (since, without salting, they all have the same hash), but it isn't a defense against having your password cracked by a targeted attack (since, in a targeted attack, there are no other hashes to be collateral damage). Why did you bring it up? What attack are you thinking of?
Earlier quoted context omitted.
And how does it do on hashes that are not known to be useless, eg bcrypt or argon2?
It is running on top of hashcat, and at the above-mentioned compute it was benchmarking 45 million bcrypts per second. At that point it is more about the attack plan than the compute. https://imgur.com/a/DXQMsM1 edit: here is the demo video: https://www.youtube.com/watch?v=KnD4f8N1_OE
More meaningful would be the speedup compared to a single CPU core, which is what the developers (should) benchmark against. They should make it as slow as possible, so if their system can do bcrypt with a cost of 15 in 0.1 seconds, they should set either that or cost 16. (Much more than 0.2s might be annoying to users or be a DOS vector.)
Reflecting on this, I wonder if a PaaS solution that is a "vault" of confidential information would be a good thing. Similar to how Stripe handles payments with a token, we could all store tokens for User information (eg the Id) and query the vault (or operate on the vault, eg, validate login, or return email, etc) using keys. The service could be hardened (like Stripe) to ensure the data is stored securely, and dete…