Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. ×

Comment Dont worry I've got a backup (Score 3, Funny) 51

As it turns out I have a backup sample, because you have to keep it at incredibly high pressure I keep it in the much more reliably pressurized environment of a dorm room with two Chemical Engineering majors.

Indeed because of the pressures involved I had to add some padding around the sample to prevent the rare metal from being crushed.

You can come collect it whenever, except of course when there's a sock on the door handle (P.S. there is never a sock on the door handle).

Comment Re:What should happen and what will happen (Score 1) 96

The problem with that is on the other practical end: if you massively increase the resources needed will also increase the server side resources; it won't be as bad as it will be on the cracking end, but server resources are expensive.

It won't be as bad as on the cracking end, that's the whole point. The reason for doing password hashing is to exploit the asymmetric level of effort between hashing and brute force search. To make that work, though, you do need to invest as much as you can afford in the server, to move the bar for the attacker as high as possible -- hopefully out of reach of all but the most serious. If you can't afford very much, fine, but realize that you're also not setting the bar very high.

But this is exactly why good password hashing algorithms are moving to RAM consumption as the primary barrier. It's pretty trivial for a server with many GiB of RAM to allocate 256 MiB to hashing a password, for a few milliseconds, but it gets very costly, very fast, for the attacker. And if you can't afford 256 MiB, how about 64?

What you definitely do not want is a solution that takes microseconds and uses a few dozen bytes. That creates a trivial situation for the attacker given modern hardware, and your server absolutely can afford more than that.

This is similar to why we don't use much longer keys for public key encryption and use really large primes for DH key exchange.

Nope. The leverage factor in the password hashing case is linear, since the entropy of passwords is constant (on average). The leverage factor for cryptographic keys is exponential. The reason we don't use much longer keys for public key encryption, etc., is because there's no point in doing so, not because we can't afford it. The key sizes we use are already invulnerable to any practical attack in the near future. For data that must be secret for a long time, we do use larger key sizes, as a hedge against the unknown.

Comment Re:Are two hashes better than one? (Score 1) 96

... however it's worth noting that there are currently no ways of finding a collision for both MD5 and SHA-1 hashes simultaneously

Any crypto geeks want to weigh in on the truth of this statement? I've often wondered about this. Wouldn't using two hash algorithms be easier and more effective over the long term than getting the whole world to upgrade to the Latest And Greatest Hash every ~10 years?

MD5 + SHA1 is a "new hash algorithm". Think about what you have to do to shift to a new algorithm... all of the message formats that have to be updated, all of the stored values that have to be recomputed, all of the cross-system compatibility dances you have to do to ensure that you can upgrade both sides (or all sides; there are often more than two) in order to update without having to make some error-prone attempt to cut over simultaneously.

The challenge of changing hash algorithms has nothing to do with getting correctly-implemented source code for a new algorithm. That's super easy. The challenges are all about how to handle the changeover, which is exactly the same whether you're switching to an actual new algorithm that incorporates the latest ideas and is (currently) completely invulnerable to all known attacks, or to a combination of old, broken algorithms that may or may not be better than either one alone.

The right solution is to build systems with algorithm agility and algorithm negotiation, then to add new algorithms as soon as they're standardized and remove algorithms completely once all parties have updated.

Comment Re:For variable values of "practical" and "relevan (Score 1) 96

That is just my point. There is a big difference between a high-effort attack that is hard to do and a simpler one that has been done mass-scale. The second is a real risk, the first one is pretty irrelevant. Incidentally, the defects of the CA system are systematic, and they cannot be fixed by merely moving to a non-broken hash function.

Comment Re:Then 38,928 Incorporated Cities in US are "Smal (Score 1) 82

If NO ONE else were interested in servicing your entire town sure. Even then, this clause would apply if and only if they ONLY serviced your town and nothing else. Unless your town is 100 miles away from anything else, I don't see that being a real problem in Denmark.

Reno is not a bad example of a town literally in the middle of nowhere.

You would probably think of it as living on the Moon and net neutrality would probably be low on your list of complaints.

Comment Re:For variable values of "practical" and "relevan (Score 1) 96

Not a lot you can do?

Anything that requires signatures is vulnerable to forgery if the signer's certificate specifies SHA1.

An attacker could forge:

1. Software signatures - to slip malware into a software vendor's distribution channels.

That requires a second pre-image attack, not just a collision attack. (What gweihir called "two-sided" rather than "one-sided"... though that is not standard terminology).

2. SSL certificates - to MITM web connections to phish, steal data, or distribute malware.

Also requires a second pre-image attack.

3. Personal digital signatures - to fabricate documents, including emails, transaction, orders, etc that are normally trusted implicitly due to the signature

This one can be done with a collision attack. You generate two different documents which hash to the same value, but have different contents. The PDF format, unfortunately, make it pretty easy to generate documents which look sensible and have this property. It's not possible with more transparent formats (not without a second pre-image attack).

4. Subordinate CA certificates - to create trusted certificates which permit all of the above

The problem lies with #4.

This can only be done with a collision attack if the CA is really, really stupid. Proper CAs should include chain-length restrictions in their certificates. That way even if you can create two certificates which hash to the same value, one of which has the keyCertSign bit set to true (which the CA would refuse to sign) and one of which does not (which presumably you can get the CA to sign), it wouldn't matter because if you used the former to generate other certs, no one would accept them due to the fact that your chain is too long.

The only solution is to discontinue the use of SHA1 internally and to revoke trust for all CAs that still use SHA1.

I certainly agree that any CA still issuing certificates with SHA1 should not be trusted. Any existing certs based on SHA1 should be scrutinized, but most of them are still secure.

Better crypto has existed for a long time---the standard for SHA2 was finalized in 2001, well over a decade ago.

Absolutely. Of course, I say that as the maintainer (ish) of an open source crypto library that still uses SHA1. In systems that weren't originally designed for digest agility, it's often hard to retrofit. Today's news is a nice kick in the pants, though.

Comment Re:What should happen and what will happen (Score 1) 96

The second to last Yahoo security breach was so bad in part because the passwords were hashed with a completely unsalted MD5 https://nakedsecurity.sophos.com/2016/12/15/yahoo-breach-ive-closed-my-account-because-it-uses-md5-to-hash-my-password/. The lack of salting would have been by itself a problem even when MD5 was still considered secure.

Actually, even with salting, no standard cryptographic hash function is appropriate for password databases. You can squeak by if you iterate the hash function enough times, but even that is pretty weak, since it means that an attacker with lots of GPUs -- or, even worse, special-purpose hardware -- can perform hashes so much faster than you can that the key stretching you obtain is minimal.

The state of the art in password hashing is algorithms like Argon2, with parameters that are tuned to require significant amounts of not just CPU time, but RAM and threads. Argon2, tuned to require, say, 10ms of time on four cores and 256 MiB of RAM, is going to significantly strengthen passwords. The RAM requirement means a GPU with 4 GiB of RAM can only test 16 passwords in parallel, making GPU-based cracking essentially useless, since what GPUs provide is huge parallelism. Custom ASICs would do better, but would still run into bottlenecks on the speed of the RAM. Making really fast cracking hardware would require either huge amounts of RAM, or large amounts of extremely fast RAM. Either way, big $$$.

Even better, if at all possible you should use a hash that is keyed as well as salted. Doing that requires having some place to store the key that won't be compromised by the same sorts of attacks that compromise your password database. In most cases that's hard to do. Argon2 will accept a key so you can get both sorts of protection, though if you can be really, really certain that no attacker can ever get the key, then you can use a standard cryptographic hash function in a keyed mode, e.g. HMAC-SHA256, though I'd still recommend using a purpose-designed password hash (e.g. Argon2) in case your key is compromised.

Comment Re:That's what you get for wording the DMCA that w (Score 1) 67

Legally defined bad faith is hard to prove. We would need some metric, like number or proportion of bogus requests where bad faith is legally presumed. Of course, if a reasonable person hearing/viewing the target of the takedown knows it isn't the complainant's property, that too should be presumed to be bad faith..

Comment Hey guess what else this is true of - everything (Score 2) 128

was largely positive, but this changed from the mid-1990s to 2013,

The thing to understand is, this is not limited to tech. There has been an assault for a decade or two now on the public being happy in any way. You are meant to be riled up and agitated.... to what end I cannot say. But the end effect is not good, you can tell this is bleeding into everyone's real lives, affecting relationships and general behavior.

Comment Re:For variable values of "practical" and "relevan (Score 1) 96

Indeed. Not a lot you can do even when you ignore the high effort needed and that it is a 2-sided collision. I do not dispute that you should not use SHA1 when you want security, but the actual attacks possible at this time are pretty much irrelevant. Your list just confirms that. It looks impressive (well, sort of), but when you take into account the effort of each attack and the possible gain, they become meaningless, because higher gains at lower effort are around plenty.

Slashdot Top Deals

"Engineering meets art in the parking lot and things explode." -- Garry Peterson, about Survival Research Labs

Working...