The advantage is that many people use the same password on multiple systems, so revealing a plaintext password to, say, Slashdot may also reveal your bank password. A hashed password can't be used to directly log into another account, though it can be cracked by a determined attacker if the password is simple. A salted and hashed password vastly increases the time required for an attacker to crack a hashed password, to the point where it is infeasible unless the password is very simple.
Of course everybody knows (or should know) that using the same password for Slashdot and your bank is a bad idea (you could have a bank support rep using up your precious karma!), but it is still very common, and it's irresponsible for a developer to expose their users' passwords if they have made this common mistake.
RAM of a running process is accessible to root via the debugger, so doesn't really provide better security than a file only root can read, although it may slow an attacker down a bit or foil a dim-witted attacker. As others have mentioned, there is also some systems management difficulty if services do not function until a password is entered into them.
At any rate, lots of interesting schemes are possible, but I was wondering if any of them were in wide use?
Most applications I've worked with have stored passwords hashed and salted and stored credit card data offsite or not at all, but have kept other sorts of personal data (address, phone, etc.) in the database in plaintext.
I've always reasoned that encrypting the data is of little value, since the decryption keys would have to be on the server, and a server compromise would give the keys along with the data. This case is interesting though, since it seems only the database was compromised, so encrypted data in the database with keys outside of the database would have provided some protection.
I can come up with lots of simple schemes for encrypting personal data in the database, but what I'm wondering is, how is this typically handled? Is it common to encrypt this sort of data? If so using what techniques for encryption and key management? Are there some well-known best practices that I haven't come across?
Does this release include installer support for software RAID? I've been waiting for that for awhile; the elaborate dance to convert a system to RAID after installation is getting old.:-)
That works if you have a copy of the application, su, some version of/etc/passwd, and all of the libraries needed by both programs inside the chroot area. To avoid that, you can use chroot_safe, which is a clever LD_PRELOAD hack to start the program, load all shared libraries, then do the chroot. For many programs, this is enough to make it work without copying anything into the chroot area.
It's very handy; I use it for all sorts of things.
We used to use a Solid SQL database a few years back, before I really knew anything about databases or SQL. It was extremely reliable, fast enough for everything we did, and very easy to administer (even for people who didn't know anything about databases or SQL). I haven't used it recently, but if their technology is still top-notch, this will be very good news.
and cheap GE radios ("GE 7-2664 AM/FM Portable Radio", about $11 from Amazon). Just took about an hour to set up, and works without any problems through our whole house.
Now you won't the same sound quality sending your CD out over FM as you would sending it directly to speakers, but to me the sound quality is fine.
Re:I'll stick with OpenBSD and Trusted Solaris.
on
Hardening Linux
·
· Score: 2, Interesting
You know, the thing that's been keeping me on Linux lately is Debian's apt. I've gotten addicted to the ease of keeping Debian systems up-to-date, especially since I'm responsible for about a dozen systems in different locations and don't have much time to take care of them. I found that when I maintained Solaris systems, package management was a pain, and I procrastinated updating things because it was time-consuming and sometimes broke things. On OpenBSD, recompiling everything from ports seems time-consuming and error prone, especially with a large update (like X). Plus I like being able to use debsums to track checksums on everything I've installed, and have it tell me if any of my executables have changed; sort of a poor-man's tripwire.
On the other hand, it's been a while since I took a look. Has package management gotten better on Solaris or OpenBSD, to the point where I can keep a system up-to-date with about 1 minute a week of my attention?
I keep hoping somebody will package a Debian OpenBSD. That's something I'd use in a heartbeat, if it were well-maintained.
I have a Timberland laptop backpack that my wife bought 5 years ago for law school. When she finished with it I used it for grad school, and now I use it for work. It regularly has a laptop in it along with a few textbooks, and it's still in great shape. It's also quite nice looking, holds a lot of stuff, and isn't obviously a laptop bag.
Rebate forms aren't hard to come by; you can usually download them from the manufacturer's Web site. The proof-of-purchase is the receipt and usually a UPC from the box. And anyways, it's not reasonable to refuse to accept a return if the customer can't prove they didn't send the rebate in; what if they immediately sent in the rebate, then found the item didn't perform as expected?
Rebates, as compared to simply lowering the price, are designed to take advantage of people who will forget to fill out the forms, or who will make an error in doing so. Perhaps stores and manufacturers who try to take advantage of consumers in this way shouldn't be surprised when consumers try to take advantage back...
None. But to me, having the source code to the system that was used and a properly setup system of computers qualifies as independently verifiable, and recounting the record on a hard disk would seem as reliable to me as recounting the record of paper ballots. Knowing that the computer "followed procedure" and that the procedure is sound is as good as knowing that election workers followed a sound procedure.
The disadvantage of paper ballots as a backup for an electronic system is that it requires two systems to run in parallel. I think if we're going to have paper ballots be the true standard of voting, we should just use technology to make them easier to use. Make sure they can be read by OCR, and either have a computer help the voter fill out a paper ballot or have the voter fill it out in some other way, then have a computer show them how it reads their vote. That way a voter would know right away if their vote was going to be miscounted, and request a new ballot.
Of course, paper ballots make remove voting impossible, but maybe that's a good thing.:)
Assuming that the sample is truly random, it seems like the odds of that working would be pretty good, although of course whenever you do random sampling there's a chance that you could just happen to miss the bad machines. It may be a hard sell to tell somebody "there's only a 5% chance that your election results will be wrong", though.
And even if you can get the odds of broken or malicious code affecting the election's outcome down to an acceptable level, this still strikes me as a dangerous proposition. As far as I'm concerned, it's exactly equivalent to hiring a company to run the elections in secret, then just checking a few precincts to make sure the company didn't cheat. Maybe this system would have a high probability of working, but why would you want it, when you could just have them do their work in the open?
What disadvantage do you perceive in requiring that voting systems have source code available for public scrutiny, just as current election procedures are?
Data integrity can be dealt with with CRCs, digital signatures, and other standard mechanisms. It's logic errors that require open source.
As for verifying the integrity of the software, if you have a CD with the software, for example, then you can establish a public procedure that can be verified. The city clerk takes a CD out of a box, verifies the digital signature, makes copies for election workers; the workers take it to the polling places, put one in each machine, and fire them up. Machines can be purchased from any computer supplier, and their operation can be verified, just like existing equipment is purchased from suppliers and the operation verified. Everything happens in the public eye. I would personally be willing to trust this system.
That said, the only disadvantage I can think of for paper ballots is that they're expensive to deal with. They have to be hauled around, kept on file for a while, etc. Completely electronic ballots would allow the same job to be done with fewer workers, and using both electronic and paper ballots would require two independent systems for dealing with correctness and privacy. Maybe it would be better to only use paper ballots, and just use technology to make them clearer---for example using ScanTron votes with the bubbles next to the candidate's name instead of punchcards.
If a paper+electronic system were used, the electronic version would still need to be verifiable and open; otherwise if it counted votes incorrectly there would be no way of knowing. If it drastically miscounted, nobody would bother with a recount. Alternatively, if trust in the machines was very low, recounts would always be requested, and there would be no point to using an electronic system.
That's an interesting point, but the paper ballots are counted in public by public officials following rules created by your state legislature. For elections in Michigan, anybody who wants can observe the election procedure, and can complain if they think it's done poorly; I'd imagine you could do something similar to monitor a vote recount.
The difference here is that the electronic ballots are tallied in secret by secret software written by a private company, with no observation allowed.
For electronic voting to work, it's going to need to use completely open software, where many experts can verify that it will work properly. Since so many people have an interest in the system working perfectly, there will be lots of people reviewing the code, and I think that very few serious bugs would be there for long.
verifiedvoting.org is advocating this same position. I'm not sure if they're actually writing software.
No, we actually got about 3 feet out of Alien, but our antenna was bad (the cable connector was damaged). Their technology is about the same as Matrics, so I assumed the range would be similar if we had a working antenna.
We have gotten 9-12 feet out of Matrics, with their 4" tags.
It depends on whose computers they are. 18 USC 2332 (b), as modified by the Patriot act, defines terrorism as:
(5) the term ''Federal crime of terrorism'' means an offense that -
(A) is calculated to influence or affect the conduct of government by intimidation or coercion, or to retaliate against government conduct; and
(B) is a violation of... 1030(a)(1) (relating to protection of computers), 1030(a)(5)(A)(i) resulting in damage as defined in 1030(a)(5)(B)(ii) through (v) (relating to protection of computers),
(5)(A)(i) knowingly causes the transmission of a program, information, code, or command, and as a result of such conduct, intentionally causes damage without authorization, to a protected computer;
(ii) intentionally accesses a protected computer without authorization, and as a result of such conduct, recklessly causes damage; or
(iii) intentionally accesses a protected computer without authorization, and as a result of such conduct, causes damage;...
(B) by conduct described in clause (i), (ii), or (iii) of subparagraph (A), caused (or, in the case of an attempted offense, would, if completed, have caused) -
(i) loss to 1 or more persons during any 1-year period (and, for purposes of an investigation, prosecution, or other proceeding brought by the United States only, loss resulting from a related course of conduct affecting 1 or more other protected computers) aggregating at least $5,000 in value;
The courts have been very liberal in how they define damages to computers; shutting down a government department for a few hours would easily meet this criteria.
So if they're the government's and you say "do this thing or else I'll DDOS your computers", it's definitely terrorism.
The interesting question is, under this law, would it be terrorism for me to say "Senator Levin (our excellent senator from Michigan), if you don't vote against DMCA II, I'm going to have all of my friends email your office" if doing that results in crashing their mail server, forcing them to buy a new one for more than $5K? I guess ambiguities like that are what you end up with when you write a several hundred page law in a few days, as the Patriot act was written.
Mostly good information, but you're wrong about range. I've got a Matrics and Alien EPC RFID reader on my desk at work, and the range I've measured is 9-12 feet. The advertised range is 15-20 feet. Alien and Matrics are the two big players, and both advertise about this range. You can see a comparison grid for popular readers on buyrfid.com.
You may not have anything to hide, but lots of people do, and for legitimate reasons. That's why we have basic privacy rights. Consider an employer that places a tag reader in their entranceway and tells nobody. They could find out:
About an employee who has brought in a copy of "Union Organizing for Dummies".
About the drugs employees take, which could prompt them to fire employees with diseases that are likely to prove expensive to them, like cancer or AIDS, or with emotional problems, like depression.
About a closeted gay employee who has a copy of The Advocate in their briefcase to read during lunch.
The type of underwear the secretary from the 4th floor wears.
That you've recently purchased condoms, tampons, or other private items.
That Steve from accounting wears womens underwear
Don't you agree that an employee has a right to keep all of these things private?
And sure, some workplaces search bags now, but they can't search your bag without you knowing about it; you simply wouldn't bring private items in from your car if you knew they might be searched.
The privacy fears of RFID may be overblown, but there are definitely some real concerns.
The EPC tags Wal-Mart is using can only be read for about 20 feet, not half a mile. The only tags with longer range are "active tags", with batteries, and they're quite expensive (around $20, compared to $1 for the tags Wal-Mart is using).
It's possible range will increase somewhat, but probably not much. The tags have very limited energy available to broadcast their response, and in order to collect enough RF energy to send it more than a few yards, they would have to be very very big tags.
You just download it and follow the instructions. It takes about 5 minutes to compile and an hour or two to read through the documentation and install it (much faster if you've done it before). At the end of it, you understand how the system works fairly well. Postfix/Exim might be faster to set up initially, but if you don't read through the docs while you're doing it, you'll end up having to read them the first time a problem comes up. My guess is that the total amount of time to set up and run any of these systems for, say, a year is about the same.
The nice thing about qmail is it has a very modular design, and you can easily remove parts and replace them or layer them together. It might be a little harder to get the hang of than editing a config file, but it's very flexible and powerful.
I know that you already know this, but you can't; DJB's annoying choice of license forbids distributing qmail binaries built from modified sources. Instead, you simply download the source and compile it. It takes about 5 minutes on modern hardware.
If you have a strong preference for RPMs, you can use an existing.spec file to build your own, then use that within your organization.
Slashdot Mirror
Yes, thanks for the clarification, it only increases the time by preventing the use of rainbow tables (or, nowadays, simply googling the hash).
The advantage is that many people use the same password on multiple systems, so revealing a plaintext password to, say, Slashdot may also reveal your bank password. A hashed password can't be used to directly log into another account, though it can be cracked by a determined attacker if the password is simple. A salted and hashed password vastly increases the time required for an attacker to crack a hashed password, to the point where it is infeasible unless the password is very simple.
Of course everybody knows (or should know) that using the same password for Slashdot and your bank is a bad idea (you could have a bank support rep using up your precious karma!), but it is still very common, and it's irresponsible for a developer to expose their users' passwords if they have made this common mistake.
RAM of a running process is accessible to root via the debugger, so doesn't really provide better security than a file only root can read, although it may slow an attacker down a bit or foil a dim-witted attacker. As others have mentioned, there is also some systems management difficulty if services do not function until a password is entered into them.
At any rate, lots of interesting schemes are possible, but I was wondering if any of them were in wide use?
Thanks,
------Scott.
Most applications I've worked with have stored passwords hashed and salted and stored credit card data offsite or not at all, but have kept other sorts of personal data (address, phone, etc.) in the database in plaintext.
I've always reasoned that encrypting the data is of little value, since the decryption keys would have to be on the server, and a server compromise would give the keys along with the data. This case is interesting though, since it seems only the database was compromised, so encrypted data in the database with keys outside of the database would have provided some protection.
I can come up with lots of simple schemes for encrypting personal data in the database, but what I'm wondering is, how is this typically handled? Is it common to encrypt this sort of data? If so using what techniques for encryption and key management? Are there some well-known best practices that I haven't come across?
Thanks!
----Scott.
Does this release include installer support for software RAID? I've been waiting for that for awhile; the elaborate dance to convert a system to RAID after installation is getting old. :-)
That works if you have a copy of the application, su, some version of /etc/passwd, and all of the libraries needed by both programs inside the chroot area. To avoid that, you can use chroot_safe, which is a clever LD_PRELOAD hack to start the program, load all shared libraries, then do the chroot. For many programs, this is enough to make it work without copying anything into the chroot area.
It's very handy; I use it for all sorts of things.
I've used the Eclipse Test & Performance Tools Platform with pretty good results:
i ling-Tool/tptpProfilingArticle.html
http://www.eclipse.org/articles/Article-TPTP-Prof
We used to use a Solid SQL database a few years back, before I really knew anything about databases or SQL. It was extremely reliable, fast enough for everything we did, and very easy to administer (even for people who didn't know anything about databases or SQL). I haven't used it recently, but if their technology is still top-notch, this will be very good news.
I did exactly this, and we've been very happy with it. I used a "Whole House FM Transmitter" from:
http://www.my-radio-station.com/
and cheap GE radios ("GE 7-2664 AM/FM Portable Radio", about $11 from Amazon). Just took about an hour to set up, and works without any problems through our whole house.
Now you won't the same sound quality sending your CD out over FM as you would sending it directly to speakers, but to me the sound quality is fine.
You know, the thing that's been keeping me on Linux lately is Debian's apt. I've gotten addicted to the ease of keeping Debian systems up-to-date, especially since I'm responsible for about a dozen systems in different locations and don't have much time to take care of them. I found that when I maintained Solaris systems, package management was a pain, and I procrastinated updating things because it was time-consuming and sometimes broke things. On OpenBSD, recompiling everything from ports seems time-consuming and error prone, especially with a large update (like X). Plus I like being able to use debsums to track checksums on everything I've installed, and have it tell me if any of my executables have changed; sort of a poor-man's tripwire.
On the other hand, it's been a while since I took a look. Has package management gotten better on Solaris or OpenBSD, to the point where I can keep a system up-to-date with about 1 minute a week of my attention?
I keep hoping somebody will package a Debian OpenBSD. That's something I'd use in a heartbeat, if it were well-maintained.
Information from the MUSCLE smartcard-on-Linux project be useful:
http://www.linuxnet.com/
I have a Timberland laptop backpack that my wife bought 5 years ago for law school. When she finished with it I used it for grad school, and now I use it for work. It regularly has a laptop in it along with a few textbooks, and it's still in great shape. It's also quite nice looking, holds a lot of stuff, and isn't obviously a laptop bag.
Rebates, as compared to simply lowering the price, are designed to take advantage of people who will forget to fill out the forms, or who will make an error in doing so. Perhaps stores and manufacturers who try to take advantage of consumers in this way shouldn't be surprised when consumers try to take advantage back...
That would work if a law were passed requiring this, and if everybody followed the law. I'm not sure how likely either of those are.
None. But to me, having the source code to the system that was used and a properly setup system of computers qualifies as independently verifiable, and recounting the record on a hard disk would seem as reliable to me as recounting the record of paper ballots. Knowing that the computer "followed procedure" and that the procedure is sound is as good as knowing that election workers followed a sound procedure.
The disadvantage of paper ballots as a backup for an electronic system is that it requires two systems to run in parallel. I think if we're going to have paper ballots be the true standard of voting, we should just use technology to make them easier to use. Make sure they can be read by OCR, and either have a computer help the voter fill out a paper ballot or have the voter fill it out in some other way, then have a computer show them how it reads their vote. That way a voter would know right away if their vote was going to be miscounted, and request a new ballot.
Of course, paper ballots make remove voting impossible, but maybe that's a good thing. :)
Assuming that the sample is truly random, it seems like the odds of that working would be pretty good, although of course whenever you do random sampling there's a chance that you could just happen to miss the bad machines. It may be a hard sell to tell somebody "there's only a 5% chance that your election results will be wrong", though.
And even if you can get the odds of broken or malicious code affecting the election's outcome down to an acceptable level, this still strikes me as a dangerous proposition. As far as I'm concerned, it's exactly equivalent to hiring a company to run the elections in secret, then just checking a few precincts to make sure the company didn't cheat. Maybe this system would have a high probability of working, but why would you want it, when you could just have them do their work in the open?
What disadvantage do you perceive in requiring that voting systems have source code available for public scrutiny, just as current election procedures are?
Data integrity can be dealt with with CRCs, digital signatures, and other standard mechanisms. It's logic errors that require open source.
As for verifying the integrity of the software, if you have a CD with the software, for example, then you can establish a public procedure that can be verified. The city clerk takes a CD out of a box, verifies the digital signature, makes copies for election workers; the workers take it to the polling places, put one in each machine, and fire them up. Machines can be purchased from any computer supplier, and their operation can be verified, just like existing equipment is purchased from suppliers and the operation verified. Everything happens in the public eye. I would personally be willing to trust this system.
That said, the only disadvantage I can think of for paper ballots is that they're expensive to deal with. They have to be hauled around, kept on file for a while, etc. Completely electronic ballots would allow the same job to be done with fewer workers, and using both electronic and paper ballots would require two independent systems for dealing with correctness and privacy. Maybe it would be better to only use paper ballots, and just use technology to make them clearer---for example using ScanTron votes with the bubbles next to the candidate's name instead of punchcards.
If a paper+electronic system were used, the electronic version would still need to be verifiable and open; otherwise if it counted votes incorrectly there would be no way of knowing. If it drastically miscounted, nobody would bother with a recount. Alternatively, if trust in the machines was very low, recounts would always be requested, and there would be no point to using an electronic system.
That's an interesting point, but the paper ballots are counted in public by public officials following rules created by your state legislature. For elections in Michigan, anybody who wants can observe the election procedure, and can complain if they think it's done poorly; I'd imagine you could do something similar to monitor a vote recount.
The difference here is that the electronic ballots are tallied in secret by secret software written by a private company, with no observation allowed.
For electronic voting to work, it's going to need to use completely open software, where many experts can verify that it will work properly. Since so many people have an interest in the system working perfectly, there will be lots of people reviewing the code, and I think that very few serious bugs would be there for long.
verifiedvoting.org is advocating this same position. I'm not sure if they're actually writing software.
We have gotten 9-12 feet out of Matrics, with their 4" tags.
18 USC 1030a refines this:
The courts have been very liberal in how they define damages to computers; shutting down a government department for a few hours would easily meet this criteria.
So if they're the government's and you say "do this thing or else I'll DDOS your computers", it's definitely terrorism.
The interesting question is, under this law, would it be terrorism for me to say "Senator Levin (our excellent senator from Michigan), if you don't vote against DMCA II, I'm going to have all of my friends email your office" if doing that results in crashing their mail server, forcing them to buy a new one for more than $5K? I guess ambiguities like that are what you end up with when you write a several hundred page law in a few days, as the Patriot act was written.
Mostly good information, but you're wrong about range. I've got a Matrics and Alien EPC RFID reader on my desk at work, and the range I've measured is 9-12 feet. The advertised range is 15-20 feet. Alien and Matrics are the two big players, and both advertise about this range. You can see a comparison grid for popular readers on buyrfid.com.
Don't you agree that an employee has a right to keep all of these things private?
And sure, some workplaces search bags now, but they can't search your bag without you knowing about it; you simply wouldn't bring private items in from your car if you knew they might be searched.
The privacy fears of RFID may be overblown, but there are definitely some real concerns.
The EPC tags Wal-Mart is using can only be read for about 20 feet, not half a mile. The only tags with longer range are "active tags", with batteries, and they're quite expensive (around $20, compared to $1 for the tags Wal-Mart is using).
It's possible range will increase somewhat, but probably not much. The tags have very limited energy available to broadcast their response, and in order to collect enough RF energy to send it more than a few yards, they would have to be very very big tags.
The nice thing about qmail is it has a very modular design, and you can easily remove parts and replace them or layer them together. It might be a little harder to get the hang of than editing a config file, but it's very flexible and powerful.
I know that you already know this, but you can't; DJB's annoying choice of license forbids distributing qmail binaries built from modified sources. Instead, you simply download the source and compile it. It takes about 5 minutes on modern hardware.
If you have a strong preference for RPMs, you can use an existing .spec file to build your own, then use that within your organization.