Please create an account to participate in the Slashdot moderation system

 



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 Re:What should happen and what will happen (Score 1) 122

Using memory dependent hashes works better if one is a small server since one will rarely have a lot of people sending in their passwords at the same time, so the RAM space you need isn't that large. If you are a large organization then this doesn't work as well because you then need room to be able to do many such calculations functionally simultaneously.

Meh. If you are a large organization, you can afford more.

Anyway, the point is that you should turn it up as much as you can afford.

I agree that there's a linear v. exponential difference there(although for many of these it is more like linear and subexponential due to algorithms like the number field sieve),

Yes, NFS is subexponential, but not very "sub". And anyway, RSA is old, broken crypto which should be migrated away from.

but the rest of your comment is essentially wrong. We keep keys just long enough that we consider it to be highly unlikely that they are going to be vulnerable, but not much more than that.

I hate to resort to appeal to authority, but the actual analysis required to prove it is way more effort than I have time for this morning. Take a look at keylength.com, it has a host of authoritative references.

In fact, it would be a lot safer if we increased key sizes more than we do, but there are infrastructural problems with that. See e.g. discussion at http://crypto.stackexchange.com/questions/19655/what-is-the-history-of-recommended-rsa-key-sizes

Heh. In my previous reply I actually typed a long section about why RSA is a weak counterexample to my argument, but deleted it because it's nitpicking. Since you chose to pick that nit...

It's a valid counterexample because RSA key generation, and, to a much lesser extent, RSA private key operations, are computationally expensive enough to stress low-end devices (an issue I often have to deal with... I'm responsible for some of the core crypto subsystems in Android). But it's a weak counterexample because RSA is not modern crypto. It's ancient, outmoded, we have some reasons to suspect that factoring may not be NP hard, using it correctly is fraught with pitfalls, and it's ridiculously expensive computationally. And even still, the common standard of 2048-bit keys is secure for quite some time to come. As that stackoverflow article you linked mentions, the tendency has been to choose much larger-than-required keys (not barely large enough) rather than tracking Moore's law.

So, yeah, if you use an outdated, ridiculously expensive algorithm, and you do it on very low-spec hardware, and you want it to be secure for a very long time then, yeah, you might end up having to use barely-large-enough key sizes.

Don't do that. For asymmetric crypto use ECC. Preferably with an Edwards curve, so you don't have to deal with niggling suspicions that the curve is weak in some obscure way known only to the NSA.

Comment Re:Hard wired (Score 1) 155

As hunter-gatherers (you know, in the time before writing and the invention of religion)

Before writing, yes. I strongly suspect that religion existed even then. All of the hunter-gatherer societies that survived to historical times had religions, often quite sophisticated ones.

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

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

... 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:Left and right (Score 1) 146

My experience from my coursework was that the cited studies seemed to me to be pretty rigorous. There was an entire section dedicated to what might have been titled "junk science", though as I recall the authors of the textbook used a somewhat more diplomatic term. In there were all kinds of commonly-held disorders like pre-menstrual syndrome, seasonal affective disorder in the like where research suggests that while the disorders may be real, they in fact effect a far smaller group of people than earlier studies had claimed. In other words, even in psychology it sure looks to me like there is at least some psychologists who follow valid methodological principles.

The other thing to remember is that "psychology" is a pretty damned broad term, and that in a lot of cases other professions like psychoanalysts, psychiatrists, counselors and the like often get lumped in, and in some cases these other groups publish in journals of varying degrees of quality. That's not to say that some of these people don't adhere to pretty strong methodologies, but it does tend to be a bit of a wild west in some cases. But when you're talking about cognitive psychology and other similar branches, there's a lot of overlap there that pulls in neurological experts, behavioral experts and the like who sit within the harder edges of the psychology field. It most certainly isn't all just kooky neo-Freudians.

Comment Re:For variable values of "practical" and "relevan (Score 2) 122

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 3, Informative) 122

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:Left and right (Score 1) 146

Having taken a college-level psychology course (which of course makes me an expert in the field!) I can tell you that psychology isn't necessarily as soft as you think, and while there are certainly holdover schools of psychology that are based on partial or total rubbish, when you start talking about cognitive psychology and behaviorism, these are just as hard a science as physics or geology, to the point that I got the strong impression that my instructor viewed many of the other schools pretty dimly as being as much wishy-washy metaphysics as anything else. Psychology is an awfully big field, so claiming most of it is rubbish is deeply unfair.

Comment Re:My experiences in other companies and opinions. (Score 1) 176

Of course there has been in a lot of research on management styles, some of it predating WWII which suggested that bullying management style may bring about short-term gains, but usually at the cost of a paranoid and low-morale organization which can negatively effect long term performance.

I've only been yelled at once in my working life, and while it scared the shit out of me to be sure, the only take-away I had was that my boss was a fucking asshole. I could only work as fast as I was going, and because he was a cheap asshole, he wouldn't hire someone else to take over some of my sysadmin role so I could more coding.

Comment Re:Left and right (Score 1) 146

I see little evidence that science is regaining ground. There has been far too concerted an effort in the last ten to fifteen years to demonize scientists, to make them out to be profiteering frauds. In the end reality will very much bring back the pro-science movement, but for now, even on Slashdot, the attitude on everything from climate change to basic research is incredibly negative.

Comment Re:The magic is dead. (Score 5, Interesting) 146

Computing is pretty much ubiquitous nowadays. When I first got into computing back in grade school around 1981-82, computers were just this incredibly awesome thing. There was a pioneering spirit to the home computing world. I remember taking my crappy little Radio Shack computer to local meetups, and you'd have everyone from ten year olds like myself to grizzled old guys (who could actually afford cool peripherals like disk drives and the like). That persisted to some extent until the early 1990s, with the earliest versions of Linux like the original Slackware release being the swan song of an age of computing that had persisted since the mid-70s. Once the Internet really overtook the old BBS culture, that was the final nail. I blame it all on AOL!

I can remember pouring through Byte magazine back in the mid-80s and just salivating over the idea of having a modem or a double-sided floppy drive. It was just a very optimistic age. I found an old box of computer magazines from the era, and still smiled at the three page BASIC program listing for some sort of text adventure game, remembering how I built my first one based on a how-to book I'd ordered from an advertisement in the back. Good times.

Comment Re:Mostly, send the snowflakes to Venezuela (Score 1) 176

This is why I wish Slashdot would get rid of ACs. I have no idea who I'm debating. Are they responding to what I wrote? Are they the parent?

AT any rate, lots of people of every stripe care about money. Whoever you are, the AC I was responding to heavily suggested that Milo is vindicated because he makes lots of money. How that squares with your post is beyond me.

Comment Re:My experiences in other companies and opinions. (Score 1) 176

In general I would frown on any employees, but in particular a manager, getting into a shouting match, homophobic slur or otherwise. In a manager I would find this particularly disturbing, because you should really be promoting managers based on leadership qualities, and shouting at your subordinates doesn't display leadership, it displays bullying. As to a specifically homophobic slur, like it or not, we live in a litigatory age, and, as you point out, if the staff member being yelled at were gay, then your manager has crossed a realm into pain. As others have pointed out, this kind of culture comes down from the top. Good sound senior management would not allow the workplace to behave this way.

The fact is that in any workplace, but particularly a large one, you're going to have conflicts, and on occasion they may get out of hand. I agree that the homophobic slur is the least serious of them, but it still isn't something that should be tolerated. An off the record warning would be exactly how I'd deal with that as well, but if the employee persisted in that sort of conduct, then it would have to move on to a more formal disciplinary process.

Oh, and to all those brave alt-right haters, want to end up in court, go tell a subordinate who complains they were threatened or abused to suck it up.

Slashdot Top Deals

We all agree on the necessity of compromise. We just can't agree on when it's necessary to compromise. -- Larry Wall

Working...