Hasn't someone already bought rights to that spectrum? It doesn't belong to the TV stations. Is the government going to keep the money but not give the buyer the spectrum?
If anything completely out of the ordinary happens to the stock market, if some random event sends a jolt through all of Wall Street and pushes G.M. to, say, twenty dollars, Nassim Taleb will not end up in a dowdy apartment in Athens. He will be rich.
It could equally well be asked, what would motivate someone to clamp down on the energy that fuels our economy during the worst economic downturn in generations?
There are tradeoffs to be made. But being motivated by one side or the other of the tradeoff interferes with objective science.
Instead of pushing a politically motivated agenda, why not look for common ground. Reducing dependence on foreign oil is an appealing goal to people both sides of the issue. Don't shove global warming theories down everyone's throat.
> Some real nice attempts at "Argument from Authority" there. > > So far it seems that the scientific consensus is that warming is real and likely to be contributed towards by human > activity.
The pot is calling the kettle black. Appeal to "scientific consensus" is also a nice attempt at "Argument from Authority" -- and an attempt to discredit the argument without dealing with the substance.
Someone help me understand how direct quotes from a plethora of highly credentialed scientists rates a 4, and an ad hominem attack on that post rates a 5????
If I can remotely turn your laptop into a paperweight, is that a feature or a bug?
I suspect someone is vastly overconfident of their ability to secure this feature.
Surely what is required is to isolate the sensitive information, so that it can be protected.
That's a great idea that in practice will leak your information.
It all depends on what you are protecting and how that information is used. In the most demanding case, you need mandatory access controls (something like SELinux, data classification, no read-up, no write-down...). If that is your situation then getting a policy waiver will be dramatically harder. You might be able to get a waiver if you airgap your machine from the sensitive network, etc.
If your business is not sensitive enough to require mandatory access controls, then you have a better shot, if you don't handle sensitive data on the machine you want exempted.
A challenge-response protocol simply provides a way to prove that you know a certain secret. To claim that this secret cannot be stolen is naive -- even if the secret is based in part on physical properties of a particular chip. In the end it is just a series of bits. Smart money says it can be stolen, given physical access to the chip.
Of course there is also the potential to discover the secret by brute force. If there are biases in the physical properties on which it is based, it could be easier to brute-force than advertised.
OpenID just shifts the vulnerability. Someone, somewhere must determine that you are who you claim to be. That becomes the new target for attackers.
If someone puts a keylogger / trojan horse on your machine, it's still "game over." Likewise if someone compromises the authentication service, or if they are able to defeat the authentication protocol in some manner.
Also, OpenID raises the cost of a successful exploit. Stolen credentials give access to every account where you use that OpenID. So you dare not use the OpenID on your bank account, nor your email account (you know, the place where the bank sends password resets...), nor any other high-value account. So OpenID is only useful for accounts that don't need strong protection (places where you may as well use a password!)
In the real world, in order to trust authentication via public key cryptography, you must accept the following assumptions:
1) The party on the other end has adequately protected their private key, with no (zero) lapses, ever.
2) The hardware containing your private key has never been accessed by an unauthorized party.
3) The software being executed on both sides has been properly implemented and is actually performing the expected crypto algorithm... and is not also exposing the private key.
4) Random number generation used to generate asymmetric keys and symmetric session keys is cryptographically strong, on both sides of the conversation.
5) The hardware on the other end of the conversation is currently being controlled by the party you expect.
Etc... Virtually always, a person sitting at a computer doesn't perform public key cryptography. Instead, he types commands and views responses (or clicks icons and sees gui dialogs)... and makes many assumptions about what happened behind the scenes.
Suffice it to say, "public key cryptography" is not a magic answer. Secure authentication is a very hard problem.
I RTFA. At this point, we're hanging all of our eggs into the encyrption basket. If someone proves P=NP and breaks SSL, the whole internet is hosed. Now again, why are we telling people that this stuff is safe, when -we- know that it is not?
1. The internet will have to balkanized into those countries that have laws to go after hackers and those who do not.
2. Consumers will eventually only choose content that is actually hosted by their ISPs because that will be the only content that is safe.
3. ISPs will increasingly look to disallow traffic coming from "non-trusted" ISPs in order to protect themselves.
Self-signed certificates with unknown parties are pretty much tantamount to no security at all; the encryption can't be relied on for more than obfuscation.
Sometimes obfuscation is all you need. The proper choice of countermeasures depends on the threat and the value of the information being protected, and on the cost of the countermeasure.
There are lots of times when SSL is used for less than its complete feature set. SSL provides a mechanism for *mutual* authentication, but how often does the server actually require a verified SSL certificate from the client? The fact that servers usually don't do this does not mean SSL is not useful in that context. Likewise, the absence of a verified server side certificate does not necessarily mean that SSL is providing no value. Encryption without authentication provides a degree of privacy, raising the level of difficulty significantly for anyone who would want to eavesdrop.
When a client encounters a self-signed certificate, or when the certificate is a type that is weakly verified by the CA, the client should simply notify the user of that fact. That can be done with a single notifier. The notifier can provide the user the option of verifiying the certificate out-of-band so it will be trusted next time without a nag screen.
If your OpenID is linked to your email account, and your email account is used for password reset at your bank (or brokerage, or paypal, or any online store that holds your credit card number...), then compromising your OpenID account can give access to your financial account.
It's a problem because accessing one site on a compromised machine gives away your credentials to all your sites. I would never consider accessing my banking account from a library pc. But if I accessed some social networking site on that same machine using OpenID on it, I've given away the credentials to my banking account.
My current bank forced me to select 6 questions, many of which there were no choices I knew the answer to, but that someone stealing my identity could find.
Just put in a strong password as the answer to each of the questions. It's about the best you can do.
The benefit of periodically changing your password is highly debateable. See Dr Eugene Spafford's blog article on the subject:
http://www.cerias.purdue.edu/site/blog/post/password-change-myths/
Aside from that, widespread adoption of OpenID would be a hacker's dream. It's no more difficult to steal credentials under OpenID than it is under a conventional login. Steal one set of credentials and you have access to everything the person does under OpenID. Today, I can use extra caution when loggin in to a bank, ebay, paypal, etc -- only doing it on a well-trusted machine, for example. With OpenID, I have to use that same paranoia on every site where the id is recognized.
If you're smart you won't use OpenID for anything that really matters. And you might be surprised what really matters. Your email account is at the top of the list (think banking password reset requests...)
What they have accomplished under a single authentication protocol will probably be extended to the others. When this technique is fully developed, it has potential for other uses besides throttling. For example, a company could use it at the perimeter firewall to prevent use of ssh tunnels to bypass a web proxy.
The policy of forcing users to change their passwords monthly does not effectively counter any real-world threats, and creates additional threats.
Instead, force users to pick a strong password and never change it unless there is suspicion of compromise.
To send email securely from a public terminal:
Type your message into a PDA, encrypt and sign it. Then, load it onto the public pc via a usb port, or in worst case scenario, type it in (assumes it was encrypted into ascii form, gpg -a etc) If you have to type it, good luck getting it right.
Then login to a disposable email account, and send the encrypted file as an attachment.
Receiving email securely is more problematic. You could arrange for a particular individual or individuals to send you email in a manner analogous to the above, to a temporary email address set up for the purpose. But I don't think there is any way to get email from the "general public" securely on a public computer.
Slashdot Mirror
Hasn't someone already bought rights to that spectrum? It doesn't belong to the TV stations. Is the government going to keep the money but not give the buyer the spectrum?
Quote from the article:
So, does anybody know whether Taleb is rich now?
It could equally well be asked, what would motivate someone to clamp down on the energy that fuels our economy during the worst economic downturn in generations? There are tradeoffs to be made. But being motivated by one side or the other of the tradeoff interferes with objective science. Instead of pushing a politically motivated agenda, why not look for common ground. Reducing dependence on foreign oil is an appealing goal to people both sides of the issue. Don't shove global warming theories down everyone's throat.
> Some real nice attempts at "Argument from Authority" there.
>
> So far it seems that the scientific consensus is that warming is real and likely to be contributed towards by human
> activity.
The pot is calling the kettle black. Appeal to "scientific consensus" is also a nice attempt at "Argument from Authority" -- and an attempt to discredit the argument without dealing with the substance.
Someone help me understand how direct quotes from a plethora of highly credentialed scientists rates a 4, and an ad hominem attack on that post rates a 5????
Extra energy entering the atmosphere, not previously accounted for. Time to recalibrate all those global warming models.
Hey, maybe this is what's causing the climate to warm.
Among all the religions, smalltalk is the one that is true and pure.
If I can remotely turn your laptop into a paperweight, is that a feature or a bug? I suspect someone is vastly overconfident of their ability to secure this feature.
pgpdisk provides key escrow features for enterprise manageability.
PGP provides enterprise features that truecrypt does not. (key escrow...)
Surely what is required is to isolate the sensitive information, so that it can be protected.
That's a great idea that in practice will leak your information.
It all depends on what you are protecting and how that information is used. In the most demanding case, you need mandatory access controls (something like SELinux, data classification, no read-up, no write-down...). If that is your situation then getting a policy waiver will be dramatically harder. You might be able to get a waiver if you airgap your machine from the sensitive network, etc. If your business is not sensitive enough to require mandatory access controls, then you have a better shot, if you don't handle sensitive data on the machine you want exempted.
A challenge-response protocol simply provides a way to prove that you know a certain secret. To claim that this secret cannot be stolen is naive -- even if the secret is based in part on physical properties of a particular chip. In the end it is just a series of bits. Smart money says it can be stolen, given physical access to the chip. Of course there is also the potential to discover the secret by brute force. If there are biases in the physical properties on which it is based, it could be easier to brute-force than advertised.
OpenID just shifts the vulnerability. Someone, somewhere must determine that you are who you claim to be. That becomes the new target for attackers. If someone puts a keylogger / trojan horse on your machine, it's still "game over." Likewise if someone compromises the authentication service, or if they are able to defeat the authentication protocol in some manner. Also, OpenID raises the cost of a successful exploit. Stolen credentials give access to every account where you use that OpenID. So you dare not use the OpenID on your bank account, nor your email account (you know, the place where the bank sends password resets...), nor any other high-value account. So OpenID is only useful for accounts that don't need strong protection (places where you may as well use a password!)
In the real world, in order to trust authentication via public key cryptography, you must accept the following assumptions: 1) The party on the other end has adequately protected their private key, with no (zero) lapses, ever. 2) The hardware containing your private key has never been accessed by an unauthorized party. 3) The software being executed on both sides has been properly implemented and is actually performing the expected crypto algorithm... and is not also exposing the private key. 4) Random number generation used to generate asymmetric keys and symmetric session keys is cryptographically strong, on both sides of the conversation. 5) The hardware on the other end of the conversation is currently being controlled by the party you expect. Etc... Virtually always, a person sitting at a computer doesn't perform public key cryptography. Instead, he types commands and views responses (or clicks icons and sees gui dialogs)... and makes many assumptions about what happened behind the scenes. Suffice it to say, "public key cryptography" is not a magic answer. Secure authentication is a very hard problem.
I RTFA. At this point, we're hanging all of our eggs into the encyrption basket. If someone proves P=NP and breaks SSL, the whole internet is hosed. Now again, why are we telling people that this stuff is safe, when -we- know that it is not?
1. The internet will have to balkanized into those countries that have laws to go after hackers and those who do not. 2. Consumers will eventually only choose content that is actually hosted by their ISPs because that will be the only content that is safe. 3. ISPs will increasingly look to disallow traffic coming from "non-trusted" ISPs in order to protect themselves.
Sounds like we're headed back to Compuserve!
Agreed. But it shouldn't take four clicks and an "add an exception" dialog to bypass.
Self-signed certificates with unknown parties are pretty much tantamount to no security at all; the encryption can't be relied on for more than obfuscation.
Sometimes obfuscation is all you need. The proper choice of countermeasures depends on the threat and the value of the information being protected, and on the cost of the countermeasure.
There are lots of times when SSL is used for less than its complete feature set. SSL provides a mechanism for *mutual* authentication, but how often does the server actually require a verified SSL certificate from the client? The fact that servers usually don't do this does not mean SSL is not useful in that context. Likewise, the absence of a verified server side certificate does not necessarily mean that SSL is providing no value. Encryption without authentication provides a degree of privacy, raising the level of difficulty significantly for anyone who would want to eavesdrop. When a client encounters a self-signed certificate, or when the certificate is a type that is weakly verified by the CA, the client should simply notify the user of that fact. That can be done with a single notifier. The notifier can provide the user the option of verifiying the certificate out-of-band so it will be trusted next time without a nag screen.
If your OpenID is linked to your email account, and your email account is used for password reset at your bank (or brokerage, or paypal, or any online store that holds your credit card number...), then compromising your OpenID account can give access to your financial account.
It's a problem because accessing one site on a compromised machine gives away your credentials to all your sites. I would never consider accessing my banking account from a library pc. But if I accessed some social networking site on that same machine using OpenID on it, I've given away the credentials to my banking account.
My current bank forced me to select 6 questions, many of which there were no choices I knew the answer to, but that someone stealing my identity could find.
Just put in a strong password as the answer to each of the questions. It's about the best you can do.
You enter your credentials to the openid provider who then sends ...
Ever heard of a keystroke logger?
The benefit of periodically changing your password is highly debateable. See Dr Eugene Spafford's blog article on the subject: http://www.cerias.purdue.edu/site/blog/post/password-change-myths/ Aside from that, widespread adoption of OpenID would be a hacker's dream. It's no more difficult to steal credentials under OpenID than it is under a conventional login. Steal one set of credentials and you have access to everything the person does under OpenID. Today, I can use extra caution when loggin in to a bank, ebay, paypal, etc -- only doing it on a well-trusted machine, for example. With OpenID, I have to use that same paranoia on every site where the id is recognized. If you're smart you won't use OpenID for anything that really matters. And you might be surprised what really matters. Your email account is at the top of the list (think banking password reset requests...)
What they have accomplished under a single authentication protocol will probably be extended to the others. When this technique is fully developed, it has potential for other uses besides throttling. For example, a company could use it at the perimeter firewall to prevent use of ssh tunnels to bypass a web proxy.
The policy of forcing users to change their passwords monthly does not effectively counter any real-world threats, and creates additional threats. Instead, force users to pick a strong password and never change it unless there is suspicion of compromise.
To send email securely from a public terminal: Type your message into a PDA, encrypt and sign it. Then, load it onto the public pc via a usb port, or in worst case scenario, type it in (assumes it was encrypted into ascii form, gpg -a etc) If you have to type it, good luck getting it right. Then login to a disposable email account, and send the encrypted file as an attachment. Receiving email securely is more problematic. You could arrange for a particular individual or individuals to send you email in a manner analogous to the above, to a temporary email address set up for the purpose. But I don't think there is any way to get email from the "general public" securely on a public computer.