The attack's impact for WPA-TKIP, a wireless security standard still used by old Wi-Fi equipment, is even worse. Breaking into wireless networks that use this encryption method takes an hour or less with the RC4 NOMORE attack.
"In general, any protocol using RC4 should be considered vulnerable," the researchers said.
Even with this significant time reduction, not everyone is convinced that this new attack is practical enough to become widely used.
"I think even 48 hours is an unreasonable amount of time to expect that a browser will be continuously open and sending over 4,000 requests per second the whole time," said Ivan Ristic, director of engineering at security vendor Qualys, via email. "If the attack takes longer, it's even less likely."
Also, the researchers chose to present the success of their attack against a 16-character cookie, which is too small, Ristic said. "That's usually only 64 bits of security (hex-encoded) whereas you should have at least 128."
And while there are some cookies that can persist for long periods of time, like those used to automatically log users back into Web sites, the typical session cookies should be reset much more often, Ristic said. "I usually go for 12 hours -- effectively one working day."
Despite all that, Ristic, who is also the creator of the popular SSL Labs test for HTTPS servers, believes that there should not be too much focus on how practical the attack is.
"RC4 is broken and is going away," he said. "This attack should be used as an excuse to speed up the deprecation."
Data gathered by Qualys' SSL Pulse project, which analyzes the TLS configurations of the world's top 150,000 HTTPS websites, shows that around 16 percent of them still use RC4 with modern browsers so are directly vulnerable. Another 44 percent support RC4-based ciphersuites, but likely only use them with a small number of legacy clients.
TLS supports multiple ciphersuites -- combinations of encryption, hashing and key exchange algorithms. These ciphersuites are listed in a TLS server's configuration in the order of preference.
If a server is configured to prefer RC4, clients connecting to it will use RC4, even if they also support more modern ciphers. If the server prefers a modern cipher, but the client doesn't support it, the connection will be encrypted using a cipher they both support, and that common cipher could be RC4.
HTTPS server administrators should disable support for RC4, Ristic said. "I believe that to be viable, except possibly in some special circumstances when dealing with very old legacy clients. It's certainly something that every organisation can check by enabling appropriate logging in their existing installations."
Sign up for CIO Asia eNewsletters.