1

I have been reading this blog post and this stack overflow post but I don't have much experience with hashing form fields (the honeypot part, there seems to be a lot of examples on the web) So I have a few questions.

Question 1

Is it something like this or am I way off base? (Note, this is a simplified example with just the timestamp for brevity)

PHP on the form:

$time = mktime(); 
$first_name = md5($time + 'first_name');

HTML on the form:

<form action="register.php" method="post">
<input type="text" name="<?php echo $first_name ?>" >
<input type="hidden" name="check" value="<?php echo $time ?>" >
<input type="submit" name="register">
</form>

Register.php

// check to see if there is a timestamp
if (isset($_POST['check'])) {
    $time = strtotime($_POST['check']);

    if (time() < $time) {
    // original timestamp is in the future, this is wrong
    }

    if (time() - $time < 60) {
    // form was filled out too fast, less than 1 minute?
    }

    // otherwise
    $key = $_POST['check'];

    if (md5($key + 'first_name') == $_POST['whatever-the-hash-on-the-first_name-field-was']) {
        // process first_name field?
    }
}

Question 2:

How does the hashing of the field name make things more secure? I get the timestamp check (although I don't understand the part in the blog post "too far in the past"...wouldn't a bot fill it out too fast if anything??) but I am not sure what hashing the name attribute does exactly.

Community
  • 1
  • 1
redconservatory
  • 21,438
  • 40
  • 120
  • 189
  • Hashes are one way, they can't be decoded – SupremeDud May 11 '12 at 12:52
  • Decode is a bad choice of words. I meant, compare the hash the form created with the name that was supposed to result based on the "check" field. – redconservatory May 11 '12 at 12:53
  • Also, does it matter whether I am using md5 in this example, or should I be using SHA2? – redconservatory May 11 '12 at 12:55
  • Thinking about it, maybe the (partial) answer to #2 is that bots fill out the field based on what they think it is "first_name" "email" and so on...so if the name is something they don't recognize, they won't fill it out? – redconservatory May 11 '12 at 12:57
  • The advantage of saving passwords in hash is that even if your database is stolen user's passwords will still be secured until they are cracked using brute-force attacks, but this can take a very long time. By the way, you can use more advanced hashing, for example, hash something twice, use different algorithms and etc. – Leri May 11 '12 at 13:06
  • I see what you are getting ask, but I am actually asking about hashing field names for this particular example. I am extending a controller that already hashes the passwords with a salt – redconservatory May 11 '12 at 15:04

1 Answers1

6

You need to hash the field names server side before you send them to the client:

<form action="register.php" method="post">
<? $timestamp = time() ?>
<!-- This is where the user would put the email. Don't put this comment in for real -->
<input type="text" name="<?php echo md5("email" . $timestamp . $secretKey) ?>" >
<input type="hidden" name="check" value="<?php echo $timestamp ?>" >
<input type="submit" name="register">
</form>

That will randomize the names of the fields. On your server when the data is posted you need to re-hash the field names to find the correct post variables:

<?
    if (isset($_POST['check'])) {
        $email = $_POST[md5("email" . $_POST['check'] . $secretKey)];
    }
?>

The author of the blog says this is a way to prevent replay attacks. I think there is some merit to the idea, and here is how it would work:

  1. An attacker would visit your site, and manually fill out the form, recording all of your field names.
  2. He would then input those recorded field names into his bot and program the bot to re-fill your form at a later time.
  3. The attacker might record this for the 'email field' <input type="text" name="0c83f57c786a0b4a39efab23731c7ebc" /> and for the hidden check field <input type="hidden" name="2012/05/11 12:00:00" />
  4. The bot would then post those very same fields with different data.
  5. This is where your "too far in the past" check would be triggered. The bot would be posting a timestamped form with an old date and you would reject it.

I hope this helps you understand what the blog author was getting at.

SupremeDud
  • 1,371
  • 10
  • 18