The unfortunate reality is that the largest vulnerability is, and will be, the human element. They want their login to be "easy" - so anyone who gets physical access to the machine gets root access with no password credentials, or they use a trivially-cracked password. They want to "simplify" their security arrangements. They trust an email sent by their friends (or sometimes even spoofed to look like it came from themselves) or "system administrator at your domain."
End result? More vulnerabilities.
Unfortunately, the "solution" involves either telling a lot of crybabies "no, you can't have it this way" or else changing human nature. And it's not in human nature to stand up to the crybabies (actually, an actual corporation never would - it's "bad customer relations.")
No, the solution is to make systems secure by default and ensure that the easy ways to do things are also the secure ways. Note that although I use Linux for specific examples of some good security practices, it is not necessarily secure for the casual user.
Why is remote login allowed by default? The Linux distros I have dealt with do not even have SSH servers in the default install. Most users are not going to use remote access at all. They should have to do something extra to enable it. Or maybe just something extra to get it to work with routable IPs because most people may want file/printer sharing on their 192.168.x.x local LAN.
Why are blank passwords allowed by default? No password for local login to a non-admin account on a single-user or family machine does not seem like a big deal. On the other hand, blank passwords should not be allowed for remote access (SSH has an option for this; other replies point out that Windows XP prevents remote blank password login as well). Simple passwords are a different problem, but a simple solution may be biometric login via a fingerprint scanner like Thinkpads support. Fast and easy without the trouble of remembering a password.
The e-mail problem is probably the most serious problem and the hardest one to fix. It does not really depend significantly on operating system other than the fact that it is easier to implement with a monoculture. If the exploit is offered via a link from the e-mail then it could just show the page/download appropriate for your OS like mozilla.com does.
Some solutions include better spam blocking. If those messages get blocked as spam, then the user never has a chance to react insecurely to them. This is likely incomplete and difficult to implement for all users, as spam blocker quality seems to vary widely and spam is continually improving. Some sort of trivial signature system could help. I believe there are services that will give you an S/MIME certificate for free based on proving that you can receive e-mail at a specific address. An e-mail client could probably automatically request such a certificate. Also, webmail providers could sign S/MIME certificates for their users automatically. That combined with throwing out unsigned e-mails from a sender whose public ke you know (as it was used in a previous e-mail) could make forging e-mail from addresses a bit more difficult.
A more direct solution may involve limiting the rights of software so if a user gets tricked into installing a program, it cannot do much damage. AppArmor and SELinux are extensions to Linux allowing for rights limiting of applications in addition to the more traditional chroot'ing and running as a limited user. Only software from the trusted repositories could get full rights -- preventing the user from getting tricked into adding a repository to the trusted list while making installs of 3rd party software feasible poses a further difficulty.
I do not offer solutions, only partial ideas. The general direction is that blaming users for using software insecurely will not get you anywhere. The software has to be designed so it is either secure or broken -- which was the idea behind the new Firefox 3 display for expi
And, by the way, this optimizing is also why there is "IE32" and "ARM" specific code in Chrome. There has to be. That's integral to how hotpath-type techniques work.
Soon to get modded down as offtopic or troll, but why exactly is it that CS students think they're the smartest? What is it about knowing how to use a computer that makes for elitism? It's not like many CS students go on to cancer research with their computer skills. A few yes, but most of those were double majors in biology or were biology students taking a few computer classes.
I suspect it is a mix of its visibility and the type of mind that is good at computer science.
With the rise of the internet computers and people who have been successful with them have been very visible to the general population. The pervasive idea that no one except for a small minority has any idea how computers work while nearly everyone uses them may make those who are skilled with them feel elite and/or special.
Also, in relation to the theory of multiple intelligences, often people talking about intelligence only mean the Logical-Mathematical category, which is the one most closely related to computer science. Looking at that list, you may notice that several of those categories of intelligence are areas that computer geeks are stereotypically bad at.
Computer science is a field of mathematics which lays the basis for computers and algorithms. It is older than computers themselves. The actual applications tend to involve using a computer, but there is a lot of theory to learn and work with without actually touching one.
You mean like this? (Thanks to Dan Kaminsky's blog for the reference. I highly recommend reading his summary of SIGGRAPH; there's a lot of cool stuff there.)
Suddenly, it's "padlock USUALLY means OK, but you do need to check the URL and you should really also check the contents of the cert". It's far better to be clear and unambiguous about it, not in the least because if someone does get bitten, it can also affect you and me (botnets, more spam, more viruses etc).
The people arguing for self-signed SSL to have a usable UI in these comments are usually clear about what they mean by that: they do not mean they want it to look just like CA signed SSL. It should either look like plain HTTP or possibly be displayed as different but clearly less secure than CA signed SSL. Perhaps a broken padlock icon would work, maybe along with a red or orange highlight on the URL bar/favicon instead of the secure SSL yellow/blue/green.
Oh no, how do I know I am talking to the real Slashdot and not a fake one served by a man-in-the-middle attacker? Oh yeah, I don't. On the other hand, since I am sending my login cookie over an unencrypted link, a man-in-the-middle could simply sniff the cookie and hijack my login session, which is a lot easier than intercepting self-signed SSL, using a different certificate, and hoping I have not seen the real certificate before.
On the other hand, ignore this post, that sounds like an awesome excuse to disown any posts I later decide I dislike.;)
Anyway, the GP says in the text you quoted that the encryption is to make sniffing more difficult, and he couldn't care less whom he is actually communicating with - if he did, he would use a trusted channel like talking face-to-face.
Except the problem seems to be flipped: with UAC, people seem to ignore the warning and always allow; with Firefox 3's self-signed certificates, people seem to ignore the warning and always deny. Both are signs of a bad UI.
You are correct that we should be wary of being too trusting, but currently all you need to drain most people's bank accounts is their password and some security question answers. Unlike a private key, these can be guessed or acquired through phishing or DNS poisoning or other attacks. Also, they are likely to be the same across multiple sites, so a security breach at one could cause trouble for users at another. The major problems with public keys are that (1) the software in not in place to use them and (2) passwords are portable, so you can use them from any computer.
For important things, we should be using Two-factor authentication, especially with things like keyfobs which show time-based passwords and fit on a keychain so they are not tied to one computer and are safe from malware - except, of course, if you have malware active when you access your bank website, it can simply hijack your session and do whatever it wants.
Past that, for really important things, people need to be aware that any computer security system (in fact, probably any security system) is going to be imperfect, and assumptions that a security system is perfect will lead to trouble. But that is not a good reason to avoid using good security as opposed to poor or no security.
If users were able to add self signed certs to a trusted list, then subsequent mitm attacks would be thwarted.
The current implementation involves a trusted list, which is a good idea: on a couple projects I have worked on self-signed HTTPS (verified via phone) has been used for version control and project information.
One should also consider the even simpler layer of security of SSH-style certificate checks: warn if the certificate is new or different from the previous one.
If you're accepting self-signed certificates, there's no way for you to easily differentiate my false certificate from the site's real one.
Self-signed certificates are dangerous because they give the user the impression that they have gained some security when they have not.
Erm, then just change the UI for self-signed certificates. Do not make them look secure. Either make them look like plain HTTP or have and orange or red color warning the user that the connection is unsecured. If they care about the security of the link, then they will check for the blue/green/yellow. Also, there should be a warning if the cert is at all different from the previous time viewing the page, perhaps only if the new cert is untrusted (self-signed) or only if the old cert is not expired.
USB monitors exist. Here is a review of one. As mentioned in the review, the problem is that there are not any USB graphics cards, so the graphics are not hardware accelerated. They get around the bandwidth problem by using "DisplayLink" compression.
Even if we assume everyone continues to use the same password, with the same account, everywhere, it's still better than a conventional login. With the conventional login, every site I log into could steal my password and use it to login as me elsewhere. With OpenID, only my OpenID provider can do that.
Well that is true with most current systems, it is not an intrinsic problem with password authentication. digest access authentication is an example of a password-based authentication method where the server does not need to know the password. It does not involve a salt other than the HTTP realm, but that could be changed. With such a system, you could use the same password on several different web sites and only ever give them hashed versions with different salts. Then the problem of knowing your password would not exist. Of course, such systems are unlikely be used in part because they would be more complicated to setup and because it would be nearly impossible for the user to tell the difference.
That said, I think the other advantages of OpenID that you give are important.
While it is true that Limewire, etc. are popularized, there are two major points to consider here:
A lot of people I know will refuse to use p2p or accept pirated copies of movies, etc. on moral grounds. This may be a fluke, but it does seem rather common to have a sizable DVD collection.
Most people I have encountered do not have a firm grasp on what copyright law covers. I think part of it is that the web has a ton of free-as-in-beer media and only some of it is legal. I know people that will buy DVDs of movies but will watch TV shows for free on some random website (which is probably spyware infested being a warez-type website) instead of paying for them.
I guess my point is that although most people do not care about the issue, they are not necessarily copying everything in sight. There is a sense of moral obligation to pay for products one uses or at least have a "legit" copy. If you presented the facts and asked you would probably find most people against copyright terms as long as they are, but I do not think you would get a resounding "no" on copyright even from people whose works are not affected by copyright.
Because it is a ridiculous point, not a good one. Do you refuse to buy a GPS navigation device for fear of the government using it to track you? That is essentially the same technology a robocar would use to decide (on a high level) where to go.
Actually, I do. I'm not delusional - I don't claim to have any special knowledge of government secrets. All I know is that a malicious government could abuse knowledge of the movements of its citizens. Maybe they'll do that someday, but I'd at least like to prevent them from using already installed systems to do so secretly.
May I ask what owning and operating a GPS navigation device has to do with the government being able to track your movements secretly?
Because it is a ridiculous point, not a good one. Do you refuse to buy a GPS navigation device for fear of the government using it to track you? That is essentially the same technology a robocar would use to decide (on a high level) where to go.
He also links to a way to check from the command line: porttest.dns-oarc.net -- Check your resolver's source port behavior. That method also allows you to test DNS servers other than the one you are using, so it provides a simply way to tell if your ISP has fixed their servers yet without changing your own config. The sidebar on doxpara just shows a 404 for me.
Those are (related) methods by which the client can assert that it knows the user's password without actually telling the password to the server (HTTP digest access authentication or similar methods involving hashing the password with a challenge string) and therefore not letting the password slip to someone in the middle. Of course, for a really secure transaction with your bank or similar, the connection will already be over HTTPS, so that is not much of a worry.
On the other hand, the same math allows for security tokens, which lets a system remotely verify that you physically have a token, allowing something-you-have security. Another way to handle such security might be to, say, have your ATM card have a secret key on it that it uses to authenticate itself. Then an ATM transaction requires the ATM card and your PIN, so a sketchy ATM stealing your PIN would not matter as much.
You will notice that last suggestion involved having a computer in your ATM card, which, although not all that expensive, is certainly more expensive than a magnetic strip. Basically, such extreme security measures are expensive and not in demand because most people have no idea how insecure their transactions are and quite simply identity theft is not high on most people's radar, so the fixes do not get implemented. As identity theft becomes more common and they security becomes less expensive, I suspect the demand will grow.
Yes, but you can delegate from one OpenID page to another. For example, you could get web hosting at example.com and set up OpenID there that just forwards from example@openid.google.com. Then if you want to change providers later, you just change who you forward from. Also, the services using OpenID for accounts will probably be smart enough to be aware of this problem and allowing changing OpenIDs like most services allow changing e-mail addresses today.
You could just use separate OpenIDs, at least for level 3 vs. the other two. (Getting you bank to accept (offer?) OpenID and getting an OpenID provider to offer a SecurID token are separate problems which also need to be addressed.) Don't most services already reauthenticate less often for things like iGoogle than for viewing webmail or changing settings?
Slashdot Mirror
It is a prediction for 20 years in the future. Hopefully our internet connections will be better by then.
The unfortunate reality is that the largest vulnerability is, and will be, the human element. They want their login to be "easy" - so anyone who gets physical access to the machine gets root access with no password credentials, or they use a trivially-cracked password. They want to "simplify" their security arrangements. They trust an email sent by their friends (or sometimes even spoofed to look like it came from themselves) or "system administrator at your domain."
End result? More vulnerabilities.
Unfortunately, the "solution" involves either telling a lot of crybabies "no, you can't have it this way" or else changing human nature. And it's not in human nature to stand up to the crybabies (actually, an actual corporation never would - it's "bad customer relations.")
No, the solution is to make systems secure by default and ensure that the easy ways to do things are also the secure ways. Note that although I use Linux for specific examples of some good security practices, it is not necessarily secure for the casual user.
Some solutions include better spam blocking. If those messages get blocked as spam, then the user never has a chance to react insecurely to them. This is likely incomplete and difficult to implement for all users, as spam blocker quality seems to vary widely and spam is continually improving. Some sort of trivial signature system could help. I believe there are services that will give you an S/MIME certificate for free based on proving that you can receive e-mail at a specific address. An e-mail client could probably automatically request such a certificate. Also, webmail providers could sign S/MIME certificates for their users automatically. That combined with throwing out unsigned e-mails from a sender whose public ke you know (as it was used in a previous e-mail) could make forging e-mail from addresses a bit more difficult.
A more direct solution may involve limiting the rights of software so if a user gets tricked into installing a program, it cannot do much damage. AppArmor and SELinux are extensions to Linux allowing for rights limiting of applications in addition to the more traditional chroot'ing and running as a limited user. Only software from the trusted repositories could get full rights -- preventing the user from getting tricked into adding a repository to the trusted list while making installs of 3rd party software feasible poses a further difficulty.
I do not offer solutions, only partial ideas. The general direction is that blaming users for using software insecurely will not get you anywhere. The software has to be designed so it is either secure or broken -- which was the idea behind the new Firefox 3 display for expi
And, by the way, this optimizing is also why there is "IE32" and "ARM" specific code in Chrome. There has to be. That's integral to how hotpath-type techniques work.
I thought that was what LLVM was for.
V8 is BSD to be specific. Microsoft could use it in IE if they wanted to.
Soon to get modded down as offtopic or troll, but why exactly is it that CS students think they're the smartest? What is it about knowing how to use a computer that makes for elitism? It's not like many CS students go on to cancer research with their computer skills. A few yes, but most of those were double majors in biology or were biology students taking a few computer classes.
I suspect it is a mix of its visibility and the type of mind that is good at computer science.
With the rise of the internet computers and people who have been successful with them have been very visible to the general population. The pervasive idea that no one except for a small minority has any idea how computers work while nearly everyone uses them may make those who are skilled with them feel elite and/or special.
Also, in relation to the theory of multiple intelligences, often people talking about intelligence only mean the Logical-Mathematical category, which is the one most closely related to computer science. Looking at that list, you may notice that several of those categories of intelligence are areas that computer geeks are stereotypically bad at.
Computer science is a field of mathematics which lays the basis for computers and algorithms. It is older than computers themselves. The actual applications tend to involve using a computer, but there is a lot of theory to learn and work with without actually touching one.
You mean like this? (Thanks to Dan Kaminsky's blog for the reference. I highly recommend reading his summary of SIGGRAPH; there's a lot of cool stuff there.)
Suddenly, it's "padlock USUALLY means OK, but you do need to check the URL and you should really also check the contents of the cert". It's far better to be clear and unambiguous about it, not in the least because if someone does get bitten, it can also affect you and me (botnets, more spam, more viruses etc).
The people arguing for self-signed SSL to have a usable UI in these comments are usually clear about what they mean by that: they do not mean they want it to look just like CA signed SSL. It should either look like plain HTTP or possibly be displayed as different but clearly less secure than CA signed SSL. Perhaps a broken padlock icon would work, maybe along with a red or orange highlight on the URL bar/favicon instead of the secure SSL yellow/blue/green.
Oh no, how do I know I am talking to the real Slashdot and not a fake one served by a man-in-the-middle attacker? Oh yeah, I don't. On the other hand, since I am sending my login cookie over an unencrypted link, a man-in-the-middle could simply sniff the cookie and hijack my login session, which is a lot easier than intercepting self-signed SSL, using a different certificate, and hoping I have not seen the real certificate before.
On the other hand, ignore this post, that sounds like an awesome excuse to disown any posts I later decide I dislike. ;)
Anyway, the GP says in the text you quoted that the encryption is to make sniffing more difficult, and he couldn't care less whom he is actually communicating with - if he did, he would use a trusted channel like talking face-to-face.
Except the problem seems to be flipped: with UAC, people seem to ignore the warning and always allow; with Firefox 3's self-signed certificates, people seem to ignore the warning and always deny. Both are signs of a bad UI.
You are correct that we should be wary of being too trusting, but currently all you need to drain most people's bank accounts is their password and some security question answers. Unlike a private key, these can be guessed or acquired through phishing or DNS poisoning or other attacks. Also, they are likely to be the same across multiple sites, so a security breach at one could cause trouble for users at another. The major problems with public keys are that (1) the software in not in place to use them and (2) passwords are portable, so you can use them from any computer.
For important things, we should be using Two-factor authentication, especially with things like keyfobs which show time-based passwords and fit on a keychain so they are not tied to one computer and are safe from malware - except, of course, if you have malware active when you access your bank website, it can simply hijack your session and do whatever it wants.
Past that, for really important things, people need to be aware that any computer security system (in fact, probably any security system) is going to be imperfect, and assumptions that a security system is perfect will lead to trouble. But that is not a good reason to avoid using good security as opposed to poor or no security.
If users were able to add self signed certs to a trusted list, then subsequent mitm attacks would be thwarted.
The current implementation involves a trusted list, which is a good idea: on a couple projects I have worked on self-signed HTTPS (verified via phone) has been used for version control and project information.
One should also consider the even simpler layer of security of SSH-style certificate checks: warn if the certificate is new or different from the previous one.
Because OpenDNS never had the flaw in the first place.
If you're accepting self-signed certificates, there's no way for you to easily differentiate my false certificate from the site's real one. Self-signed certificates are dangerous because they give the user the impression that they have gained some security when they have not.
Erm, then just change the UI for self-signed certificates. Do not make them look secure. Either make them look like plain HTTP or have and orange or red color warning the user that the connection is unsecured. If they care about the security of the link, then they will check for the blue/green/yellow. Also, there should be a warning if the cert is at all different from the previous time viewing the page, perhaps only if the new cert is untrusted (self-signed) or only if the old cert is not expired.
USB monitors exist. Here is a review of one. As mentioned in the review, the problem is that there are not any USB graphics cards, so the graphics are not hardware accelerated. They get around the bandwidth problem by using "DisplayLink" compression.
Even if we assume everyone continues to use the same password, with the same account, everywhere, it's still better than a conventional login. With the conventional login, every site I log into could steal my password and use it to login as me elsewhere. With OpenID, only my OpenID provider can do that.
Well that is true with most current systems, it is not an intrinsic problem with password authentication. digest access authentication is an example of a password-based authentication method where the server does not need to know the password. It does not involve a salt other than the HTTP realm, but that could be changed. With such a system, you could use the same password on several different web sites and only ever give them hashed versions with different salts. Then the problem of knowing your password would not exist. Of course, such systems are unlikely be used in part because they would be more complicated to setup and because it would be nearly impossible for the user to tell the difference.
That said, I think the other advantages of OpenID that you give are important.
While it is true that Limewire, etc. are popularized, there are two major points to consider here:
I guess my point is that although most people do not care about the issue, they are not necessarily copying everything in sight. There is a sense of moral obligation to pay for products one uses or at least have a "legit" copy. If you presented the facts and asked you would probably find most people against copyright terms as long as they are, but I do not think you would get a resounding "no" on copyright even from people whose works are not affected by copyright.
Because it is a ridiculous point, not a good one. Do you refuse to buy a GPS navigation device for fear of the government using it to track you? That is essentially the same technology a robocar would use to decide (on a high level) where to go.
Actually, I do. I'm not delusional - I don't claim to have any special knowledge of government secrets. All I know is that a malicious government could abuse knowledge of the movements of its citizens. Maybe they'll do that someday, but I'd at least like to prevent them from using already installed systems to do so secretly.
May I ask what owning and operating a GPS navigation device has to do with the government being able to track your movements secretly?
Because it is a ridiculous point, not a good one. Do you refuse to buy a GPS navigation device for fear of the government using it to track you? That is essentially the same technology a robocar would use to decide (on a high level) where to go.
We've mixed together chemical soups and watched life erupt out of it.
If we have, this is the first I've heard of it. Have you any reputable links?
Your skepticism is quite reasonable. The closest I know of is The Miller-Urey experiment which produced a few proteins.
He also links to a way to check from the command line: porttest.dns-oarc.net -- Check your resolver's source port behavior. That method also allows you to test DNS servers other than the one you are using, so it provides a simply way to tell if your ISP has fixed their servers yet without changing your own config. The sidebar on doxpara just shows a 404 for me.
Read up a bit on cryptography, specifically cryptographic hash functions and digital signatures.
Those are (related) methods by which the client can assert that it knows the user's password without actually telling the password to the server (HTTP digest access authentication or similar methods involving hashing the password with a challenge string) and therefore not letting the password slip to someone in the middle. Of course, for a really secure transaction with your bank or similar, the connection will already be over HTTPS, so that is not much of a worry.
On the other hand, the same math allows for security tokens, which lets a system remotely verify that you physically have a token, allowing something-you-have security. Another way to handle such security might be to, say, have your ATM card have a secret key on it that it uses to authenticate itself. Then an ATM transaction requires the ATM card and your PIN, so a sketchy ATM stealing your PIN would not matter as much.
You will notice that last suggestion involved having a computer in your ATM card, which, although not all that expensive, is certainly more expensive than a magnetic strip. Basically, such extreme security measures are expensive and not in demand because most people have no idea how insecure their transactions are and quite simply identity theft is not high on most people's radar, so the fixes do not get implemented. As identity theft becomes more common and they security becomes less expensive, I suspect the demand will grow.
Yes, but you can delegate from one OpenID page to another. For example, you could get web hosting at example.com and set up OpenID there that just forwards from example@openid.google.com. Then if you want to change providers later, you just change who you forward from. Also, the services using OpenID for accounts will probably be smart enough to be aware of this problem and allowing changing OpenIDs like most services allow changing e-mail addresses today.
True, but password reset e-mails get sent to your e-mail.
You could just use separate OpenIDs, at least for level 3 vs. the other two. (Getting you bank to accept (offer?) OpenID and getting an OpenID provider to offer a SecurID token are separate problems which also need to be addressed.) Don't most services already reauthenticate less often for things like iGoogle than for viewing webmail or changing settings?