Slashdot Mirror


Beat Spam Using Hashcash

Shell writes "If they want to send spam, make them pay a price. Built on the widely available SHA-1 algorithm, hashcash is a clever system that requires a parameterizable amount of work on the part of a requester while staying "cheap" for an evaluator to check. In other words, the sender has to do real work to put something into your inbox. You can certainly use hashcash in preventing spam, but it has other applications as well, including keeping spam off of Wikis and speeding the work of distributed parallel applications." If you're specifically interested in hashcash for your mail server, Camram has some interesting ideas -- their Frequently Raised Objections page may be illuminating.

18 of 324 comments (clear)

  1. Hashcash got me arrested... by Anonymous Coward · · Score: 5, Funny

    Those damn police dogs can smell through plastic pretty well!

    1. Re:Hashcash got me arrested... by Infinityis · · Score: 5, Funny

      Maybe Winzip and Ziplock should merge. I think it'd be nice to have encrypted, password protected sandwich bags, but at 90% compression, I think the bread might not taste so good afterwards.

  2. Again? by Anonymous Coward · · Score: 4, Informative

    The previous stories weren't enough?

  3. Slashdot Spam Form Response by Anonymous Coward · · Score: 4, Insightful

    Your post advocates a

    (*) technical ( ) legislative ( ) market-based ( ) vigilante

    approach to fighting spam. Your idea will not work. Here is why it won't work. (One or more of the following may apply to your particular idea, and it may have other flaws which used to vary from state to state before a bad federal law was passed.)

    ( ) Spammers can easily use it to harvest email addresses
    (*) Mailing lists and other legitimate email uses would be affected
    ( ) No one will be able to find the guy or collect the money
    ( ) It is defenseless against brute force attacks
    ( ) It will stop spam for two weeks and then we'll be stuck with it
    (*) Users of email will not put up with it
    ( ) Microsoft will not put up with it
    ( ) The police will not put up with it
    ( ) Requires too much cooperation from spammers
    ( ) Requires immediate total cooperation from everybody at once
    ( ) Many email users cannot afford to lose business or alienate potential employers
    ( ) Spammers don't care about invalid addresses in their lists
    ( ) Anyone could anonymously destroy anyone else's career or business

    Specifically, your plan fails to account for

    ( ) Laws expressly prohibiting it
    ( ) Lack of centrally controlling authority for email
    ( ) Open relays in foreign countries
    ( ) Ease of searching tiny alphanumeric address space of all email addresses
    ( ) Asshats
    ( ) Jurisdictional problems
    ( ) Unpopularity of weird new taxes
    ( ) Public reluctance to accept weird new forms of money
    ( ) Huge existing software investment in SMTP
    ( ) Susceptibility of protocols other than SMTP to attack
    ( ) Willingness of users to install OS patches received by email
    (*) Armies of worm riddled broadband-connected Windows boxes
    ( ) Eternal arms race involved in all filtering approaches
    ( ) Extreme profitability of spam
    ( ) Joe jobs and/or identity theft
    ( ) Technically illiterate politicians
    ( ) Extreme stupidity on the part of people who do business with spammers
    ( ) Dishonesty on the part of spammers themselves
    ( ) Bandwidth costs that are unaffected by client filtering
    ( ) Outlook

    and the following philosophical objections may also apply:

    (*) Ideas similar to yours are easy to come up with, yet none have ever been shown practical
    ( ) Any scheme based on opt-out is unacceptable
    ( ) SMTP headers should not be the subject of legislation
    ( ) Blacklists suck
    ( ) Whitelists suck
    ( ) We should be able to talk about Viagra without being censored
    ( ) Countermeasures should not involve wire fraud or credit card fraud
    ( ) Countermeasures should not involve sabotage of public networks
    ( ) Countermeasures must work if phased in gradually
    ( ) Sending email should be free
    ( ) Why should we have to trust you and your servers?
    ( ) Incompatiblity with open source or open source licenses
    ( ) Feel-good measures do nothing to solve the problem
    ( ) Temporary/one-time email addresses are cumbersome
    ( ) I don't want the government reading my email
    ( ) Killing them that way is not slow and painful enough

    Furthermore, this is what I think about you:

    (*) Sorry dude, but I don't think it would work.
    ( ) This is a stupid idea, and you're a stupid person for suggesting it.
    ( ) Nice try, assh0le! I'm going to find out where you live and burn your house down!

    1. Re: Slashdot Spam Form Response by er_col · · Score: 5, Insightful

      Thanks for the usual Spam Form Response. I think it is remarkable that very few choices are marked on it this time around. And if you read the Frequently Raised Objections page, you may well end up with no marks left at all. So this hashcash idea does sound really interesting.

    2. Re:Slashdot Spam Form Response by pclminion · · Score: 4, Insightful
      One word, one hyphen: white-listing.

      As a USER of email, I find the need to maintain a white-list simply because spammers are fucking assholes is UNACCEPTABLE. I won't do it. Right now, my Bayesian filters completely hide spam from me. I will not move from that system to a system which requires MORE WORK FOR ME, i.e., maintaining a whitelist.

      Feel free to sit there and feel smug about your "solution" which requires you to waste your time.

      I find that the people who most strongly advocate sender-side blocking, like HashCash, invariably are network administrators who don't want "their" bandwidth wasted. Guess what: I'm a customer. It's my bandwidth. I really don't give a fuck if spammers are violating the sanctity of your precious network. I am only interested in not seeing spam, not thinking about spam, and not worrying about spam. HashCash is a horrid solution in those respects, and I won't accept it.

  4. Re:This doesn't *stop* anything by Raul654 · · Score: 4, Insightful

    Easily countered - then you simply change the hash question on a per email basis. So I ask potential email A a question about FOO and potential emailer B a question about OOF. There's no way to know in advance what I am going to ask. That way, the only way to email me is to actually compute the answer.

    --


    To make laws that man cannot, and will not obey, serves to bring all law into contempt.
    --E.C. Stanton
  5. Re:This doesn't *stop* anything by OverlordQ · · Score: 4, Informative

    In the future (if this takes off), these lists will simply contain the hashes along with the addresses. This temporarily makes the spammers lives a bit difficult, but doesn't have a long term impact.

    Did you even RTFA? If there is *any* sort of time lag from when the Supplier A generated the hashes and sent to the Spammer B and the spammer sends the mail the hash's will become invalid.

    3. The date (and time) a stamp was minted. Stamps in the future and those too far in the past may be judged invalid.

    --
    Your hair look like poop, Bob! - Wanker.
  6. That's covered in the Article. by 955301 · · Score: 4, Informative


    The author points out that a) a date is added to the string to be hashed and b) a database is kept for the day of hashes already used.

    If you include the hash when you pass it out, step a) invalidates hashes of older days and step b) keeps the current days hashes from being reused.

    So it doesn't matter if the spammers share. The hashes are one-times.

    --
    You are checking your backups, aren't you?
  7. I had to quit smoking... by RandoX · · Score: 5, Funny

    ...because I was out of hash cash.

  8. cf Penny Black by r · · Score: 4, Interesting

    Funny, isn't there a Microsoft Research project that did this already?

    Oh yeah, so there is, along with papers explaining how it works. So much for giving credit for prior work.

    --

    My other car is a cons.

  9. Greylisting worked for my company by alen · · Score: 4, Interesting

    We bought a vanilla smtp server for our gateway called Xwall. A few months ago they introduced greylisting.

    Basically what it does is temporarily block suspicious emails. If it's a real SMPT server it will resend the message and the second time it will be allowed to go through. Spammers never use RFC compatible SMTP servers and simply send once in bulk and forget about it. This cut down our spam by over 90%.

    1. Re:Greylisting worked for my company by Haegar · · Score: 5, Informative

      Tried it at work - stopped loads of spam, but had to disable it because out there are too many broken smtp servers (on short inspection mostly lotus notes) that think an return code of 4xx is a permanent error and bounce the mail.

      And my boss is not happy when even ONE important mail from a client is not reaching him.

      --
      c'ya haegar
  10. Re:Right cause, wrong solution. by Em+Ellel · · Score: 4, Informative

    Joe Sixpack wants to send a mail. If it takes him an hour to parse a key, he's not going to mail his mother anymore.

    The general idea is that it will take a relatively small yet significant time to compute. So for example (also random) 30 seconds. Joe Sixpack will not notice 30 second delay on his computer for one email. However Jack Spammer who sends a million emails will need 500,000 minutes to compute the sums. A huge difference.... until you figure out that Joe Sixpack computer's spyware is what actually doing the computing.

    -Em

    --
    RelevantElephants: A Somatic WebComic...
  11. Solution also ignores... by Croaker · · Score: 4, Insightful

    the fact that not everyone is sending legitimate email with a powerful computing device. Something that could cause an inconvenience to a spammer with a boatload of cheap commodity 2Ghz desktop systems (other their own or a zombie army) will bring more modest systems to their knees. Handhelds, phones, old 486 systems recycled for use in the 3rd world, set top boxes, embedded systems, etc. will no longer be viable systems with which to send mail. And what about web mail providers?

    These's simply no reason to resort to kludge solutions that depend on penalizing those who cannot afford top-of-the-line systems.

  12. It's a temporary bandaid, not a solution by Vainglorious+Coward · · Score: 4, Insightful

    Spammers never use RFC compatible SMTP servers

    And spammer tactics remain static, so the same techniques that worked five hours or five years ago will continue to work indefinitely. Not.

    --
    My next sig will be ready soon, but subscribers can beat the rush
  13. The real problem here is not header forging. by mellon · · Score: 4, Insightful

    It's that in order for this to be useful, it has to be widely implemented. Anybody who sends a lot of legitimate email (e.g., hotmail) is going to need to buy a lot more CPU. So it's not going to get widely implemented. So it won't help. Sorry. :'(

  14. Re:Right cause, wrong solution. by Ninja+Programmer · · Score: 4, Insightful
    • The general idea is that it will take a relatively small yet significant time to compute. So for example (also random) 30 seconds. Joe Sixpack will not notice 30 second delay on his computer for one email.
    Yes he will. Because that 30 seconds of 100% CPU utilization. To make sure its not annoying to mail senders, its got to be something really short like 3 seconds or something (that would be my personal threshold). But then there's the question of whether or not its enough of a burden on spammers.