But when you do actually press the Del key, the real password dialog appears, and it is on a secure desktop (the "Winlogon" desktop) that can't be manipulated by your rogue program. Your window would be seen only after the user entered their password once, which would look quite suspicious.
Actually, even before Vista, the requirement to press Ctrl-Alt-Del before you entered your password solved the rogue screensaver problem nicely.
No ordinary process can intercept the key combination and when pressed, takes you to a secure desktop that ordinary program cannot draw on so they cannot fake the password screen.
Why does Google think what its doing is any better than the people who sell exploits on the black market?
The black hat guys aren't going to post the exploit on a public bug tracker for everyone to examine, that's why.
Issue #128 might not even be a bug depending on your perspective, as noted in the report!
Then what is the problem with releasing it to the public? They didn't make any statement about its severity as far as I can tell. That evaluation is up to the reader.
they delayed the patch so the compat issues can be resolved... Google publishes the exploit code just to be dicks about it.
As another poster mentioned in another thread, the researchers acknowledge that some bugs need longer to fix, but they think that after a certain time period, it's better if the public knows about it so can they can take appropriate measures while the patch is being developed. That is the reason bugs are publicized. Whether you agree with that is another question.
This is just Google mud slinging.
It might well be, but if it results in more secure software for everyone, I'm all for it.
Personally I think the strict 90-day rule might be a little to strict. Rather than speculating on Google's ulterior motives, we should discuss whether this move makes software more secure as a whole.
You don't need every reporter to publicize it. You just need one reputable researcher to come out and say "Most the bugs I reported to MS haven't been fixed," and it would prove your point. The fact that we don't see that makes your story highly unlikely. By the way, you are also alleging that they are knowingly publishing false information on their web site. (As you said they only patch bugs that they know are being exploited, but most of their issued bulletins said the bugs are not being exploited.)
I don't like defending Microsoft (they certainly deserve their bad reputation), but your accusation is really going too far. No large company is going to do that.
And yet Microsoft has a known policy that they don't fix any exploit proven or not unless it is actively being exploited
Can you please cite the policy?
A quick glance through the Microsoft Security Bulletins reveals that most of them have not been actively exploited before being patched.
Of course you could argue that Microsoft is lying, but many security researchers do (privately) report vulnerabilities to Microsoft, and you really don't think some of them will publicize the bugs if they aren't fixed in, like, a year?
Or are you actually trying to say they don't fix them unless they have been reported, which is an entirely different thing?
CloudFlare has retracted their statement that private key compromise is very hard.
They started a challenge and at least 2 people successfully got private keys from their Heartbleed-enabled server with as few as 100K requests. (I am sure that with some optimization, the number could be even lower.)
Can you guess where the password is, now? (And those didn't even take that many tries)
I have not seen actual SSL private keys floating around just yet, but given that the original researchers said they managed to get private keys from their own servers, I think it is reasonable to assume that some production servers must have already leaked them.
Always turn off SSL validation, because it's totally worthless.
Yeah, because if a sufficiently motivated person can always pick a lock, we should just remove all locks?
With certificate validation, someone will have to compromise a CA (admittedly, any trusted CA will do) and do a MITM to get your data.
Without certificate validation, anyone who can do a MITM can get your data.
And you seem to think that the difficulty of pulling a MITM attack is about the same as compromising a CA.
It is not: Just set up a rogue Wi-Fi hotspot in a cafe or other public place and wait for people to connect. Then, there are off-the-shelf software for sniffing SSL data using rogue certificates generated on the fly (which would now be accepted since your turned off validation)
See: Are MITM attacks extremely rare?
I agree that the chances of you getting actually MITM-ed on your typical connection are pretty slim, but then the chances of getting eavesdropped are pretty slim too, so why are you still advocating to use SSL then? (I assume you are because otherwise it doesn't make sense to say "turn off validation")
And I would argue that if you can do passive eavesdropping and you are not actually one of the endpoints, you probably already control a node in the middle, and already well-positioned to do an MITM.
But yes, the CA system definitely has its flaws and can't keep up with some new attacks. There are several projects trying to fix this part of SSL. But I find it interesting that instead of proposing a solution, you are effectively proposing that we turn off all security.
Are text messages significantly expensive outside of the US?
I live in Hong Kong, and most carriers charge HK$0.6 (about US$0.08) for each text message between different carriers. I have once been charged HK$200 (US$25) a month just for sending those.
So yes, the lower cost was a big reason of WhatsApp's success (at least here).
Slashdot Mirror
I'm supposed to download binaries that don't have Authenticode signatures, from a web server that doesn't support TLS.
Actually, the download server that it links to supports TLS now.
But yes, I completely agree that the switch to 2048- or 4096-bit keys is long overdue...
But when you do actually press the Del key, the real password dialog appears, and it is on a secure desktop (the "Winlogon" desktop) that can't be manipulated by your rogue program. Your window would be seen only after the user entered their password once, which would look quite suspicious.
Actually, even before Vista, the requirement to press Ctrl-Alt-Del before you entered your password solved the rogue screensaver problem nicely.
No ordinary process can intercept the key combination and when pressed, takes you to a secure desktop that ordinary program cannot draw on so they cannot fake the password screen.
Why does Google think what its doing is any better than the people who sell exploits on the black market?
The black hat guys aren't going to post the exploit on a public bug tracker for everyone to examine, that's why.
Issue #128 might not even be a bug depending on your perspective, as noted in the report!
Then what is the problem with releasing it to the public? They didn't make any statement about its severity as far as I can tell. That evaluation is up to the reader.
they delayed the patch so the compat issues can be resolved ... Google publishes the exploit code just to be dicks about it.
As another poster mentioned in another thread, the researchers acknowledge that some bugs need longer to fix, but they think that after a certain time period, it's better if the public knows about it so can they can take appropriate measures while the patch is being developed. That is the reason bugs are publicized. Whether you agree with that is another question.
This is just Google mud slinging.
It might well be, but if it results in more secure software for everyone, I'm all for it.
Personally I think the strict 90-day rule might be a little to strict. Rather than speculating on Google's ulterior motives, we should discuss whether this move makes software more secure as a whole.
You don't need every reporter to publicize it. You just need one reputable researcher to come out and say "Most the bugs I reported to MS haven't been fixed," and it would prove your point. The fact that we don't see that makes your story highly unlikely. By the way, you are also alleging that they are knowingly publishing false information on their web site. (As you said they only patch bugs that they know are being exploited, but most of their issued bulletins said the bugs are not being exploited.)
I don't like defending Microsoft (they certainly deserve their bad reputation), but your accusation is really going too far. No large company is going to do that.
And yet Microsoft has a known policy that they don't fix any exploit proven or not unless it is actively being exploited
Can you please cite the policy?
A quick glance through the Microsoft Security Bulletins reveals that most of them have not been actively exploited before being patched.
Of course you could argue that Microsoft is lying, but many security researchers do (privately) report vulnerabilities to Microsoft, and you really don't think some of them will publicize the bugs if they aren't fixed in, like, a year?
Or are you actually trying to say they don't fix them unless they have been reported, which is an entirely different thing?
CloudFlare has retracted their statement that private key compromise is very hard. They started a challenge and at least 2 people successfully got private keys from their Heartbleed-enabled server with as few as 100K requests. (I am sure that with some optimization, the number could be even lower.)
Forgot to write the source for the images: http://arstechnica.com/security/2014/04/critical-crypto-bug-exposes-yahoo-mail-passwords-russian-roulette-style/
Can you please tell me where the passwords are in this memory dump ...
Have you ever seen a real exploited piece of data?
These are taken from Yahoo production servers, a day or two ago:
http://cdn.arstechnica.net/wp-...
http://cdn.arstechnica.net/wp-...
Can you guess where the password is, now? (And those didn't even take that many tries)
I have not seen actual SSL private keys floating around just yet, but given that the original researchers said they managed to get private keys from their own servers, I think it is reasonable to assume that some production servers must have already leaked them.
Always turn off SSL validation, because it's totally worthless.
Yeah, because if a sufficiently motivated person can always pick a lock, we should just remove all locks?
With certificate validation, someone will have to compromise a CA (admittedly, any trusted CA will do) and do a MITM to get your data. Without certificate validation, anyone who can do a MITM can get your data.
And you seem to think that the difficulty of pulling a MITM attack is about the same as compromising a CA. It is not: Just set up a rogue Wi-Fi hotspot in a cafe or other public place and wait for people to connect. Then, there are off-the-shelf software for sniffing SSL data using rogue certificates generated on the fly (which would now be accepted since your turned off validation) See: Are MITM attacks extremely rare?
I agree that the chances of you getting actually MITM-ed on your typical connection are pretty slim, but then the chances of getting eavesdropped are pretty slim too, so why are you still advocating to use SSL then? (I assume you are because otherwise it doesn't make sense to say "turn off validation") And I would argue that if you can do passive eavesdropping and you are not actually one of the endpoints, you probably already control a node in the middle, and already well-positioned to do an MITM.
But yes, the CA system definitely has its flaws and can't keep up with some new attacks. There are several projects trying to fix this part of SSL. But I find it interesting that instead of proposing a solution, you are effectively proposing that we turn off all security.
Are text messages significantly expensive outside of the US?
I live in Hong Kong, and most carriers charge HK$0.6 (about US$0.08) for each text message between different carriers. I have once been charged HK$200 (US$25) a month just for sending those. So yes, the lower cost was a big reason of WhatsApp's success (at least here).
Yes, AES-GCM is now supported in Firefox 27
Fedora has had the "sandbox" command for some years which uses SELinux to set up a disposable sandboxed context for running a program.
Since Fedora 17 there is also a "virt-sandbox" command using LXC or KVM to do a similar job:
https://fedoraproject.org/wiki/Features/VirtSandbox
Well, I live in Hong Kong and we have 1Gbps fiber-to-the-home at HK$260 or about US$33...
http://www.three.com.hk/website/appmanager/three/home?_nfpb=true&pageid=c11001&_pageLabel=P600193131219996753703&lang=eng
https://apply.hkbn.net/orp/eng/orp_nc.jsp?step=chkcoverage&t=2&role=B&orp_type=