Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×

Comment Re:That's why Liux isn't 1st choice for security.. (Score 0) 341

True, but as you say: the "password" is a generator seed, and the real access key is what's stored in plaintext. Also: this intermediate hash needs to be repeatable, so it can't really be salted (I can come up with a few over-engineered ways, like the AP sending back the salt in the handshake and you store the salt), so rainbow tables.... In any case, the actual authentication token is plaintext.

Comment Re:Nothing changes... (Score 3, Informative) 341

Windows does the same thing. Does it automatically connect to Wifi when it boots?

We can store them in an exotic form of plaintext, like encrypted with the encryption key in /var, so you can use the encryption key to read the plaintext but we can claim it's "stored encrypted" even though this doesn't add security.

Comment Re:And the problem is? (Score 1, Informative) 341

If the system stores an encryption key and a password, it's storing plaintext in an exotic format. If the system is capable of extracting the plaintext without user intervention, then it's storing plaintext in an exotic format. If it's OpenSSL encrypted, and the OpenSSL key is RIGHT THERE NEXT TO IT, it's in plaintext.

Comment Re:That's why Liux isn't 1st choice for security.. (Score 4, Informative) 341

If you want the system to use a wifi connection as its primary--to boot and enable wifi, or to allow all users to enable wifi--the wifi connection must store the password in plaintext.

Think like this: You get a wire, plug in an RJ-45, and tell the system to enable that on boot. When you boot, you're online.

Now, if you use wifi, to do this, you have two options. The first is for a user to log in, connect to wifi, and store the password encrypted in keyring. The next user logs in (after the first logs off, or after a reboot) and, not knowing the password, can't use the network on that machine. The second option is to store that password in plaintext, accessible by a system level service (or, alternately, by all users). At boot, the system service enables the network connection; any user with access rights to enable or disable the network connection can send a message to the service to do so, and the service will read the password from disk.

In the second scenario, if you create an encryption key and encrypt the password, you need to store the key in plaintext. An attacker would get the key and use it to decrypt the password in the same way as he'd obtain the plaintext password, so technically you are still storing plaintext--just in a different format involving multiple files. It's not encrypted until it's separated from the key. An encrypted e-mail is encrypted because only the sender and recipient have the key--the sender usually generates a session key and encrypts that with a public key, so usually no longer has the key after sending it. A third party would have an encrypted blob and no key. If you encrypted the e-mail and stored a private key to decrypt it on the same system, protected by a password stored in a text file on the same system, then administrative access gives you full access to everything--essentially, the message is stored in plaintext. That's a stretch; but if your system fundamentally functions such that it must store some data, and stores that data and an encryption key "to encrypt it", you're storing plaintext--the "encrypted" data is never transported, and the key is just theater.

So this isn't an example of poor security; it's an example of "the only way to accomplish this particular goal".

Comment Re:This just in, spy wants spy rules to stay (Score 1) 316

Not really. What else did the CIA give bush? Briefings on 3000 other terrorist attacks just about to happen, from 250 other terrorist groups in 87 countries? All that intelligence is like an oil field and you're looking for that one quart of oil that's going to burn ultra-hot because of its unique composition. One day it ignites while you're sucking it out of the ground and the rig blows up, and people are like, "There were so many warning signs, the equipment was groaning, it was out of maintenance, some drills had failed, engineers on the team had warned that this could happen..." and what really happened was a piece of sulfated rock came up in the oil that day, and would have ignited a brand-new, inspected, perfectly functional rig anyway, and we've NEVER had a piece of sulfated rock cause a fire like that so nobody could have possibly predicted that could be an actual thing.

Comment Re:This just in, spy wants spy rules to stay (Score 0) 316

Worse, he's right: people don't understand what's happening and believe anything under stress. I could rant, but I'll just point at some barely coherent brown kid who sounds nutty but really knows what he's talking about. Try not to go too far out on this stuff, but ... yeah, he has a point.

Slashdot Top Deals

Real Programmers don't eat quiche. They eat Twinkies and Szechwan food.

Working...