Microsoft Warns Customers Away From RC4 and SHA-1 92
Trailrunner7 writes "The RC4 and SHA-1 algorithms have taken a lot of hits in recent years, with new attacks popping up on a regular basis. Many security experts and cryptographers have been recommending that vendors begin phasing the two out, and Microsoft on Tuesday said it is now recommending to developers that they deprecate RC4 and stop using the SHA-1 hash algorithm. RC4 is among the older stream cipher suites in use today, and there have been a number of practical attacks against it, including plaintext-recovery attacks. The improvements in computing power have made many of these attacks more feasible for attackers, and so Microsoft is telling developers to drop RC4 from their applications. The company also said that as of January 2016 it will no longer will validate any code signing or root certificate that uses SHA-1."
Pay no attention to the man behind the Back Door.. (Score:5, Insightful)
Why in gods name would a company that backdoored their entire crypto stack to the NSA worry that
some crypto code is weak?
Re: (Score:2)
Re: (Score:2)
Because the NSA doesn't like when someone else can get your files.
It slows them down.
Re: (Score:2)
Because although they gave it the NSA, they still don't want the Chinese government to compromise it?
Re:Pay no attention to the man behind the Back Doo (Score:4, Insightful)
Because... the NSA pays MS for backdoors, whereas the Russians don't?
Because... the NSA tries to stay under the radar, whereas other malware often doesn't? (ex. adware, bot-nets. Thus damaging the MS "experience".)
Because... the NSA wants to know your secrets, whereas scammers want to use your secrets? (ex. Credit card payments. Further damaging the MS "experience".)
Just a few thoughts.
Re: (Score:2)
Why does the NSA want to know my secrets if they are not going to use it?
Re: (Score:1)
Re: (Score:1)
[clickety-clickety]
There you go. Plenty of evidence. Oh, you want to SEE the evidence? Well, there's this thing called FISA, that says you aren't allowed to. Because, well TERRORISM.
Fnord.
You, over there: Papers, please.
Re: (Score:2)
Why in gods name would a company that backdoored their entire crypto stack to the NSA worry that some crypto code is weak?
Because they now have a better back door that needs to become the default.
Re: (Score:2)
Why? Because the attacks on RC4 are becoming feasible for ordinary well-organized criminals, and there might be other agencies aside form the NSA who might try brute-forcing SHA1.
The NSA is mainly a danger for business outside the US - and perhaps for Megaupload-like companies within the US for which some state prosecutor could imagine and construct some criminal copyright infringement case, although it seems that the NSA doesn't habitually help out the FBI.
Re: (Score:2)
They don't admit to helping the FBI. Look up 'parallel construction.'
Re: (Score:2)
They no longer deny helping the FBI, DEA, ATF, and county sheriffs.
Re: (Score:2)
We have a real problem where the PCI scanning vendors are so freaked out about BEAST attacks (where client hardening is the correct solution) that the only cipher they'll accept (server side) that's FIPS compliant and BEAST resistant is RC4.
What they should be doing instead is scoring people down for not doing ephemeral key exchange, scoring people down for not using TLS 1.2 and stop freaking out about CBC on the server side when getting rid of it is not even a thorough solution (fear of CBC is overblown, e
Re: (Score:2)
Re: (Score:2)
[for BEAST] client hardening is the correct solution
Indeed. TLSv1.1 is not vulnerable, and most browsers that are still limited to TLSv1.0 are able to use the 1/n-1 split workaround to BEAST (notable exception is Safari on MacOS up to X.8). The right approach would be to detect TLSv1.0 clients that do not use 1/n-1 split and deny them access before they exchange anything sensible.
Re: (Score:2)
Because Microsoft doesn't deliberately open back doors for free.
Re:The time has come the walrus said... (Score:4, Informative)
MD5 is broken, SHA1 has been weakened slightly but it isn't broken.
The term broken is only used when it is trivial to crack and/or forge.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:3)
MD5 is broken, SHA1 has been weakened slightly but it isn't broken. The term broken is only used when it is trivial to crack and/or forge.
Sorry to nitpick it really depends on how you use the algorithm. MD5 is broke for signatures yet still perfectly acceptable for other purposes.
Re: (Score:2)
MD5 is broken, SHA1 has been weakened slightly but it isn't broken. The term broken is only used when it is trivial to crack and/or forge.
Sorry to nitpick it really depends on how you use the algorithm. MD5 is broke for signatures yet still perfectly acceptable for other purposes.
This is true of anything. All statements about security are relevant only within a given set of threat models.
Re: (Score:2)
That's not the definition of "broken" that cryptographers use.
Re: (Score:2)
MD5 is broken, SHA1 has been weakened slightly but it isn't broken.
Same for RC4. The cypher is still OK, you just have to initialize it better (his has been known about for decades, the fact that Microsoft isn't doing it is the real news).
Re: (Score:1)
Specifically, you "just" need to discard the first n bits of the keystream, and n seems to get larger every year. Do excuse me if that doesn't inspire confidence.
Look, if you absolutely need to support some legacy application that only speaks RC4, that's one thing, but there's no reason beyond that to choose it over AES-256-GCM these days.
Re:The time has come the walrus said... (Score:5, Informative)
In the field of cryptography, the term "broken" is used whenever the work factor to crack is less than that of a brute force attack. Stevens' 2^61 collision attack against SHA1 means that SHA1 is broken.
Re:The time has come the walrus said... (Score:4, Funny)
No more RC4? No more SHA1? Next they'll be telling me to patch against WMF exploits.
Thank God we can still depend on ActiveX!
Re: (Score:2)
Or that we shouldn't use WEP for our wireless encryption.
If SHA-1 is a problem, what does that make MD4? (Score:3, Insightful)
Microsoft continues to make use of MD4 for password hashing in the Security Account Management part of the registry. The authors of MD4, RSA, had recommended for a long time switching to MD5 and now recommends using MD6, Other members of the security community also recommend using a stronger hash function, combining a salt string with the password and doing multiple rounds of the hash function. Microsoft has failed to do any of these recommendations.
MS-CHAPv2 also continues to be part of Microsoft's offering as well. Support for this is included in their OS for PPTP, iSCSI and 802.1x (and possibly others). As pointed out in the article, attacking MS-CHAPv2 is now as simple as cracking a single DES key.
It is nice the Microsoft is recognizing some of the advice of the security community and taking steps to phase out SHA-1 and RC4. But I have a hard time applauding Microsoft when this is just the tip of the iceberg of weak hashing functions and protocols in popular use in their software.
Re: (Score:1)
This is likely the main motivation on the Microsoft move. Customers have stopped upgrading the OS from clients and servers as MS has changed both of them to the new metro-ui. But this move may backfire them, as if a customer is threatened and pissed, he can nowadays move to competitors with the same amount of employee re-training as to new MS OS's.
Re: (Score:2, Informative)
Funnier (or sadder) still, NTLM v2 is unsalted rc4.
Re:If SHA-1 is a problem, what does that make MD4? (Score:4, Interesting)
Microsoft continues to make use of MD4 for password hashing in the Security Account Management part of the registry.
Playing devils advocate no password hash is really secure even if you check salt, algorithm and amplification boxes unless password itself is unrealistically good. Sure all of those things help *ALOT* except still not good enough I still wouldn't trust it to protect my user database. Operating under a secure syskey mode is prudent.
MS-CHAPv2 also continues to be part of Microsoft's offering as well. Support for this is included in their OS for PPTP, iSCSI and 802.1x (and possibly others). As pointed out in the article, attacking MS-CHAPv2 is now as simple as cracking a single DES key.
Still waiting for WP8 wireless to even warn the user before completely failing to validate TLS certificates. Bad enough when a vendor makes a mistake when designing a protocol... When implementing something they KNOW to be totally insecure by *design* .. now that represents a whole new realm of incompetence.
It is nice the Microsoft is recognizing some of the advice of the security community and taking steps to phase out SHA-1 and RC4. But I have a hard time applauding Microsoft when this is just the tip of the iceberg of weak hashing functions and protocols in popular use in their software.
This is only because it is in Microsoft's best interests their signatures not be hacked as it would among other things doom the trusted platform. They don't seem to have the same level of concern about our passwords being compromised.
Worth noting even with known attacks SHA-1 is still plenty secure for signatures... For all we know SHA-1 may never see a serious exploit but SHA-2 could be broken tomorrow. (Devil you know vs the one you don't) SHA-1 at least has had some exposure to the real world for a number of years.. SHA-2 currently very little.
I think the guys who designed original TLS PRF conceptually had the solution about right XORing multiple hash algorithms such that if one fails the underlying thing is not totally doomed. Virtually impossible to quickly resign global trust hierarchy even less feasible to resign code to react to a serious breach.
SHA-2 (Score:2)
SHA-2, more specifically its SHA256 ^2 variant, is not only used to secure messages in HMAC, but also in bitcoin for validating blocks (adding pages into the common distributed ledger), and thus also in bitcoin mining.
Given the current massive craze in bitcoin, there's been massive development around SAH256.
If SHA256 was cracked, somebody would be laughing on the way to the bank, after having mined most of the coin.
That didn't happen (current bitcoin production is still spread among the most popular mining
Re: (Score:2)
Playing devils advocate no password hash is really secure even if you check salt, algorithm and amplification boxes unless password itself is unrealistically good.
Passwords have a variety of problems but being subject to brute force attacks needn't be one of them. Their security (or lack thereof) relies on exploiting the asymmetry of effort required to verify vs crack, and reasonable passwords have on the order of 30 bits of entropy. That does require that the password be fairly good, but not "unrealistically good". The key is to calibrate the computation required to verify the password so that searching is infeasible. For example, if it takes 1/10th of a CPU-second
Re: (Score:2)
*sigh* ok then... (Score:1)
... what do we replace all our database password hash columns with now?
Re: (Score:3)
Asterisks.
Re: (Score:1)
Well, one possible solution would be to calculate a "double hash" where the first hashing is done with the old algorithm, and the hash produced by that is then hashed with the new algorithm. It should provide the same security as only using the new algorithm, but allows you to convert all the hashes from the old algorithm which you already have to the corresponding new hashes without the need to have the passwords.
So for example if you used MD5 hashes before, and want the security of SHA-256, you use sha256
Re: (Score:1)
Curious: why doesn't the higher strength transfer to signatures as well?
Re: (Score:1)
Because with digital signatures the attack is to generate a second text which causes the same hash value. Of course given the plain text, you certainly can generate its weak hash (so the fact that the weak hash is strong-hashed afterwards doesn't prevent you from getting the weak hash value), and if you manage to create a second, malicious text which creates the same weak hash value, then of course re-hashing that value with a strong hash doesn't help: Hashing the same value gives the same result.
The situat
Re: (Score:3)
There's trolling, and then there's trolling on drugs that only got invented last week. Damn dude, whatever that new stuff is, it's no good for you.
Why the long window? (Score:2)
SHA1? insecure? (Score:4, Interesting)
I can understand RC4.
I can understand MD5.
But SHA1? right now, according to wikipedia, a full collision attack requires something like $2.77M of computing power on the cloud...
maybe a less if you have you own supercomputer, but even at $1M it sound a lot...
So why warn away from SHA1 NOW? what are we going to use? md5? md4? remember that while keccak was chosen as the SHA3, they still have to release the complete details on how it must be implemented -- number of rounds and such -- so SHA3 *NOW* is not an option.
I'll start taking microsoft seriously on this once they phase out MD4, RC4, MD5 from their existing standards and products.
Re:SHA1? insecure? (Score:5, Insightful)
So why warn away from SHA1 NOW?
If developers are using it today, then you will be next year, and the year after, when attack are more feasible.
what are we going to use?
I'm not a cryptography expert but if SHA-1 is too weak, and SHA-3 not quite there yet, why not SHA-2?
Re:SHA1? insecure? (Score:4, Informative)
Specifically the 2nd SHA family are usually called SHA-224, SHA-256, SHA-384, and SHA-512
Re: (Score:2)
remember that while keccak was chosen as the SHA3
and there's still a fight brewing over keccak rounds - NIST wants the rounds reduced to improve performance, at the same time we know that NSA has been weakening public crypto to hurt security. This may not be the case with keccak but the implications are strong enough and stock keccak good enough, that keccak, as submitted, should become SHA-3, not the reduced round version.
If that doesn't happen, we may just ignore NIST and do a community standard based on
Re: (Score:2)
I can understand RC4.
I can understand MD5.
But SHA1? right now, according to wikipedia, a full collision attack requires something like $2.77M of computing power on the cloud... maybe a less if you have you own supercomputer, but even at $1M it sound a lot...
So why warn away from SHA1 NOW? what are we going to use? md5? md4?
Because SHA1 has known weaknesses, even if they're not practically exploitable, and because attacks always get better. Would it shock you to hear tomorrow about a new attack on SHA1 that allows collisions to be generated for a few hundred dollars of computation? It wouldn't shock me. I don't expect it, but it would not be surprising.
The alternative to SHA1 right now is SHA2. Or if you want you can use Keccak as published, but you may have to change it when the final standard is released. Depending on the
Re: (Score:2)
Let's say Merck has a new drug in phase 3 clinical trials, it seems to cure cancer and the common cold. They plan to publish the results of the trials tomorrow, and everyone expects great success
If you can crack RC4, you can MitM the private session between Lead Researcher Fred and the board. Whoah, this miracle drug works as advertised, except it causes permanent impo
Re: (Score:2)
What about Git? (Score:3)
Git is a great system, but it relies on SHA1. If SHA1 has feasible attacks, is git going to stay on SHA1 or will it move to something more secure? Can it even do so without breaking compatibility?
Re: (Score:3)
Git is a great system, but it relies on SHA1. If SHA1 has feasible attacks, is git going to stay on SHA1 or will it move to something more secure? Can it even do so without breaking compatibility?
SHA1 as used in Git proves that a particular commit has the contents and the ancestors that the person with the repo says it does. It prevents two different people from saying, "this is what the source looked like at this point in time". So in practice, coming up with a collision attack in that scenario wouldn't be much use because whatever you come up with to generate the collision obviously isn't source code :)
That said, replacing it with something else would essentially involve rebasing the entire repo,
Re: (Score:3)
So in practice, coming up with a collision attack in that scenario wouldn't be much use because whatever you come up with to generate the collision obviously isn't source code :)
You fall into the trap of trying to find reasons for how it is *not* a problem. But *every* single time a weakness is found it opens up to multiple different attacks. Just because you cannot imagine a possible attack using a vulnerability does not mean that such attack vectors do not exist.
Case in point: During the total pwnage (rootkit installed and active for the better part of a month - possibly longer) of kernel.org and multiple other Linux Foundation sites back in 2010 (we still have not seen a post mo
Re: (Score:2)
I call BS on that "*every*"
Re: (Score:1)
Re: (Score:2)
Attacks against SHA1 are still purely theoretical: it would take several million dollars of hardware+electricity to produce a single collision. To subvert a git repository, you need to be able to have a commit of your own legitimately accepted, with no modifications (like Signed-off-by: by whoever took your patch, or modifications to the file you edit), and then, you need to pwn the server holding the public repository to replace that commit with the nefarious half of your collision.
That's a MASSIVE undert
Re: (Score:2)
There's a difference between using SHA1 for verifying integrity and using SHA1 for cryptographic purposes.
I don't think it's GIT's intent to cryptographically prove that nobody has injected a modified commit in your history while going through extreme effort to mask that single-commit modification.