While not storing cleartext, they do store your WiFi passwords in a reversible encryption.
Okay, let's get a few things straight here.
First, "reversible encryption" is a stupid phrase. There are basically two kinds of encryption: symmetric encryption and asymmetric encryption. Symmetric encryption uses a single secret key to both encrypt and decrypt data. It's reversible (using the one key). Asymmetric encryption uses two keys: one key to encrypt and a different key to decrypt. It's also reversible, but the encrypt and decrypt operations can only be performed with the corresponding key. They're both reversible. In fact, the point of encryption is that it's reversible.
Hashes are cryptographic operations that are one-way. That is, not reversible. Hashing is not encryption.
Second, WPA, WEP, and all sort of other security protocols are relatively simple (read: usable) in that the security is provided by a shared secret. That is, the two parties (ie., your phone and your wireless router) both have a copy of a secret piece of information. That piece of information might be a password, a key, a key derived from a password, a hash of something or another. It doesn't really matter. The point is that the a key aspect of the protocol is that both sides must have the secret.
For these systems, both sides fundamentally have to store the secret in an accessible form. That is, they "have to store your password in plaintext". Or they have to ask you to input it again every time it needs to be used (ie., you connect to the wireless network). Because both sides need to have the shared secret in its original form in order to perform their protocol. That's how the protocols. So you can't really store those passwords in an irretrievable fashion. Sure, you can store that data in some kind of encrypted database, but the system needs to be able to decrypt that database whenever it needs to access the secrets. This means it needs to either store the encryption key to that database somewhere (in which case the database can hardly be considered "secure") or it needs to ask you for the encryption key (ie., a password) every time it needs to access the database -- meaning that what you can do is replace one secret (the stored data) with another one (the database password).
So don't complain too hard when you find out that you can retrieve your saved Web passwords in Chrome (or Firefox) or that you can retrieve WPA passwords from... well, everything. There is, fundamentally, no alternative. (Storage "in the cloud" is another matter.)
Probably the most effective system that provides some real benefits is using system-level support for encrypted databases that is tied to your login credentials. Even better if this is full-disk encryption below the logical OS level.
If you walked into an office for a job interview, and the first thing you saw was some management type openly berating a subordinate, what tone would that set
Linus isn't a "management type", here, he's a senior engineer. It's very different. A "management type" (let's just call him a "manager") carries the connotation of generally not knowing what they're talking about -- at least not for technical matters, which is presumably what the berated person and the reader are really interested in. A senior engineer does.
If I saw a senior engineer berating a junior engineer's work, which is what Linus does, I wouldn't think anything of it -- I see it all the time.
The Nobel Peace Prize and scientific Nobel prizes are decided on by completely different groups. The only thing they have in common is the word "Nobel". The scientific prizes are decided by the Swedish Academy of Sciences. The Peace prize is decided by an independent body, the Norwegian Nobel Committee.
You might have a second thought when you travel to mainland China and find you can't access Dropbox.
You know, Dropbox stores all files locally and uses the cloud storage to keep all copies of the same directory in sync. So if you travel with one computer to some place with no access to Dropbox, then you still have access to all your files and it will sync the changes when you once again have access.
You know, most of the feds that go to Defcon are simply security researchers and hackers, just like half the other people there, who happen to work for a different organization.
The Feds at DefCon and Black Hat mostly just wear jeans and t-shirts like everyone else. It's a little easier at Black Hat because many of them won't put their company name on their badge. DefCon doesn't have identification on badges.
They were accessible to more people than they needed to be, yes. They were accessible to Bradley Manning, yes.
When you get a clearance, they don't just hand you access to the computer systems that contain that kind of data. Those documents were on a SIPRNET server. You cannot, in fact, simply wave your clearance at a computer and pull documents off of SIPRNET. It is a lot more trouble than that.
A lot of people had access to them, yes, but it is not nearly as large as the set of all people with TS clearance.
it's silly that usa isn't counted from the end of the civil war
The US now was the Union during the Civil War and was the US before the civil war and had a continuous government from before until after the civil war.
(Personally, I prefer the "sovereign entity" definition, so would include both UK and Austro-Hungarian Empire as countries, but a project like this really ought to apply some degree of consistency, so should have either both or neither.)
The Austro-Hungarian Empire doesn't exist any more. The land it controlled is now a collection of different sovereign entities.
So... explain how that helps when someone hacks into the server and requests data using the same mechanisms and level of authority as the server software (which must ultimately manipulate unencrypted data).
The current SSL system is also totally open to a main-in-the-middle attacks by state sponsors, as has been reported here various times. And yes self signed certs are also very vulnerable to the same attack - but the point here is to encrypt the majority of data.
They're not vulnerable to "the same attack". One attack requires hacking a CA or exerting very substantial influence over them. The other doesn't. The set of malicious actors who can -- and do -- MitM you if you use self-signed certs is much, much larger than the set of actors who can do it if you use CA-signed certs.
The only argument I have seen against this rational is that people may be lulled into a false sense of security if they believe self signed certs are as secure as CA issued ones, falling for MITM attacks for their bank traffic etc. The counter to that is that is simple and sensible: no, not if the browser does not try to tell them they have a top secure connection - and treats it like it is a plain text connection.
Yes, that's pretty much the argument. The danger is that they could think that their connection is somehow more secure than plaintext. You cannot safely fix this without determining user intent, and even the user can't usually be trusted to determine their intent. If they intended to use HTTPS to get real security but instead were presented with a self-signed certificate, they should be warned. They shouldn't just continue on blithely unaware -- which is exactly what will happen if you treat it as a normal unencrypted connection. People don't check these things. If they intended to have no security, like HTTP, actually using HTTPS with a self-signed certificate is no worse. But you can't easily tell the difference between those two situations. By treating self-signed-certificate-based HTTPS as if it were normal HTTP, you make it easier to use a shitty security mechanism (a key exchange where you have no idea if the party you're exchanging keys with is the party you intend to communicate with), but you make it much harder for most users to detect a common and very dangerous attack. That's a terrible tradeoff.
It'd be easier to add an extension to HTTP that enables opportunistic un-cert'ed if both client and server support it, then push support for that extension into Firefox and Apache (or convince Google that it's a good idea). Except that no serious website will benefit at all from this, since they all can afford the small cost of a certificate for HTTPS.
Last time I did a back-of-the-envelope calculation, running an electric car off of a 100% coal power source produces CO2 at roughly the rate of a gasoline-powered car at 40 mpg. Which is not amazing, but is not bad. Of course, if you live someplace like California or upstate New York (cleanest energy in the country), it is dramatically, dramatically better.
That's not their decision to make. A different part of the executive could declassify it, sure, but in the meantime, the DoD is just dealing with the bureaucratic reality of regulations concerning classified data.
Do they really want their own personnel to be less informed than the general public? It's not like preventing soldiers from reading the information is going to keep it out of the hands of the "enemy".
That's not what they're trying to do at all. It's a bureaucratic measure because they don't want any classified material -- regardless of how it was obtained -- stored on unclassified DoD computers. That avoids the problem of people finding it later and having to go through the whole procedure of figuring out how it got there. It's easier to take reasonable measures to keep classified material off the computers in the first place. (It's still kind of stupid, but at least it has a reason.)
So, you trust our government to be cautious and scrupulous about the amount and nature of radiation they use to survey the public, and to use a precautionary principle where there is any doubt about whether they are endangering your life?
I didn't say that. But I do happen to be familiar with how much X-ray radiation you typically use in Compton backscattering scanners.
Additionally: why do we even have browser disk cache in place anymore? Most of the pages of modern web are dynamic (cgi-bin), so you never want old copies anyway.
Web servers tell the browser not to cache dynamic pages. (So, for dynamic pages, it's like there is no disk cache!) But the bulk of the data is in static resources used by those dynamic pages, like images and Javascript libraries.
That protects you against someone stealing your hard drive -- which is a pretty reasonable fear if you have a laptop. It does nothing against malware, which is enormously more common.
That is BS. There are plenty of scenarios in which an attacker having read access to your browser cache is significantly less privileged than the sensitivity of information discussed here.
And it would have violated several standards if you arbitrarily decided to not cache any SSL delivered data.
What part of the standard? Last I knew, you're not required to cache any data, and what data you choose to cache and not cache is up to you, unless the headers tell you otherwise.
This sounds almost like what the government is already deploying. In one context, x-ray trucks are terrorism. In the other, they're part of the counter-terrorism effort.
And yes, I know the doses would be different, but where do you draw the line?
That's like saying giving someone an injection with a needle that's been sterilized with bleach is the same as giving them an injection of bleach. Hey, they both contain *some* bleach!
Slashdot Mirror
While not storing cleartext, they do store your WiFi passwords in a reversible encryption.
Okay, let's get a few things straight here.
First, "reversible encryption" is a stupid phrase. There are basically two kinds of encryption: symmetric encryption and asymmetric encryption. Symmetric encryption uses a single secret key to both encrypt and decrypt data. It's reversible (using the one key). Asymmetric encryption uses two keys: one key to encrypt and a different key to decrypt. It's also reversible, but the encrypt and decrypt operations can only be performed with the corresponding key. They're both reversible. In fact, the point of encryption is that it's reversible.
Hashes are cryptographic operations that are one-way. That is, not reversible. Hashing is not encryption.
Second, WPA, WEP, and all sort of other security protocols are relatively simple (read: usable) in that the security is provided by a shared secret. That is, the two parties (ie., your phone and your wireless router) both have a copy of a secret piece of information. That piece of information might be a password, a key, a key derived from a password, a hash of something or another. It doesn't really matter. The point is that the a key aspect of the protocol is that both sides must have the secret.
For these systems, both sides fundamentally have to store the secret in an accessible form. That is, they "have to store your password in plaintext". Or they have to ask you to input it again every time it needs to be used (ie., you connect to the wireless network). Because both sides need to have the shared secret in its original form in order to perform their protocol. That's how the protocols. So you can't really store those passwords in an irretrievable fashion. Sure, you can store that data in some kind of encrypted database, but the system needs to be able to decrypt that database whenever it needs to access the secrets. This means it needs to either store the encryption key to that database somewhere (in which case the database can hardly be considered "secure") or it needs to ask you for the encryption key (ie., a password) every time it needs to access the database -- meaning that what you can do is replace one secret (the stored data) with another one (the database password).
So don't complain too hard when you find out that you can retrieve your saved Web passwords in Chrome (or Firefox) or that you can retrieve WPA passwords from... well, everything. There is, fundamentally, no alternative. (Storage "in the cloud" is another matter.)
Probably the most effective system that provides some real benefits is using system-level support for encrypted databases that is tied to your login credentials. Even better if this is full-disk encryption below the logical OS level.
If you walked into an office for a job interview, and the first thing you saw was some management type openly berating a subordinate, what tone would that set
Linus isn't a "management type", here, he's a senior engineer. It's very different. A "management type" (let's just call him a "manager") carries the connotation of generally not knowing what they're talking about -- at least not for technical matters, which is presumably what the berated person and the reader are really interested in. A senior engineer does.
If I saw a senior engineer berating a junior engineer's work, which is what Linus does, I wouldn't think anything of it -- I see it all the time.
The Nobel Peace Prize and scientific Nobel prizes are decided on by completely different groups. The only thing they have in common is the word "Nobel". The scientific prizes are decided by the Swedish Academy of Sciences. The Peace prize is decided by an independent body, the Norwegian Nobel Committee.
The Nobel Peace Prize has always been political.
You might have a second thought when you travel to mainland China and find you can't access Dropbox.
You know, Dropbox stores all files locally and uses the cloud storage to keep all copies of the same directory in sync. So if you travel with one computer to some place with no access to Dropbox, then you still have access to all your files and it will sync the changes when you once again have access.
You know, most of the feds that go to Defcon are simply security researchers and hackers, just like half the other people there, who happen to work for a different organization.
DefCon is cash only, no registration, no identifying information.
The Feds at DefCon and Black Hat mostly just wear jeans and t-shirts like everyone else. It's a little easier at Black Hat because many of them won't put their company name on their badge. DefCon doesn't have identification on badges.
No.
They were accessible to more people than they needed to be, yes. They were accessible to Bradley Manning, yes.
When you get a clearance, they don't just hand you access to the computer systems that contain that kind of data. Those documents were on a SIPRNET server. You cannot, in fact, simply wave your clearance at a computer and pull documents off of SIPRNET. It is a lot more trouble than that.
A lot of people had access to them, yes, but it is not nearly as large as the set of all people with TS clearance.
RTFS. The proposed character looks like a combination of T and h, but its meaning is the entire English word "the", not the sound "th".
it's silly that usa isn't counted from the end of the civil war
The US now was the Union during the Civil War and was the US before the civil war and had a continuous government from before until after the civil war.
(Personally, I prefer the "sovereign entity" definition, so would include both UK and Austro-Hungarian Empire as countries, but a project like this really ought to apply some degree of consistency, so should have either both or neither.)
The Austro-Hungarian Empire doesn't exist any more. The land it controlled is now a collection of different sovereign entities.
So... explain how that helps when someone hacks into the server and requests data using the same mechanisms and level of authority as the server software (which must ultimately manipulate unencrypted data).
Because that's what happens.
Since when is credit card data, e-mail address, and password the only "customer data" a company keeps about you?
The current SSL system is also totally open to a main-in-the-middle attacks by state sponsors, as has been reported here various times. And yes self signed certs are also very vulnerable to the same attack - but the point here is to encrypt the majority of data.
They're not vulnerable to "the same attack". One attack requires hacking a CA or exerting very substantial influence over them. The other doesn't. The set of malicious actors who can -- and do -- MitM you if you use self-signed certs is much, much larger than the set of actors who can do it if you use CA-signed certs.
The only argument I have seen against this rational is that people may be lulled into a false sense of security if they believe self signed certs are as secure as CA issued ones, falling for MITM attacks for their bank traffic etc. The counter to that is that is simple and sensible: no, not if the browser does not try to tell them they have a top secure connection - and treats it like it is a plain text connection.
Yes, that's pretty much the argument. The danger is that they could think that their connection is somehow more secure than plaintext. You cannot safely fix this without determining user intent, and even the user can't usually be trusted to determine their intent. If they intended to use HTTPS to get real security but instead were presented with a self-signed certificate, they should be warned. They shouldn't just continue on blithely unaware -- which is exactly what will happen if you treat it as a normal unencrypted connection. People don't check these things. If they intended to have no security, like HTTP, actually using HTTPS with a self-signed certificate is no worse. But you can't easily tell the difference between those two situations. By treating self-signed-certificate-based HTTPS as if it were normal HTTP, you make it easier to use a shitty security mechanism (a key exchange where you have no idea if the party you're exchanging keys with is the party you intend to communicate with), but you make it much harder for most users to detect a common and very dangerous attack. That's a terrible tradeoff.
It'd be easier to add an extension to HTTP that enables opportunistic un-cert'ed if both client and server support it, then push support for that extension into Firefox and Apache (or convince Google that it's a good idea). Except that no serious website will benefit at all from this, since they all can afford the small cost of a certificate for HTTPS.
Last time I did a back-of-the-envelope calculation, running an electric car off of a 100% coal power source produces CO2 at roughly the rate of a gasoline-powered car at 40 mpg. Which is not amazing, but is not bad. Of course, if you live someplace like California or upstate New York (cleanest energy in the country), it is dramatically, dramatically better.
Maybe they do, but they also understand the power of clever PR.
That's not their decision to make. A different part of the executive could declassify it, sure, but in the meantime, the DoD is just dealing with the bureaucratic reality of regulations concerning classified data.
Do they really want their own personnel to be less informed than the general public? It's not like preventing soldiers from reading the information is going to keep it out of the hands of the "enemy".
That's not what they're trying to do at all. It's a bureaucratic measure because they don't want any classified material -- regardless of how it was obtained -- stored on unclassified DoD computers. That avoids the problem of people finding it later and having to go through the whole procedure of figuring out how it got there. It's easier to take reasonable measures to keep classified material off the computers in the first place. (It's still kind of stupid, but at least it has a reason.)
The rest of the world doesn't even comprehend this bizarre concept of 'the humanities' that you've invented...
That would be some trick, Americans defining the modern word "humanities" in Renaissance Europe. (The concept dates back to at least classical Rome.)
So, you trust our government to be cautious and scrupulous about the amount and nature of radiation they use to survey the public, and to use a precautionary principle where there is any doubt about whether they are endangering your life?
I didn't say that. But I do happen to be familiar with how much X-ray radiation you typically use in Compton backscattering scanners.
Additionally: why do we even have browser disk cache in place anymore? Most of the pages of modern web are dynamic (cgi-bin), so you never want old copies anyway.
Web servers tell the browser not to cache dynamic pages. (So, for dynamic pages, it's like there is no disk cache!) But the bulk of the data is in static resources used by those dynamic pages, like images and Javascript libraries.
That protects you against someone stealing your hard drive -- which is a pretty reasonable fear if you have a laptop. It does nothing against malware, which is enormously more common.
That is BS. There are plenty of scenarios in which an attacker having read access to your browser cache is significantly less privileged than the sensitivity of information discussed here.
And it would have violated several standards if you arbitrarily decided to not cache any SSL delivered data.
What part of the standard? Last I knew, you're not required to cache any data, and what data you choose to cache and not cache is up to you, unless the headers tell you otherwise.
This sounds almost like what the government is already deploying. In one context, x-ray trucks are terrorism. In the other, they're part of the counter-terrorism effort.
And yes, I know the doses would be different, but where do you draw the line?
That's like saying giving someone an injection with a needle that's been sterilized with bleach is the same as giving them an injection of bleach. Hey, they both contain *some* bleach!
Quantity is important.