Forgot your password?
typodupeerror
Encryption Microsoft Security Software

Microsoft Warns Customers Away From RC4 and SHA-1 92

Posted by Soulskill
from the avoiding-collisions dept.
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."
This discussion has been archived. No new comments can be posted.

Microsoft Warns Customers Away From RC4 and SHA-1

Comments Filter:
  • by icebike (68054) on Wednesday November 13, 2013 @01:15AM (#45409547)

    Why in gods name would a company that backdoored their entire crypto stack to the NSA worry that
    some crypto code is weak?

    • by AHuxley (892839)
      Its not just the codes used, its the US branded: OS, file systems, "bugs" and files sent.
    • Because the NSA doesn't like when someone else can get your files.
      It slows them down.

    • Because although they gave it the NSA, they still don't want the Chinese government to compromise it?

    • by LongearedBat (1665481) on Wednesday November 13, 2013 @01:52AM (#45409813)

      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.

    • by ruir (2709173)
      Mod parent up please, because it is the truth, wether you like it or not.
    • 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.

    • 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.

    • 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

      • by devman (1163205)
        RC4 is NOT FIPS compliant. Never has been. RSA has never published a spec for RC4. The code just showed up one day on a mailing list from an anonymous source.
      • by manu0601 (2221348)

        [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.

    • by Guppy06 (410832)

      Because Microsoft doesn't deliberately open back doors for free.

  • by fluke11 (1160111) on Wednesday November 13, 2013 @01:25AM (#45409635)

    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:2, Informative)

      by Anonymous Coward

      Funnier (or sadder) still, NTLM v2 is unsalted rc4.

    • by WaffleMonster (969671) on Wednesday November 13, 2013 @03:32AM (#45410225)

      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.

      • by DrYak (748999)

        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

      • by swillden (191260)

        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

    • by ruir (2709173)
      Some protocols maybe be weak, but for instance, you are not supposed to use MS-CHAPv2 on the clear, it is usually encrypted inside a PEAP or TTLS tunnel, which is the standard configuration, for instance for the worldwide academic confederation, EDUROAM.
  • ... what do we replace all our database password hash columns with now?

    • by DavidD_CA (750156)

      Asterisks.

    • by Anonymous Coward

      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

      • by Anonymous Coward

        Curious: why doesn't the higher strength transfer to signatures as well?

        • by Anonymous Coward

          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

  • Plenty of time between now and January 2016 when MS will reject the use of SHA1. I understand that large corporations move slowly, but we have known about SHA1 shortcomings for a while now. I would like to read more about what products are affected, possible attacks in product contexts, and reasons for the long window until retirement! Even Windows 7 mainstream support will end in 2015!
  • SHA1? insecure? (Score:4, Interesting)

    by Luke_22 (1296823) on Wednesday November 13, 2013 @05:33AM (#45410687)

    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)

      by Shimbo (100005) on Wednesday November 13, 2013 @05:43AM (#45410731)

      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?

    • 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

    • by swillden (191260)

      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

    • by pla (258480)
      But SHA1? right now, according to wikipedia, a full collision attack requires something like $2.77M of computing power on the cloud...

      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
  • by markkezner (1209776) on Wednesday November 13, 2013 @10:28AM (#45412197)

    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?

    • by tobiasly (524456)

      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,

      • 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

        • by tangent3 (449222)

          I call BS on that "*every*"

        • by John Allsup (987)
          Git uses SHA-1 to hash the contents of a file, then uses that hash as in internal name.  I imagine it wouldn't be too difficult to modify git to use a different hash (one of the SHA-2 ones) and then create a new repo and check the files into that.  I don't know about transferring history to a repo hashed with a new hashing algorithm, but overall a shift to a different hash would be easy enough.
        • by KiloByte (825081)

          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

    • by lhunath (1280798)

      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.

Be sociable. Speak to the person next to you in the unemployment line tomorrow.

Working...