>People die in car wrecks way more than from chicken poisoning or terrorism or whatever
A lot of people make that mistake when calculating the risk from terrorists. You can't just compare the number of auto deaths in the past to the number of terrorist deaths in the past. To get a useful estimate of the risk you have to factor in how many terrorist deaths there might be in the future. You have to speculate about the future, so of course your estimate is unreliable. But if you don't factor in significant future possibilities then your estimate is nearly worthless. You have to factor in the probability of nukes and the expected number of casualties, to figure out how likely you are to get killed by terrorists. And yes, nukes are a real danger if you live in a big city, though maybe not a huge danger.
>When the browsers provide support for seamless SVG that gets push data from a socket connection I'll stop using Flash.
There are some applications that would be so much better with SVG that even I might recommend Flash for the purpose. But please don't use Flash just because it would make your site a little cooler when it would be fine without it. For example my doctor's home page uses flash and won't even load at all without it. There's not even a link to get to a static page. Of course that's exceptionally lousy web design, but what does my doctor's home page really need Flash for anyway? Most of a doctor's site would be just fine with old fashioned html.
>When browsers provide seamless client side data validation and inline error prompting for forms, I'll stop using Javascript.
Client side data validation is nice but not really necessary. Maybe a simple and secure form of validation is something that should be put into browsers.
>Any web page that can't benefit from the above uses of the technology probably isn't all that more informative than an email would be.
>Static information is useful but stateless information is becoming useless. This is interactive media... not a book that you can access over a phone line.
Slashdot works just fine with JavaScript turned off. I'd rate Slashdot a little higher than useless. A lot of sites I buy stuff from work fine without JavaScript. On the other hand, the value of some features used by some sites, like Google Maps, justifies their use of JavaScript.
No, I don't think JavaScript is secure. It's not because of a flaw in the language specification or in the security model or something like that. It's the very idea of JavaScript. A programming language executed in a web browser is dangerous. It wouldn't matter if it was PythonScript or VBScript or LispScript or FlashScript, it would be a bad idea because it would be practically impossible to implement securely.
Maybe they only take money from people they know are from major companies, because if they took money from anyone who asked, they would be quickly exposed.
Yeah!! DOWN with teh flash and javascript! Time to move on to something better. Silverlight, here I come!!!11!one:D.
OK Crazy Taco, to even suggest something like Silverlight, proves that the excess hot sauce has gotten to your brain. We're your friends and we're here to help. Slowly step away from the keyboard.
>You're worrying about things that have never happened. People have been worrying about the bomb for 60 years, but the smart money has been on no bomb.
When you're speculating on real estate, you have to do just that, speculate. Things are changing. The Soviets were atheists and thus were deterred by mutually assured destruction. On the other hand, the terrorists are suicidal. Russian security is much weaker than it used to be, and nukes are proliferating to more countries. I think terrorists probably won't be able to set off a nuke, but a smart investor should consider it a significant concern instead of just saying "don't worry about it".
We've prevented a nuclear disaster so far, but as the saying goes - Past performance is not a guarantee of future results.
They said they could make javascript secure but it's still a huge source of holes. Instead of learning our lesson, Flash, another executable web format is taking over. Don't use flash because it's cool. Only use it if you really need it for your web page.
And if Ubuntu was really concerned about security they would ship it by default with a web browser already set up under a separate username with strict selinux policies.
You might want to be careful about that. Some people say it's just a matter of time before a nuke gets set off in a large city. After that people might have a strong preference for staying away from population centers. Also, if the economies of poor counties get better birthrates may drop. With stagnant or decreasing population, real estate might be a bad investment.
I doubt that the lack of expiration date on the vouchers Microsoft distributed will make it subject to GPLv3. It's kind of like if you sign up for a free email account and part of the terms are that the terms may change without notice. If the changes are limited and reasonable, a court might hold you to the changes. But if they change the terms without notice to say that you must give them your house if you send one more free email, then the court almost certainly won't enforce that.
Likewise if Microsoft left itself open to changes in the terms of the GPL then the changes probably can't radically alter the terms of the contract. If the changes to the contract can get Microsoft's patents, then why couldn't it be changed to take all of Microsoft's intellectual property, or even just ALL of Microsoft's property?
>if we have an application whose purpose is to read and edit MS Word documents, and a patent says we are not allowed to do that, then that application is kaput.
Good point. Maybe it would turn out good for us though. I've often wanted to tell people like professors that it's only fair to put documents in formats like ODF that everyone can view without having to buy expensive software. But since OpenOffice and others read Microsoft Word format, that argument is weak. If OpenOffice couldn't read Word format, it would add extra support to the push for governments to switch to ODF.
I suppose her defense will be that someone stole her photo and created a fake ID without her permission
Yeah, and then the evil someone gave it back to her without her permission, and she involuntarily used it to try to blag beer in a NY bar. Good luck with empanneling a jury to buy that one.
She would probably have to claim it wasn't her in the bar. Like maybe the bartender had a fake ID made to frame her, or a girl that looked like her used her picture or something. Yea, it's a long shot, but what else could she have been thinking when she sent the DMCA notice? I suppose the best explanation is that she just wasn't thinking.
Oops, I was under the impression that it used the entire 2.4GHz band simultaneously to achieve the increased bandwidth. But Wikipedia confirms I was mistaken.
The beauty of 802.11b is that the power is low enough that the spectrum can be used by many people at once. If you need long range you can use a high gain antenna. If you use an omnidirectional antenna, your signal wont go far enough to screw up too many other people. Also don't make the 802.11g mistake and make the whole spectrum one big channel so that just one user can screw it up for everyone. Also don't let the channels overlap like they do with 802.11b so that one user can ruin two of the three available bands.
As noted by the parent post, a lot of comments below assume she is claiming authorship of the fake ID. She's not. She's only claiming authorship of the photo and signature. I suppose her defense will be that someone stole her photo and created a fake ID without her permission. I'm not sure that story will be sufficient to create a reasonable doubt in the minds of the jury if she gets charged with forgery.
do you go to the trouble of reading the security certificate of a page every single time you log on to it and verifying that the issuing authority is someone you trust?
All you have to do is look at the domain name and verify that the page is httpS to you know who you are connecting to. I'm not sure who you mean by issuing authority but if you mean the certificate authority, there is a list of trusted certificate authority public keys installed with your web browser that are used to automatically verify the bank's public key matches the domain name.
if you assume a man in the middle and a careless end user, there is nothing you can do.
That's true. The user has to check that the page is secure and that the domain is correct. But shouldn't banks at least offer that option instead of redirecting to insecure pages?
There are even people that only ever use read-only "Live CDs"
That would probably be a good idea. If you do that, one thing to watch out for is that many live CDs aren't updated very often. They may have major vulnerabilities for months after the patches have been released. An alternative might be just a kernel on a boot CD with an intrusion detection system to scan your hard drive to make sure your operating system isn't compromised.
Imagine I "root" Bob's computer and redirect it to my evil website everytime he tries to go to www.somebank.com.... What's the name of such an attack?
I don't know what you would call such an attack, but it wouldn't be a MITM because it would be the entire endpoint that had been compromised, not the middle.
For years I've been leaving the password empty and hitting return so I can get a full SSL page.
That's probably ok, but it's probably best to use a bogus username as well. No sense in giving even that to them. In fact on my accounts I use odd usernames. I had an account once where my username was just firstnamelastname. It got hacked. When I discovered the breach and called to report it, I found out that my bank would reset the password and email address for the account over the phone after the caller authenticated with only my birthdate and last four digits of my social security number. OUCH!
Strangely the crooks didn't take anything though. I think because there was so little to take that they thought I would notice too quickly. Maybe they wanted to maintain a low profile till they exploited juicier targets.
It probably doesn't make much difference if they allow logins from insecure pages because if the user doesn't know enough to check for the padlock and the domain name, then the secure page wouldn't do any good anyway. The problem is when they don't even offer a tiny little link to a secure page for those customers who do know the difference. Worse is when a user manually changes the URL to httpS and they redirect to the insecure page! At the very least they could tell users about the bad username/password trick instead of expecting people to figure it out on their own or hear it somewhere else.
Those banking web sites are awful also because they require JavaScript to be enabled. They force me to open up my browser to all JavaScript-based attacks.
Yea, I hate that too. A decent partial solution is the NoScript extension for Firefox. It will allow you to quickly and easily enable JavaScript for only the sites you want. Then at least you only have to trust that your own bank wont hack you. Of course for the unsecured pages airpwn could still be used to inject JavaScript.
How about all the sites that require Flash. Just what we need, an even bigger vulnerability than the already bad JavaScript. JavaScript was supposed to be secure and turned out not to be. Are we supposed to believe that Flash, which has even more features, will be secure? Did we not learn our lesson the hard way the first time? Does anyone else think it's crazy to let any website you visit, run programs on your computer, even if they're supposedly sandboxed? Didn't we learn the first time that the sandboxes don't work?
But it's not just Flash and JavaScript. Even Ubuntu, which likes to claim good security, comes configured to launch a movie player in your browser when you visit a site with video. Now you are exposed to vulnerabilities in you video player too. Pdf viewers are sometimes configured to launch automatically also. But pdf viewers are complex and have had vulnerabilities as well. The list goes on.
Web browsers are the biggest vulnerability for most systems. They should be configured by default to only allow a restricted subset of html to be rendered. Web designers should be strongly discouraged from implementing fancy stuff unless it's really valuable.
In addition, operating systems should include a chrooted copy of the web browser, separated from the users account and overwritten at every reboot, so that if they are compromised, the users home account won't be.
No duh, you can't spoof a cert. But show us what field in the cert includes the ip address for the fqdn listed the cn field? It doesn't exist! Again, how do you ensure the ip address the dns server resolved for www.citibank.com is really the ip address CitiBank.
It doesn't matter what the IP address is. Once your bank gets one certificate authority to sign their mybank.com public key, no other trusted certificate authority will sign another public key for the domain mybank.com. If the crook makes his own public key for mybank.com, he won't be able to get it signed, so your browser will object that it hasn't been signed by a trusted certificate authority. Since the crook doesn't have access to your bank's genuine private key, your browser will report that the computer on the other end, whatever its IP address is, cannot be verified.
But you have to verify yourself that you're connecting to the correct domain name. A crook might be able to get a trusted certificate authority to sign a key for a domain like mybanklogin.com even though they won't for mybank.com see my post above for more about verifying you've got the correct domain name.
An easy remedy for when a secure page isn't available is to enter a bad username and password which usually brings up a secure page telling you to try again
If I was going to create a phishing website, not only would I have the fake frontend, but I'd simulate the login failed behavior of the website as well. That way I'd get not only the login information the user believes is valid for the faked website, but I'd also harvest multiple login/password combinations from that user. So entering a fake username/password to get the "secure" login page isn't exactly the best advice.
After you enter the fake username and password you check that the page that comes up is httpS and that the domain name is correct. The whole idea of SSL (Secure Socket Layer) is that the crooks can't fake that. Of course there are some tricks you've got to watch out for. See my post above for how to verify the domain name.
A true MITM requires you to funnel all relevant traffic through your server.
Maybe for a "true" MITM attack. But airpwn can do a sort of partial MITM attack. When your browser sends off a request for your bank's web page over the wireless, airpwn quickly sends back a response to your computer before the real server does (because airpwn is closer and can respond quicker). As soon as your browser gets the page back, it closes the port and ignores the real bank server. When you submit the password from the fake page you're looking at, it goes out to the crook. After the crook has your password he needn't continue to be the man in the middle.
And the crook doesn't have to be sitting in the coffee shop all day waiting for someone to log on to their bank. The crook can be blocks, or even miles away with a long range antenna, collecting passwords from a busy hotspot for days or months.
Thus the problem with SSL, anyone can insert themselves and spoof as an endpoint. If I spoof as VeriSign and man in the middle attack you with the bank, there is no good way to protect against this.
Your web browser comes with a collection of public keys from registrars including Verisign. But your browser can't include every public key for every secure website. It would be too big a download and it would be hard to update. So the bank gets Verisign to put Verisign's digital signature on the bank's public key. When you connect to your bank, your bank sends you its public key and your web browser uses its copy of Verisign's public key, to verify Verisign's signature on the bank's key, thereby confirming that you have your bank's genuine public key. Because of the way public key cryptography works, nobody can forge Verisign's signature, and once you have your bank's public key, nobody can impersonate your bank.
One of the big problems with this system is that Verisign will put its signature on the public keys of criminals too. So for example a crook could maybe buy the domain bankofamericacardsite.com and ask Verisign to put a signature on the public key for that site. If Verisign isn't watching, and sometimes registrars process these things automatically, then the crook can get a genuine certificate that won't raise any red flags in your browser. So when you connect to Bank of America, you not only have to look for the s in httpS, you also have to make sure the domain is one owned by BofA, like bankofamerica.com and not bankofamericasneakylittlechange.com. There are a lot of little misspellings and minor variations of bank names, so you have to look for the exactly most common spelling of the organization's name in the domain name. If you're lucky your bank will own the common typos and variations of its name, but maybe it won't.
Unfortunately the banks don't make it easy for you. Some banks will use domains like accountaccess.com. How are you supposed to tell by looking that accountaccess.com is owned by your bank and not by some crook. You can't. (in fact accountaccess.com is owned by spammers, don't go there)
Another problem is that people don't know how to pick the domain name out of the URL. I'm not sure if this is a good enough way to describe it, but if you see a URL like
the domain name is the word and the.com right before the third slash. In this case chasecriminal.com. Notice the fake https://chasebank.com/ at the end. The stuff over on the right hand side of the URL is just stuff that is internal to the computer that you are connecting to. A criminal can put nearly anything over there.
By the way, Chase seems to be one of the banks that doesn't allow secure logins. Even if you manually change http://chase.com/ to https://chase.com/ it automatically redirects you to the insecure page. It boggles the mind.
Also note that this doesn't just apply to banks. Any site where you enter a password or secure information ought not to use an insecure page for login. And don't forget that Slashdot doesn't use any encryption at all on its logins. Don't use the same password for your bank as you do for Slashdot
Watch for the s in https at the beginning. And don't login to sites with domains like paypalsecurity.com or chaseusers.com or anything but the most obvious domain name.
Slashdot Mirror
A lot of people make that mistake when calculating the risk from terrorists. You can't just compare the number of auto deaths in the past to the number of terrorist deaths in the past. To get a useful estimate of the risk you have to factor in how many terrorist deaths there might be in the future. You have to speculate about the future, so of course your estimate is unreliable. But if you don't factor in significant future possibilities then your estimate is nearly worthless. You have to factor in the probability of nukes and the expected number of casualties, to figure out how likely you are to get killed by terrorists. And yes, nukes are a real danger if you live in a big city, though maybe not a huge danger.
There are some applications that would be so much better with SVG that even I might recommend Flash for the purpose. But please don't use Flash just because it would make your site a little cooler when it would be fine without it. For example my doctor's home page uses flash and won't even load at all without it. There's not even a link to get to a static page. Of course that's exceptionally lousy web design, but what does my doctor's home page really need Flash for anyway? Most of a doctor's site would be just fine with old fashioned html.
>When browsers provide seamless client side data validation and inline error prompting for forms, I'll stop using Javascript.
Client side data validation is nice but not really necessary. Maybe a simple and secure form of validation is something that should be put into browsers.
>Any web page that can't benefit from the above uses of the technology probably isn't all that more informative than an email would be.
>Static information is useful but stateless information is becoming useless. This is interactive media... not a book that you can access over a phone line.
Slashdot works just fine with JavaScript turned off. I'd rate Slashdot a little higher than useless. A lot of sites I buy stuff from work fine without JavaScript. On the other hand, the value of some features used by some sites, like Google Maps, justifies their use of JavaScript.
No, I don't think JavaScript is secure. It's not because of a flaw in the language specification or in the security model or something like that. It's the very idea of JavaScript. A programming language executed in a web browser is dangerous. It wouldn't matter if it was PythonScript or VBScript or LispScript or FlashScript, it would be a bad idea because it would be practically impossible to implement securely.
Maybe they only take money from people they know are from major companies, because if they took money from anyone who asked, they would be quickly exposed.
When you're speculating on real estate, you have to do just that, speculate. Things are changing. The Soviets were atheists and thus were deterred by mutually assured destruction. On the other hand, the terrorists are suicidal. Russian security is much weaker than it used to be, and nukes are proliferating to more countries. I think terrorists probably won't be able to set off a nuke, but a smart investor should consider it a significant concern instead of just saying "don't worry about it".
We've prevented a nuclear disaster so far, but as the saying goes - Past performance is not a guarantee of future results.
And if Ubuntu was really concerned about security they would ship it by default with a web browser already set up under a separate username with strict selinux policies.
You might want to be careful about that. Some people say it's just a matter of time before a nuke gets set off in a large city. After that people might have a strong preference for staying away from population centers. Also, if the economies of poor counties get better birthrates may drop. With stagnant or decreasing population, real estate might be a bad investment.
Likewise if Microsoft left itself open to changes in the terms of the GPL then the changes probably can't radically alter the terms of the contract. If the changes to the contract can get Microsoft's patents, then why couldn't it be changed to take all of Microsoft's intellectual property, or even just ALL of Microsoft's property?
Good point. Maybe it would turn out good for us though. I've often wanted to tell people like professors that it's only fair to put documents in formats like ODF that everyone can view without having to buy expensive software. But since OpenOffice and others read Microsoft Word format, that argument is weak. If OpenOffice couldn't read Word format, it would add extra support to the push for governments to switch to ODF.
The beauty of 802.11b is that the power is low enough that the spectrum can be used by many people at once. If you need long range you can use a high gain antenna. If you use an omnidirectional antenna, your signal wont go far enough to screw up too many other people. Also don't make the 802.11g mistake and make the whole spectrum one big channel so that just one user can screw it up for everyone. Also don't let the channels overlap like they do with 802.11b so that one user can ruin two of the three available bands.
As noted by the parent post, a lot of comments below assume she is claiming authorship of the fake ID. She's not. She's only claiming authorship of the photo and signature. I suppose her defense will be that someone stole her photo and created a fake ID without her permission. I'm not sure that story will be sufficient to create a reasonable doubt in the minds of the jury if she gets charged with forgery.
Strangely the crooks didn't take anything though. I think because there was so little to take that they thought I would notice too quickly. Maybe they wanted to maintain a low profile till they exploited juicier targets.
It probably doesn't make much difference if they allow logins from insecure pages because if the user doesn't know enough to check for the padlock and the domain name, then the secure page wouldn't do any good anyway. The problem is when they don't even offer a tiny little link to a secure page for those customers who do know the difference. Worse is when a user manually changes the URL to httpS and they redirect to the insecure page! At the very least they could tell users about the bad username/password trick instead of expecting people to figure it out on their own or hear it somewhere else.
How about all the sites that require Flash. Just what we need, an even bigger vulnerability than the already bad JavaScript. JavaScript was supposed to be secure and turned out not to be. Are we supposed to believe that Flash, which has even more features, will be secure? Did we not learn our lesson the hard way the first time? Does anyone else think it's crazy to let any website you visit, run programs on your computer, even if they're supposedly sandboxed? Didn't we learn the first time that the sandboxes don't work?
But it's not just Flash and JavaScript. Even Ubuntu, which likes to claim good security, comes configured to launch a movie player in your browser when you visit a site with video. Now you are exposed to vulnerabilities in you video player too. Pdf viewers are sometimes configured to launch automatically also. But pdf viewers are complex and have had vulnerabilities as well. The list goes on.
Web browsers are the biggest vulnerability for most systems. They should be configured by default to only allow a restricted subset of html to be rendered. Web designers should be strongly discouraged from implementing fancy stuff unless it's really valuable.
In addition, operating systems should include a chrooted copy of the web browser, separated from the users account and overwritten at every reboot, so that if they are compromised, the users home account won't be.
But you have to verify yourself that you're connecting to the correct domain name. A crook might be able to get a trusted certificate authority to sign a key for a domain like mybanklogin.com even though they won't for mybank.com see my post above for more about verifying you've got the correct domain name.
And the crook doesn't have to be sitting in the coffee shop all day waiting for someone to log on to their bank. The crook can be blocks, or even miles away with a long range antenna, collecting passwords from a busy hotspot for days or months.
One of the big problems with this system is that Verisign will put its signature on the public keys of criminals too. So for example a crook could maybe buy the domain bankofamericacardsite.com and ask Verisign to put a signature on the public key for that site. If Verisign isn't watching, and sometimes registrars process these things automatically, then the crook can get a genuine certificate that won't raise any red flags in your browser. So when you connect to Bank of America, you not only have to look for the s in httpS, you also have to make sure the domain is one owned by BofA, like bankofamerica.com and not bankofamericasneakylittlechange.com. There are a lot of little misspellings and minor variations of bank names, so you have to look for the exactly most common spelling of the organization's name in the domain name. If you're lucky your bank will own the common typos and variations of its name, but maybe it won't.
Unfortunately the banks don't make it easy for you. Some banks will use domains like accountaccess.com. How are you supposed to tell by looking that accountaccess.com is owned by your bank and not by some crook. You can't. (in fact accountaccess.com is owned by spammers, don't go there)
Another problem is that people don't know how to pick the domain name out of the URL. I'm not sure if this is a good enough way to describe it, but if you see a URL like
http://www.chasecriminal.com/ccpmapp/commercial/ho me/https://chasebank.com
the domain name is the word and the .com right before the third slash. In this case chasecriminal.com. Notice the fake https://chasebank.com/ at the end. The stuff over on the right hand side of the URL is just stuff that is internal to the computer that you are connecting to. A criminal can put nearly anything over there.
By the way, Chase seems to be one of the banks that doesn't allow secure logins. Even if you manually change http://chase.com/ to https://chase.com/ it automatically redirects you to the insecure page. It boggles the mind.
Also note that this doesn't just apply to banks. Any site where you enter a password or secure information ought not to use an insecure page for login. And don't forget that Slashdot doesn't use any encryption at all on its logins. Don't use the same password for your bank as you do for Slashdot
Watch for the s in https at the beginning. And don't login to sites with domains like paypalsecurity.com or chaseusers.com or anything but the most obvious domain name.