Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Government Security Your Rights Online

Voting System Test Hack Elects Futurama's Bender To School Board 210

mr crypto writes with this quote from El Reg: "In 2010 the Washington DC election board announced it had set up an e-voting system for absentee ballots and was planning to use it in an election. However, to test the system, it invited the security community and members of the public to try and hack it three weeks before the election. 'It was too good an opportunity to pass up,' explained Professor Alex Halderman from the University of Michigan. 'How often do you get the chance to hack a government network without the possibility of going to jail?' With the help of two graduate students, Halderman started to examine the software. Despite it being a relatively clean Ruby on Rails build, they spotted a shell injection vulnerability within a few hours. They figured out a way of writing output to the images directory (PDF) on the compromised server, and of encrypting traffic so that the front-end intrusion detection system couldn't spot them. The team also managed to guess the login details for the terminal server used by the voting system. ... The team altered all the ballots on the system to vote for none of the nominated candidates. They then wrote in names of fictional IT systems as candidates, including Skynet and (Halderman's personal favorite) Bender for head of the DC school board."
This discussion has been archived. No new comments can be posted.

Voting System Test Hack Elects Futurama's Bender To School Board

Comments Filter:
  • At least (Score:5, Insightful)

    by stillpixel ( 1575443 ) on Friday March 02, 2012 @11:40AM (#39221217) Homepage Journal
    the election board had the common sense to ask for this publicly and not cross their fingers and hope no one did this when they used it for real. More gov't entities should open up to testing like this.
    • Re:At least (Score:4, Insightful)

      by ackthpt ( 218170 ) on Friday March 02, 2012 @11:56AM (#39221411) Homepage Journal

      the election board had the common sense to ask for this publicly and not cross their fingers and hope no one did this when they used it for real.

      More gov't entities should open up to testing like this.

      Sure, but if you run Diebold and favor one party over another (justsayin') you don't want some hacker finding your backdoor, do you?

      • Re: (Score:2, Insightful)

        by Anonymous Coward

        Off course, with paper, you can simply walk in after the fact with boxes full of votes for you guy or gal ( Washington gov and Minnesota Sen, right?)

        • Re:At least (Score:5, Informative)

          by Anonymous Coward on Friday March 02, 2012 @01:25PM (#39222547)

          The protocol for a proper paper ballot vote is not vulnerable in that way. It goes like this:

          On the morning of the election day, observers of all parties and interested citizens witness the sealing of empty ballot boxes. The ballot boxes don't leave the room, and enough observers to prevent collusion must be present at all times.

          The election is carried out with observers of all parties watching to confirm that only people eligible to vote put one ballot each into the ballot box.

          At the end of the day, the ballots are counted under the eyes of observers of all parties. The result is signed by all observers, each observer makes a note of the result and the signed result is posted locally. The result is relayed upward, where all local results are posted again together with the aggregate result.

          This protocol ensures that no single entity can change a number without other interested parties having the opportunity to notice the manipulation.

          This protocol is simple enough that no expertise is necessary to memorize it, understand why it works, and verify that it is followed correctly. It is the only protocol with these important properties.

          • Re:At least (Score:5, Insightful)

            by rtfa-troll ( 1340807 ) on Friday March 02, 2012 @02:17PM (#39223279)

            This protocol is simple enough that no expertise is necessary to memorize it, understand why it works, and verify that it is followed correctly.

            This can't be stated strongly enough. If there is any part of this that can't be understood by retired clerk without higher education and with no real interest in mathematics and/or computing then you are getting rid of some of the most important volunteers who can ensure that the voting goes correctly.

          • by mcgrew ( 92797 ) *

            Someone please mod the parent AC up so his insightful comment will be seen. How he describes the process is exactly how it works.

          • by AK Marc ( 707885 )

            The protocol for a proper paper ballot vote is not vulnerable in that way.

            The protocol is invulnerable. The people executing the protocol aren't perfect, so in practice, real security on a well-designed e-ballot system greatly exceeds the current paper system.

            • Re:At least (Score:5, Insightful)

              by Pumpkin Tuna ( 1033058 ) on Friday March 02, 2012 @04:05PM (#39225069)

              I disagree. The key is that equal numbers of representatives from both parties are part of the process and essentially watch each other for cheating. I've run a polling place for several years now as chief judge, and I've seen no way that I could have cheated, even though I transported the paper ballots to the board of elections by myself in my own car. There were too many failsafes. It actually made me feel very good about our democracy. You can't say the same for some code, no matter how secure it is. Security can always be broken.

              • You see no way, it doesn't mean someone else couldn't find a way, or through some unforseen number of circumstances be able to collude with others.

                For a year I was one of 4 people that hired the election judges and alternates for a very large county in Texas (technically we suggested the judges to the party leaders which 99% of the time would accept our recommendation). We discovered an early voting election judge was voting for their preferred candidate once per day. One day he got unlucky and a clerk sa
                • by laird ( 2705 )

                  Physical voting is not immune from error and malice, but it DOES limit the ability to do damage, because one person can only affect a very small number of votes, and it's possible to audit to detect them, and recount to correct them.

                  In the example that you give of a judge sneaking in putting in an extra vote every day, I'll point out that the impact was only a few votes, and he got caught. It's unfortunate that he wasn't prosecuted, but hopefully the humiliation will serve as a deterrent. I'll also point ou

          • by davide marney ( 231845 ) on Friday March 02, 2012 @03:50PM (#39224833) Journal

            It is the only protocol with these important properties.

            That is incorrect. I am a poll worker in Virginia, and we follow a very similar protocol for our DRE voting machines. We run the machines through a double-blind test prior to the vote, under the observation of multiple parties, and then we seal them. During the vote, the machines are kept in the open and observed by multiple parties. Each hour, the total votes cast are compared to the total voters allowed into the polling place, and the results called in my phone, and independently recorded, by the Registrar. At the end of the voting day, the vote totals are printed on paper, called into the Registrar by phone, and then aggregated by the State Board of Election. We then transfer the totals in ink onto a separate report, make a backup copy of the database, seal our report and the machines, and deliver them to the Registrar. The sealed reports and backup data go to the local courthouse, where they are locked away until the vote is certified.

            In order to defeat our system, you would have to do it in the open, under the (very) watchful gaze of multiple parties both partisan and neutral, and you would have to do it in a way that did not change the total number of votes cast. I'm not saying it's impossible, but it would be really, really hard.

            I have been volunteering for many years, know a thing or two about machine security, and am very confident that we run a clean, fair, and open election with results that are far better than a paper ballot count. If I had a choice between a paper and a machine/electronic balloting process, I would never choose to use paper. Paper is an awful medium for counting. You may have noticed that places where counting is important -- like banks -- paper is no longer used. There's a reason for that!

            • by laird ( 2705 ) <lairdp&gmail,com> on Friday March 02, 2012 @08:41PM (#39228209) Journal

              "I am a poll worker in Virginia, and we follow a very similar protocol for our DRE voting machines. "

              While it sounds like you're trying to do a good job, there are many fundamental problems with DRE machines.

              - The software is proprietary, and not open to inspection, only to "black box" testing, which cannot only detect some kinds of errors, and cannot be counted on to detect all errors or intentional fraud.
              - There is no way to prove that the vote recorded by the DRE is the same as the vote cast. The lack of voter verification of the actual recorded vote is the fundamental problem with DREs, rendering them unsuitable for use in elections. Note that printing a record of the vote within the machine does not help, because the receipt inside the machine is not verified by the voter, so there's no way to validate that it reflects actual votes cast, so it cannot be used as the basis of an audit or recount.
              - There is no way to prove that the vote recorded by the DRE cooresponds to the votes reported.
              - There is no way to audit reported vote counts against actual votes cast, so no way to discover fraud or error in the voting system.
              - There is no way to recount actual votes cast by voters. You can recount whatever the software happened to record, but that can easily be different from the vote cost.

              Or, as NIST put it "Simply put, the DRE architecture’s inability to provide for independent audits of its electronic records makes it a poor choice for an environment in which detecting errors and fraud is important."

              There are advantages the electronic voting systems, such as providing immediate voter feedback to prevent overvoting and warning of undervoting, and assisting seeing impaired voters.

              The right way to go, I believe, is to use electronic voting systems to assist voters in producing a paper ballot (AKA the Voter Verified Paper Ballot), which the voter can then inspect and cast. That gives the advantages of a DRE, but with the added benefit that the election results can be (relatively) trusted. That is, for example, the type of system used in Nevada after the Gaming Commission rejected all of the DRE systems. This is particularly relevant, because they're the only state with significant experience in securing DRE-like devices, because they certify gambling machines, which are under similar attacks to DREs.

              Check out http://www.openvotingconsortium.org/ [openvotingconsortium.org] for an open source system that does the right thing.

      • Yep true, so we use the phrase on Gov't that they like to throw at us. "If you have nothing to hide, then you'll have no problem with us taking a look." (paraphrased)
    • Most are weasels that are afraid that they will be exposed for their lack of knowledge. So don't pray for it, though it should be like that by law.
    • Re:At least (Score:4, Insightful)

      by kbob88 ( 951258 ) on Friday March 02, 2012 @12:30PM (#39221777)

      I agree. Asking the community to test the system out does show remarkable common sense and good intentions, which seems to be lacking in e-voting community.

      Unfortunately, they did not have the common sense (or perhaps judgement) to hire a technical team that knew what they were doing when comes to security. Which is not good in any project, but seems like a huge lapse of judgement in an e-voting project.

      They also appear not to have hired an independent security review group to scan the code and review the implementation, or if they did hire one, they hired one that was no good.

      • by Ihmhi ( 1206036 )

        With a challenge like this, the security community does the security testing for free.

      • by chinakow ( 83588 )
        If common sense is lacking in the e-voting community, is it actually 'common'?
      • Re:At least (Score:4, Insightful)

        by rtfa-troll ( 1340807 ) on Friday March 02, 2012 @02:10PM (#39223155)

        They also appear not to have hired an independent security review group to scan the code and review the implementation, or if they did hire one, they hired one that was no good.

        It's explicitly stated in the summary, let alone the article that this was a good system with a clean Ruby set up. That is more or less "state of the art security". If we take the lesson that this was a "bad" team and that most others would do better we would be deeply wrong. There were IDSis systems and filters in place. That a considerably higher level of protection and a sign of a higher level of security awareness than most competing systems.

        The main message is that the currernt state of the art doesn't come close to providing decent security. Even key military systems have been showing a bunch of failures such as the Windows based battleship propulsion system. That shows that people who know how to build secure systems don't know how to build reasonable sized / commercial systems and are losing in competitive battles to cowboys using completely unsuitable technologies.

      • by M1FCJ ( 586251 )

        I wonder if I smell a rat. By discrediting the voting system so close to an election they can either discourage people from voting or open it to challenges later on, especially if it goes the other way from what they want or, finally, parachute an expensive, closed-source system by simply stating "this one stinks, here's a proper commercial system" (Diebold anyone?)...

    • I don't know. Giving people 3 weeks to try to pull this off? Seems to me like they were trying to stack the odds in their favor.

      Maybe they wanted to give an appearance of oppenness, assuming no one could get it done in that short of a time, and it backfired on them a bit. They can still fall back on the openness angle.

  • Why... (Score:5, Funny)

    by Daniel_is_Legnd ( 1447519 ) on Friday March 02, 2012 @11:42AM (#39221239)
    Why not Zoidberg?
  • Bender (Score:2, Informative)

    by rwise2112 ( 648849 )
    Bite my shiny metal ass!
  • by bunratty ( 545641 ) on Friday March 02, 2012 @11:43AM (#39221247)
    If elected I promise to KILL ALL HUMANS! Hey, you said there'd be hookers at this convention.
  • by chemicaldave ( 1776600 ) on Friday March 02, 2012 @11:44AM (#39221257)

    If you read the article, they didn't even have to guess really. The default root password for the HTTP admin interface was left intact. They then downloaded the etc/passwd file and cracked it in only 3.5 hours because, surprise surprise, the secondary administrator password was piss poor "cisco123"

    Seriously. Who hired these clowns?

    • by Desler ( 1608317 ) on Friday March 02, 2012 @11:48AM (#39221309)

      This was a system created by Rubyists. They don't understand security because that's a "low-level detail" they can't be arsed to learn.

      • by Anonymous Coward on Friday March 02, 2012 @11:58AM (#39221445)

        Indeed.

        Ruby does a lot of things, but encouraging security isn’t one of them. Building a properly secured application means thinking about security right from the beginning and working it in at the core levels. Upper level code shouldn't even be _able_ to do something insecure without some kind of token from the minimalist security layers at the base. A language designed to "handle that shit for you" leads to a lot of "oh, didn't think about that" type issues.

        See also: diaspora

        • Except this wasn't a failing in Ruby (or Rails). As TFA pointed out, the vulnerability had already been discovered and fixed. The problem was that the voting software was using a custom version of the library in question... based on an older, insecure version no less. While TFA mentions checking the file extension should help remedy the problem, doing something as simple as URL encoding the filenames would work as well (and prevent escape characters from popping up in the filename).

      • Well to be fair, the web developers and sysadmins owning the services the web developers use should be different people. They tend to have different skillsets.

      • Completely unrelated to the subject, our dev team has recently replaced portions of our product with a ruby implementation that has caused no end of problems. These folks that have managed to up our bug count by a factor of 3 and increase our feature-completion time by a factor of about 2. This has been going on for 8 months, and I'm simply ill-equipped to discuss this since I've not worked on the ruby code, or really picked it up myself yet. I'm convinced this isn't really a problem with ruby itself, bu

      • This was a system created by Rubyists. They don't understand security because that's a "low-level detail" they can't be arsed to learn.

        Rubyists pay attention to low-level details. This is why we write C extensions rather than executing shell commands from web applications, which is asinine.

        "Rails developers" are rarely Rubyists, properly speaking. This is one of the issues plaguing the Rails community. It could be worse, though. Rails developers can become Rubyists. In the PHP community, given that the preferred development methodology seems to be having two cats copulate on a keyboard, I don't hold much hope.

        • .. that the preferred development methodology seems to be having two cats copulate on a keyboard

          There is only one cat, it confuses people because it is both dead ... and alive.

        • by tibman ( 623933 )

          PHP 5 supports up to three cats now :)

        • by rev0lt ( 1950662 )

          This is why we write C extensions rather than executing shell commands from web applications, which is asinine.

          So what you're saying is that you rely on your own set of utilities developed in C, instead of using the tried-and-true, often secure and in some cases with more than one decade in deployment (as in -stable-) shell commands? And this is your counter-argument to why "rubyists" don't understand security?

    • Presumably you mean they cracked /etc/shadow. Still, piss poor is a good assessment for their attempts at securing this process. At least they opened it up for public testing though.
    • by jeffmeden ( 135043 ) on Friday March 02, 2012 @12:00PM (#39221471) Homepage Journal

      If you read the article, they didn't even have to guess really. The default root password for the HTTP admin interface was left intact. They then downloaded the etc/passwd file and cracked it in only 3.5 hours because, surprise surprise, the secondary administrator password was piss poor "cisco123"

      Seriously. Who hired these clowns?

      It gets even better. The guys attacking it decided to put in a *modicum* of security since there basically was none AT ALL... I can only hope that they actually wanted a really really really soft honeypot for this whole test, and that it wasn't just the E-voting system that they were testing. If it was, god help us all.

      We realized that one of
      the default logins to the terminal server (user: admin, password: admin) would
      likely be guessed by the attacker in a short period of time, and therefore decided
      to protect the device from further compromise that might interfere with the
      voting system test. We used iptables to block the offending IP addresses and
      changed the admin password to something much more difficult to guess. We later
      blocked similar attacks from IP addresses in New Jersey, India, and China.

  • by jizziknight ( 976750 ) on Friday March 02, 2012 @11:45AM (#39221281)
    "Have you ever tried simply turning off the TV, sitting down with your children, and hitting them?"
  • by Anonymous Coward on Friday March 02, 2012 @11:46AM (#39221289)

    Ruby on Rails

    And there's your problem. Only an idiot would try to run something that needs high security on Ruby on Fails. Rubyists couldn't write secure code if their life depended on it. Next time hire real programmers not hipsters who spend all day sipping lattes and admiring each other's new pair of skinny jeans.

    • by Anonymous Coward on Friday March 02, 2012 @11:52AM (#39221353)

      Ruby on Rails

      And there's your problem. Only an idiot would try to run something that needs high security on Ruby on Fails. Rubyists couldn't write secure code if their life depended on it. Next time hire real programmers not hipsters who spend all day sipping lattes and admiring each other's new pair of skinny jeans.

      Somewhere, in some coffee shop, some guy with a bowl cut and a faint mustache is commenting to his friend that he just got hired back to do another contract for the DC BOE and this time they want him to spend 4 hours on it instead of 2.

    • by kbob88 ( 951258 ) on Friday March 02, 2012 @12:19PM (#39221651)

      Nice troll. Actually, it's kind of a lame troll. I suppose, as is normal on /., you didn't read the report from Prof Halderman.

      The initial problem was a string interpolation vulnerability in a modified Ruby library that executes a shell command to encrypt PDF ballots. That's a pretty basic mistake that has nothing really to do with Ruby or Rails. If you interpolate into a string (or concatenate data into a string) without sanitizing the data, and then execute it, you're asking for trouble, no matter whether it's Rails or Java or C. This is also pretty basic security stuff, and there are tons of guidelines and tutorials in the Rails community for avoiding this kind of mistake. There are also plenty of code vulnerability scanners that would pick this up. It's amazing that the DC team didn't use one of these to check their code.

      But they had plenty of other problems such as easy-to-guess passwords and a lousy IDS configuration.

      So the real problem was with the people who developed and implemented the system, not with the tools. I've seen plenty of similar mistakes in systems developed using all sorts of technologies. The developers clearly didn't have a very solid background in security. That's OK actually, as long as you have someone on the project who does and who can check their designs and implementation. Sounds like they didn't have anyone well versed in security, which seems a bit odd for an e-voting project. I'm certainly no expert on security, but I am RoR coder, and even I know not to make these mistakes.

      But I suppose it's fun to bash the Rails programmers because they are in really high demand and able to command very high billing rates :-) I'll take the bashing along with the money and the ease of programming!

      • Re: (Score:3, Funny)

        by Anonymous Coward

        But I suppose it's fun to bash the Rails programmers because they are in really high demand and able to command very high billing rates :-)

        Yeah and we all believe you. No, really, we do. I'm sure the other unemployed Rubyists at Starbucks with you are congratulating you on this great post.

        • Re: (Score:2, Insightful)

          by Shados ( 741919 )

          I really hate Ruby, but its hard to ignore that there's a ton of Ruby shops hiring in the big north american metro areas and that they have more contracts than they can deal with right now. Ruby is pretty hot these days.

        • by kbob88 ( 951258 )

          Yeah, and I believe you. That's why I can't find any experience RoR developers to hire. Our recruiters can't find anyone either. They're all busy.

          • by Anonymous Coward on Friday March 02, 2012 @01:52PM (#39222947)

            Yeah, and I believe you. That's why I can't find any experience RoR developers to hire. Our recruiters can't find anyone either. They're all busy.

            We have the same issue! It took us six months before we were able to find a Senior RoR developer with 10 years experience.

      • by dgatwood ( 11270 ) on Friday March 02, 2012 @12:34PM (#39221817) Homepage Journal

        The initial problem was a string interpolation vulnerability in a modified Ruby library that executes a shell command to encrypt PDF ballots. That's a pretty basic mistake that has nothing really to do with Ruby or Rails. If you interpolate into a string (or concatenate data into a string) without sanitizing the data, and then execute it, you're asking for trouble, no matter whether it's Rails or Java or C.

        Not really. In C, you'd have gotten called an idiot within a few seconds if you used system() or popen(). Properly written C code using fork() and exec() does not require you to sanitize the string in any way.

        • by kbob88 ( 951258 )

          I think "properly written" is the key phrase there, which applies to any technology implementation.

          Ideally, they would have used the gpg libraries or gpgme and called it directly from the Ruby code. But that's harder, so they chose the easy way and got burned.

        • by icebraining ( 1313345 ) on Friday March 02, 2012 @12:55PM (#39222137) Homepage

          A simple search reveals that Ruby has fork() and exec() too. The problem is the "properly written" part.

        • I am neither a Ruby nor C developer.

          But question, assuming you are doing something like "exec(pdfparse($input))", and you dont sanitize your data, whats to stop someone from specifying the pdf file "somefile.pdf);rm -rf" as the file?

    • by Zedrick ( 764028 )
      Ruby (and RoR) is not hip anymore. This is 2012, not 2008. The hipsters have moved on to whatever, and those who remains are generally not worse than other coders.
  • by necro81 ( 917438 ) on Friday March 02, 2012 @11:53AM (#39221367) Journal
    Ya, well, I'm gonna go build my own election system. With blackjack! And hookers!

    In fact, forget the election system.
  • by Anonymous Coward on Friday March 02, 2012 @11:54AM (#39221383)

    Every single technology profession I have EVER communicated with, does not think electronic voting machines are a good idea. If EVERYONE is in agreement this is a BAD idea, why the FUCK are we still making these things?

    • by GmExtremacy ( 2579091 ) on Friday March 02, 2012 @11:57AM (#39221437)

      If EVERYONE is in agreement this is a BAD idea, why the FUCK are we still making these things?

      Because what is popular is not always correct.

    • by jeffmeden ( 135043 ) on Friday March 02, 2012 @12:02PM (#39221487) Homepage Journal

      Every single technology profession I have EVER communicated with, does not think electronic voting machines are a good idea. If EVERYONE is in agreement this is a BAD idea, why the FUCK are we still making these things?

      That's just it, we took a vote on that and as it turns out about 190% of respondents said that they were in favor of electronic voting...

    • Because it will be easier to hide voter fraud with electronic voting machines.
      • by AK Marc ( 707885 )
        We've had no lack of fraud in the 150 or so years since we abolished open voting. The "fix" is abolishing secret ballots, all fraud is based on the untracability we value higher than accuracy.
    • by Hentes ( 2461350 )

      Because the goal is not to build a secure system.

    • by Tackhead ( 54550 ) on Friday March 02, 2012 @12:24PM (#39221693)

      Every single technology profession I have EVER communicated with, does not think electronic voting machines are a good idea. If EVERYONE is in agreement this is a BAD idea, why the FUCK are we still making these things?

      Because neither politicians nor voters understand the concept of experimental error.

      And because in 2000, a Presidential election's electoral vote count was close enough that the entire contest depended upon the poopular vote count of a single state, which was itself close enough to fall within the experimental error of the measuring apparatus. (Hanging chads, ballots with improperly marked "X"s, scantron errors, etc.)

      After that, of course, the usual political process took care of itself, to wit:

      Ignorant public: "Something must be done to eliminate all experimental error!"
      Ignorant politicians: "Computers are something!"
      Frustrated techies: "Just because the computer always reports an unambiguous tally, doesn't mean that the tally reflects the will of the voters..."

      They were, of course, drowned out by a chorus of...

      Contractors and Lobbyists: "Hey, you politicians look like you want a whole lot of voting machines, and we happen to know some people who can build them... for a price."

      Most people (with the exception of politicians and rabid hyperpartisans, and in 2000, they were the minority of the electorate), whether they voted Jackass or Elephant, were willing to accept that it was possible that their candidate lost.

      But nobody - and I mean nobody - wanted to accept the possibility that there was insufficient data to discern the actual will of Florida's voters because the margin of victory was within the expected error of a voting process.

      The recorded vote count in Florida was 2,912,790 to 2,912,253. Even ignoring the experimental error associated with the voting process, a traffic accident on a highway leading to/from a Democratic- or Republican-leaning neighborhood (or a bad rainstorm, or any number of a thousand random occurrences) could have changed the outcome by making enough people stay home, delay voters' arrival at the polling stations after closing time, etc., to have changed the outcome. No matter what technology you use, 269 votes out of almost six million isn't signal, it's noise.

      • by yuhong ( 1378501 )

        Yea, even without this issue, running for President or Congress would be much easier if there was a +/-5% margin. I suggest running the vote again if it falls within this margin.

    • by halexists ( 2587109 ) on Friday March 02, 2012 @12:38PM (#39221877)
      It's not news that electronic systems can be insecure. Those selecting such systems are certainly lobbied to believe that, whatever system they choose, "this time it will be different... this one IS secure."

      The truth is all voting systems -- manually or electronically administered -- are insecure. The feature that traditionally manual voting systems have is that the scale of voting fraud exacted is correlated with the scale of corrupt election officials overseeing the process. To increase fraud you either need a) more conspirators or b) higher-level conspirators in the body that oversees the process. That is a feature that is worth keeping in any new version of voting system.

      This article is just another example of a voting system that has given up the feature. Not all electronic voting systems forsake this feature, but those that keep it are at most electronic-assisted voting systems that retain distributed verification at multiple stages of the counting process. That's because voting is most secure when it's a distributed activity, not a centralized one. With thousands of tiny precincts collecting pockets of votes, any one could tamper with results -- but many would have to tamper to have a big impact. Election commissioners, keep this feature!
    • "Every single technology profession I have EVER communicated with, does not think electronic voting machines are a good idea." Three cheers, too, for superstitious luddites (see below). Here are my top three solutions to computer fraud and f**kups:

      1. Wanted posters and long prison sentences. Rob a mail truck, do time. Why should this not work for email and other electronic fraud? Robbing an election is a more serious a threat to democracy than robbing the mails, which is bad enough.

      2. Human signatures and c

  • Personally, i would have voted for Hubert Farnsworth.
  • I'm sure Bender doesn't endorse the cool crime of election fraud. He just needs a big government network to get down with maximum efficiency.

  • by Todd Knarr ( 15451 ) on Friday March 02, 2012 @11:59AM (#39221461) Homepage

    What I want to see is a real compromise of one of these systems that can be held up as a true scare story:

    1. The compromise is undetected. At the time the results are reported, the election officials are unaware that the system has been compromised and none of the systems in place for detecting a compromise has indicated any trouble. According to all evidence in the audit trail the results are undeniably correct and true.

    2. There was no indication of tampering at the time of voting. As votes were being cast there was no indication of tampering with the ballots or any other visible indication that the results weren't being correctly recorded and reported.

    3. The results reported are undeniably wrong. Eg., the test voting was done in a controlled manner where everyone knew what the correct results should be and that everyone saw that everyone else had voted the way they were supposed to, so if the system functioned correctly it's known exactly how many votes should be cast for which candidate.

    4. The reported results are undeniably wrong. Eg., according to the reported results 100% of the votes cast were for a candidate who should've received zero votes.

    • by OFnow ( 1098151 )

      5. The bad guys who wanted to control the outcome had no way to know the result was verifiable so their compromise was either a waste of time or worse (for them).

      There. Fixed that for you.

    • Hey #1 or #2 is EXACTLY how Bush got re-elected!

    • What I want to see is a real compromise of one of these systems that can be held up as a true scare story:

      ....

      3. The results reported are undeniably wrong. Eg., the test voting was done in a controlled manner where everyone knew what the correct results should be and that everyone saw that everyone else had voted the way they were supposed to, so if the system functioned correctly it's known exactly how many votes should be cast for which candidate.

      http://en.wikipedia.org/wiki/Hacking_Democracy [wikipedia.org]

  • Comment removed based on user account deletion
  • by geekoid ( 135745 )

    He is a bending unit, not a 'head of the DC school board' unit...guh.~

  • Sad-sack programs like this being compromised fuel the other companies who may be equally as susceptible to attack to press on as if they are somehow better or more secure.

    "Sure they hacked that system the government set up, but that was some bloggers scripting in Ruby/Rails in a dark room. They didn't even change the default passwords! We're REAL programmers, writing in a lower-level language with security experience! We can't POSSIBLY do it wrong!"

    If you want to actually test an election system, try havin

  • Bender couldn't possibly do any worse.

  • why we need computerized voting? We hold elections once every year or two, it's not like counting the vote by hand is some huge drain on society's resources. Yes, hand counting is slow, that's why elections are held well before terms expire. Yes, it's labor-intensive to count by hand, but lots of eyes in the process makes fraud much harder. The Florida debacle did expose flaws in the system, but touch-screen voting is not the solution.
  • Let us all welcome our shiny metal overlord. I look forward to his New Washington D.C., with Blackjack and Hookers. In fact, forget the blackjack!

"It's like deja vu all over again." -- Yogi Berra

Working...