Please read up on https/SSL/PKI technology used in web browsers. The SecurityNow podcast did a nice series introducing cryptography and the certification schemes it makes possible.
Cryptographically-signed certificates are verified by the browser and a trusted third party (the certificate authority) as a pre-condition for establishing the link. The encrypted nature of the link is almost beside the point: SSL certs guarantee that the site (somedomain.com) you think you are talking to is the real McCoy. That is why the lock is displayed on the address bar, because it signifies the validity of the domain name currently being accessed.
The certs cannot be faked without being detected by the browser. An attacker would have to somehow steal the private key of the site you're connecting to, or the CA's private key, in order to stage a MITM, arp cache or similar attack undetected.
The system assumes that you know beforehand what domain name(s) you want to connect to. It doesn't try to decide for you which sites are "good" or "bad", it simply ensures that the "bankofamerica.com" server you're connecting with is the one that was actually registered with the CA. Thus, you have to check domain spelling.
The card maker wants to be Windows only so don't buy it. Sooner or later hardware vendors will have to come around. Vendors and users will just stick with Windows if the Linux developers do not make it easy to find compatible items when they are hardware shopping. MS are tyrannical, but the Linux devs are indifferent (or perhaps setting up a site with simple hardware search form is beyond their technical ability?).
Make users choose between tyranny and indifference, and they'll probably just stay right where they already are.
Face it. As many others have said, if you go to http://www.paypal.emptymyaccount.com/ you're a moron. You're correct, IF I know what a domain is and how to check it. Yes its simple, but the information has to get passed on from somewhere.
Clearly even Paypal are not willing to tell people to simply check domain spelling and presence of lock symbol in the address bar. This state of affairs is very sad indeed.
If a person knows they should check domain spelling and the lock symbol in the address bar, and they are too lazy to do that... then I'd say they deserve whatever befalls them as a result.
The problem is that few techies are interested in teaching/reminding people about Https and how to use it: Most seem not to understand it, and so point people toward 'solutions' where someone else decides the 'good/bad' status of websites for them.
OpenDNS monitors known phishing sites. Right, and Https is what protects users from phishing sites both known and unknown... assuming people aren't too lazy to check the domain spelling.
* The method shown above is not foolproof, in the case of DNS attacks, or websites with similar names (user types in address, typos, and is sent to another site). That's why your advice is mostly bunk. And where it isn't, a person couldn't rely on it for certainty. That's what https/SSL is for, and shame on you for not mentioning it.
User checks the address bar for A) the lock and B) the domain spelling. Absent any warning dialogs or malware infection or gross idiocy on the bank's end, the connection proof against phishing, DNS attacks etc. (But you cannot do just one or the other: You must check both at the same time!)
Sadly, despite its simplicity, most people don't know how to properly use https and this includes much of the 'techie' set. IMO this means that most people don't really know how to use a web browser.
As I mentioned elsewhere in comments, Firewire allows DMA to be turned off. And MS isn't giving you a way to turn it off.
It is known that Apple's openfirmware disables DMA (hence securing the machine) on its PPC systems when the password is enabled.
Neither OS vendor is actually talking (the Apple fix was discovered by happenstance) which seems to be the real problem here: the desire for secrecy.
OTOH, Linux allows you to turn off DMA, though it is enabled by default.
At this late date, it seems like mainly a Windows problem to me. MS may have provided a fix, but if so then they have told no one, nor has anyone discovered it yet.
Adding a firmware password to my PPC Macs puts them into a heightened security mode that turns off Firewire DMA (and was tested specifically with the hack you referenced). I would expect the Intel units to have this feature also. And the new Linux firewire driver tackles the DMA vulnerability issue too.
What I've read on the subject so far indicates that most or all Firewire chipsets allow operation without DMA, and that it is possible to secure the DMA modes by programming the memory controller to restrict access to specific buffers
FWIW, Apple was similarly "cagey" (actually silent) on the issue, but at least gave us the ability to secure the port through openfirmware.
What I would worry about more are the DMA interfaces that no one is discussing re: security... PCMCIA/PCCard and other hot-swappable ports (PCI-X? eSATA?) that support bus mastering. I'm pretty sure that non-USB-implemented CF slots are a risk.
I think that's a pretty dumb thing to say. It speaks of an attitude that even trying to secure portable devices isn't worth the effort. Thankfully there are readers here who know better.
You could also tweak the system by opening the case and removing the hard drive, or just attaching a thumb drive and copying all the data. Uh, no. USB thumb drives cannot force a system to give up its data, and how are you going to 'tweak' an OS on an encrypted drive with signed bootloader?
Recently I've compared MS sales force to Jehovah's Witnesses, but the reality is often worse than that and the following anecdote reminded me:
Back in 1995 on a public list I wrote a message critical of Microsoft.
They used their DevNet developer database to locate a colleague at my place of work through whom they applied pressure at senior management level, i.e. vailed threats to withdraw discounts etc., in an attempt to prevent further criticism from me.
Fortunately, Microsoft's emails to management actually confirmed everything that I'd said was true. I still have copies with management's handwritten comments.
At least I'm not paranoid anymore - I know what they'll do with all that information.
Incidently you don't "throw up a deceptive IFRAME". Iframes are embedded into the actual html. You can't tell it is there. Your address bar only tells you about the "parent" page. No dice:
The browser invariably knows when a portion of the page has been fetched from a third party. The lock is crossed-out, and that would have also come with a warning dialog (which I have personally experienced on several occasions).
The Netcraft article is sloppy reporting, as it omits mention of any warning dialogs. The author makes a common assumption that the user will actively continue with a compromised connection instead of canceling it... using that assumption, Cardspace can do no better unless it refuses to connect unconditionally (which is no more than a matter of default browser policy anyway, and not an inherent flaw of authenticating in-browser).
As I said in the BB comments, the user has to check for A) presence of lock, B) correct domain spelling, C) absence of cert warnings. All three. XSS attacks fail two of those and only an elitist would assume that people can't learn to complete that simple ritual... what a shame virtually no one in IT makes any effort to explain it. But then there is copious proof that IT is currently dominated by combination of ineptitude and short-sighted greed that's resulted in so much of our sensitive details being spilled across the net (and they want to build us a new bridge).
It is possible that Cameron didn't provide such XSS examples because he knew they didn't really apply, especially after I'd already stated the proper steps for the browser authentication ritual. I also stated that implementation flaws were no justification either, which I'm sure he also accepted unless he believes that OpenID-related tools are a new breed of software without coding errors.
Here is another Cameron quote:
Burz, the lock symbol can be painted on your screen by a sufficiently cogent attacker. The certificate dialog can be faked - how would you know the difference? "Sufficiently cogent" how? Enough to run his code natively on my system, interfering with the browser's internals? Oh but surely the Cardspace code would be immune... LOL
This is not about who stores identity info. Its about who controls the dominant authentication mechanism.
How 'nice' that Firefox can have Cardspace plugins added to it... too bad most will consider the lack of native Cardspace support a nuisance at best. This is a primary benefit that MS gets by moving important 'rituals' like Web logins out of the browser and into the OS (where they don't belong).
Most of the technical material I found at Microsoft dealt with Cardspace using AD via Passport and seems to be the cardinal configuration the company uses to demonstrate and instruct WRT Cardspace deployment. I'm sure there are other examples, of course.
Yahoo! Stores identity information centrally... my money is on MS keeping that model after merger, and moving the central database to AD.
---> there are techniques through which the evil site can overwrite the address bar and the status bar, so you have no idea what is going on beneath the pixels....
---> there are all kinds of tricks that can be played with the URL. Even when it is intact, your DNS-to-ip mapping be distorted by an attacker. Client Side Java script can cause all kinds of nice visual effects I will leave to your imagination; cross-site scripting attacks mean even if you use a certificate and land at the right site, buried frames may continue to be able to do nefarious things under your identity, and so on. These are all attacks that are seen regularly. Your recipe would leave you totally vulnerable. That's when Cameron went from insinuating https is easily attackable to baldly stating it. But he can't point to studies or examples of these attacks because they don't exist, and IMO pointing to his "ID Laws" platitudes does nothing for the argument. The attacker has no interest in throwing up a deceptive IFRAME that looks like an actual SSL warning, because... you know... they don't want to alarm the user. His assumptions about what constitutes a potentially successful attack seem pretty specious. Re-drawing the address bar?? C'mon... I'm supposed to assume that A) the system already has malware on it to manipulate the browser, and B) that IE6 swiss cheese is a suitable security benchmark for proposing new authentication standards.
I don't have any problem with Cameron's ID Laws specifically, only that they are being used to sugarcoat a security implementation from an abusive monopolist which absolutely cannot be trusted to avoid exclusionary strategies.
Do NOT move web authentication into the monopoly product!
I'm not surprised a repair tech, when cornered with an unusually bad problem, will make noises implying the model in question is bad design... which is why you shouldn't take their word as sincere in that situation.
I do know that Apple had many more problems with easily-dented aluminum causing motherboard problems on 15" Powerbooks. This repair survey does show both of the 12" models as among the most reliable.
The new Windows implementation of Passport is now called CardSpace, which is built into Vista. This is a system that attempts to move web logins out of the web browser and into the OS, and uses Active Directory for authentication.
If Microsoft is able to pull something where its monopoly of desktop systems and growing web properties in MSN, Facebook and Yahoo! don't login smoothly with non-Microsoft systems then Active Directory could conceivably become necessary to operate a successful website... even a Unix or Linux site.
...which are somewhat more rugged than the aluminum Powerbooks, being built on a magnesium frame encased in carbonate. They also cost less. When I pressed some Apple store staff about iBook vs Powerbook durability, they said it was
I've taken my 1.2GHz model everywhere: plane trips, car trips, on the train over the past 4 years and nothing has gone wrong with it.
This is very informative. With the/dev/dsp IO blocking in place, I know not to bother with the Yet-Another-Boondoggle sound daemon. IO blocking for audio output = BROKEN.
System architects need to make a decision: Either fix OSS so it mixes instead of blocks by default, or strictly deprecate it and remove it from the system. It is better to have an app fail outright when you begin to use it, rather than intermittently sit mute when it should be playing alarms for important calendar appointments or incoming phone calls; Oh, but DO tell the user they were stupid to leave a Flash audio web page running in the background...
Oh wait... Do Linux distros even have system architects??
Numbers 2 & 3 would cause the browser's internal cert to mismatch the fake CA's private key. SSL is proof against this attack. Number 4, still can't fake the cert without the user explicitly accepting it.
Numbers 1 & 5 are not MITM at all. These are trojan/intrusion attacks at the source. If someone can place their code on your system, then you got a lot more to worry about than SSL transmissions.
My computer has for example four Verisign root certificates installed. Does that mean that Verisign (I only take them as an example) could technically install a box with a computer into the phone line 50 meters away from my house, and do a man-in-the-middle attack by creating genuine Verisign certificates... As it happens, Verisign is brazenly advertising "lawful intercept" services and you can find pages gushing about it right on their website.
So, yes, for a fee they will ab/use their position as Trusted Third Party and fake authorization of certificates to facilitate MITM attacks. But their M.O. is to subcontract to the telecoms/ISPs, so they would never need to do anything as messy as installing a box on your street.
I think that's dubious. Revolutionaries engage in mass murder either from following their beliefs, or despite them while following their leader. The history of communism in Russia and China appears to be the latter; you have to be a Stalinist or Maoist to be ideologically linked to genocide.
Go back 30 years earlier, and you have capitalists still doing the same with Native Americans. But capitalism isn't explicitly genocidal.
Contrast this with Nazism, which has an explicit agenda of dehumanizing/demonizing minority groups and inciting the in-group to violence.
1) The lock symbol. It should be on the address bar, preferably displayed whole without a line running through it. The presence of https: alone doesn't highlight the connection's overall level of trust/security.
2) The DOMAIN NAME. Most people, even most techies, forget this crucial part. The certificate/lock validates the domain name, and YOU must determine if that domain name is the one you really want to talk to. Ex: the site 'ebai.com' may have a perfectly valid certificate, even if you meant to go to 'ebay.com' instead... so you must check the spelling of WHO you are connected to. The certificate ensures that the domain hasn't been hijacked to a server that isn't registered for that domain name (i.e. what your address bar says you're accessing really is the right server).
Beyond that, it is (or ought to be) up to each user to decide whether they trust the outfit with which they are browsing.
Slashdot Mirror
(sigh)
Please read up on https/SSL/PKI technology used in web browsers. The SecurityNow podcast did a nice series introducing cryptography and the certification schemes it makes possible.
Cryptographically-signed certificates are verified by the browser and a trusted third party (the certificate authority) as a pre-condition for establishing the link. The encrypted nature of the link is almost beside the point: SSL certs guarantee that the site (somedomain.com) you think you are talking to is the real McCoy. That is why the lock is displayed on the address bar, because it signifies the validity of the domain name currently being accessed.
The certs cannot be faked without being detected by the browser. An attacker would have to somehow steal the private key of the site you're connecting to, or the CA's private key, in order to stage a MITM, arp cache or similar attack undetected.
The system assumes that you know beforehand what domain name(s) you want to connect to. It doesn't try to decide for you which sites are "good" or "bad", it simply ensures that the "bankofamerica.com" server you're connecting with is the one that was actually registered with the CA. Thus, you have to check domain spelling.
Make users choose between tyranny and indifference, and they'll probably just stay right where they already are.
Clearly even Paypal are not willing to tell people to simply check domain spelling and presence of lock symbol in the address bar. This state of affairs is very sad indeed.
If a person knows they should check domain spelling and the lock symbol in the address bar, and they are too lazy to do that... then I'd say they deserve whatever befalls them as a result.
The problem is that few techies are interested in teaching/reminding people about Https and how to use it: Most seem not to understand it, and so point people toward 'solutions' where someone else decides the 'good/bad' status of websites for them.
There was even a Slashdot story on a research paper showing image-factor security can be gamed by crooks.
Why not just check the address bar for domain spelling + the presence of the lock symbol? Https is the verification method that works.
User checks the address bar for A) the lock and B) the domain spelling. Absent any warning dialogs or malware infection or gross idiocy on the bank's end, the connection proof against phishing, DNS attacks etc. (But you cannot do just one or the other: You must check both at the same time!)
Sadly, despite its simplicity, most people don't know how to properly use https and this includes much of the 'techie' set. IMO this means that most people don't really know how to use a web browser.
As I mentioned elsewhere in comments, Firewire allows DMA to be turned off. And MS isn't giving you a way to turn it off.
It is known that Apple's openfirmware disables DMA (hence securing the machine) on its PPC systems when the password is enabled.
Neither OS vendor is actually talking (the Apple fix was discovered by happenstance) which seems to be the real problem here: the desire for secrecy.
OTOH, Linux allows you to turn off DMA, though it is enabled by default.
At this late date, it seems like mainly a Windows problem to me. MS may have provided a fix, but if so then they have told no one, nor has anyone discovered it yet.
Actually, no.
Adding a firmware password to my PPC Macs puts them into a heightened security mode that turns off Firewire DMA (and was tested specifically with the hack you referenced). I would expect the Intel units to have this feature also. And the new Linux firewire driver tackles the DMA vulnerability issue too.
What I've read on the subject so far indicates that most or all Firewire chipsets allow operation without DMA, and that it is possible to secure the DMA modes by programming the memory controller to restrict access to specific buffers
FWIW, Apple was similarly "cagey" (actually silent) on the issue, but at least gave us the ability to secure the port through openfirmware.
What I would worry about more are the DMA interfaces that no one is discussing re: security... PCMCIA/PCCard and other hot-swappable ports (PCI-X? eSATA?) that support bus mastering. I'm pretty sure that non-USB-implemented CF slots are a risk.
It isn't just about money. The uber-capitalist ideologues are involved now, saving face for their "way of life".
They used their DevNet developer database to locate a colleague at my place of work through whom they applied pressure at senior management level, i.e. vailed threats to withdraw discounts etc., in an attempt to prevent further criticism from me.
Fortunately, Microsoft's emails to management actually confirmed everything that I'd said was true. I still have copies with management's handwritten comments.
At least I'm not paranoid anymore - I know what they'll do with all that information.
The browser invariably knows when a portion of the page has been fetched from a third party. The lock is crossed-out, and that would have also come with a warning dialog (which I have personally experienced on several occasions).
The Netcraft article is sloppy reporting, as it omits mention of any warning dialogs. The author makes a common assumption that the user will actively continue with a compromised connection instead of canceling it... using that assumption, Cardspace can do no better unless it refuses to connect unconditionally (which is no more than a matter of default browser policy anyway, and not an inherent flaw of authenticating in-browser).
As I said in the BB comments, the user has to check for A) presence of lock, B) correct domain spelling, C) absence of cert warnings. All three. XSS attacks fail two of those and only an elitist would assume that people can't learn to complete that simple ritual... what a shame virtually no one in IT makes any effort to explain it. But then there is copious proof that IT is currently dominated by combination of ineptitude and short-sighted greed that's resulted in so much of our sensitive details being spilled across the net (and they want to build us a new bridge).
It is possible that Cameron didn't provide such XSS examples because he knew they didn't really apply, especially after I'd already stated the proper steps for the browser authentication ritual. I also stated that implementation flaws were no justification either, which I'm sure he also accepted unless he believes that OpenID-related tools are a new breed of software without coding errors.
Here is another Cameron quote: Burz, the lock symbol can be painted on your screen by a sufficiently cogent attacker. The certificate dialog can be faked - how would you know the difference? "Sufficiently cogent" how? Enough to run his code natively on my system, interfering with the browser's internals? Oh but surely the Cardspace code would be immune... LOL
How 'nice' that Firefox can have Cardspace plugins added to it... too bad most will consider the lack of native Cardspace support a nuisance at best. This is a primary benefit that MS gets by moving important 'rituals' like Web logins out of the browser and into the OS (where they don't belong).
Most of the technical material I found at Microsoft dealt with Cardspace using AD via Passport and seems to be the cardinal configuration the company uses to demonstrate and instruct WRT Cardspace deployment. I'm sure there are other examples, of course.
Yahoo! Stores identity information centrally... my money is on MS keeping that model after merger, and moving the central database to AD. ---> there are techniques through which the evil site can overwrite the address bar and the status bar, so you have no idea what is going on beneath the pixels.
---> there are all kinds of tricks that can be played with the URL. Even when it is intact, your DNS-to-ip mapping be distorted by an attacker. Client Side Java script can cause all kinds of nice visual effects I will leave to your imagination; cross-site scripting attacks mean even if you use a certificate and land at the right site, buried frames may continue to be able to do nefarious things under your identity, and so on. These are all attacks that are seen regularly. Your recipe would leave you totally vulnerable. That's when Cameron went from insinuating https is easily attackable to baldly stating it. But he can't point to studies or examples of these attacks because they don't exist, and IMO pointing to his "ID Laws" platitudes does nothing for the argument. The attacker has no interest in throwing up a deceptive IFRAME that looks like an actual SSL warning, because... you know... they don't want to alarm the user. His assumptions about what constitutes a potentially successful attack seem pretty specious. Re-drawing the address bar?? C'mon... I'm supposed to assume that A) the system already has malware on it to manipulate the browser, and B) that IE6 swiss cheese is a suitable security benchmark for proposing new authentication standards.
I don't have any problem with Cameron's ID Laws specifically, only that they are being used to sugarcoat a security implementation from an abusive monopolist which absolutely cannot be trusted to avoid exclusionary strategies.
Do NOT move web authentication into the monopoly product!
I'm not surprised a repair tech, when cornered with an unusually bad problem, will make noises implying the model in question is bad design... which is why you shouldn't take their word as sincere in that situation.
I do know that Apple had many more problems with easily-dented aluminum causing motherboard problems on 15" Powerbooks. This repair survey does show both of the 12" models as among the most reliable.
The new Windows implementation of Passport is now called CardSpace, which is built into Vista. This is a system that attempts to move web logins out of the web browser and into the OS, and uses Active Directory for authentication.
If Microsoft is able to pull something where its monopoly of desktop systems and growing web properties in MSN, Facebook and Yahoo! don't login smoothly with non-Microsoft systems then Active Directory could conceivably become necessary to operate a successful website... even a Unix or Linux site.
One of Microsoft's system architects, Kim Cameron, is spreading erroneous and misleading FUD (see comment #7).
...which are somewhat more rugged than the aluminum Powerbooks, being built on a magnesium frame encased in carbonate. They also cost less. When I pressed some Apple store staff about iBook vs Powerbook durability, they said it was
I've taken my 1.2GHz model everywhere: plane trips, car trips, on the train over the past 4 years and nothing has gone wrong with it.
Then don't cry when your suburban sprawl dessicates into dust and you find you're not welcome in the green places.
Funny thing... when I lived in Colorado there were Texans migrating in droves. I understand they are not so welcome there now.
This is very informative. With the /dev/dsp IO blocking in place, I know not to bother with the Yet-Another-Boondoggle sound daemon. IO blocking for audio output = BROKEN.
System architects need to make a decision: Either fix OSS so it mixes instead of blocks by default, or strictly deprecate it and remove it from the system. It is better to have an app fail outright when you begin to use it, rather than intermittently sit mute when it should be playing alarms for important calendar appointments or incoming phone calls; Oh, but DO tell the user they were stupid to leave a Flash audio web page running in the background...
Oh wait... Do Linux distros even have system architects??
Distributed computing search for NEOs is ramping up:
http://orbit.psi.edu/
Numbers 2 & 3 would cause the browser's internal cert to mismatch the fake CA's private key. SSL is proof against this attack. Number 4, still can't fake the cert without the user explicitly accepting it.
Numbers 1 & 5 are not MITM at all. These are trojan/intrusion attacks at the source. If someone can place their code on your system, then you got a lot more to worry about than SSL transmissions.
So, yes, for a fee they will ab/use their position as Trusted Third Party and fake authorization of certificates to facilitate MITM attacks. But their M.O. is to subcontract to the telecoms/ISPs, so they would never need to do anything as messy as installing a box on your street.
I think that's dubious. Revolutionaries engage in mass murder either from following their beliefs, or despite them while following their leader. The history of communism in Russia and China appears to be the latter; you have to be a Stalinist or Maoist to be ideologically linked to genocide.
Go back 30 years earlier, and you have capitalists still doing the same with Native Americans. But capitalism isn't explicitly genocidal.
Contrast this with Nazism, which has an explicit agenda of dehumanizing/demonizing minority groups and inciting the in-group to violence.
The baby boomers gave us the Weathermen and Symbianese Army terrorist groups. Excluding them for 'practical' reasons doesn't make sense.
More than that, look for:
1) The lock symbol. It should be on the address bar, preferably displayed whole without a line running through it. The presence of https: alone doesn't highlight the connection's overall level of trust/security.
2) The DOMAIN NAME. Most people, even most techies, forget this crucial part. The certificate/lock validates the domain name, and YOU must determine if that domain name is the one you really want to talk to. Ex: the site 'ebai.com' may have a perfectly valid certificate, even if you meant to go to 'ebay.com' instead... so you must check the spelling of WHO you are connected to. The certificate ensures that the domain hasn't been hijacked to a server that isn't registered for that domain name (i.e. what your address bar says you're accessing really is the right server).
Beyond that, it is (or ought to be) up to each user to decide whether they trust the outfit with which they are browsing.