Re: Honeytokens and detection

[Jeremy Bennett <jeremy_f_bennett () yahoo com>]

In general you should not generate decoy/deception data from real data
by filtering it through any reversible algorithm. Imagine if you added
1 to the 8th digit of all credit card numbers in your DB and then used
those in your honeypot. Of course your honeypot gets hacked, the CC
numbers get stolen and you feel you've learned a lot about the hacker.
Then the algorithm you used (adding 1 to the 8th digit) is leaked. Now
everyone with that 'bogus' CC DB can convert it back to a real DB.

Better to use syntactically valid numbers that are not, and will never
be, working. Remember, our attackers have access to the same web sites
we do. The smart attacker is going to verify the numbers.

-J
--- Brian Hatch <honeypots () ifokr org> wrote:
> > What would be even better is if the IRS or some credit
> > card companies could post or distribute such honeytoken 
> > numbers, so we within the security community are certain
> > we are not implanting valid numbers.
>
> You can easily create bogus credit card numbers, since they
> use a check digit to be sure that it's valid.  The first
> relevant page I found via google describes the check
> digit algorithms, and proper format (prefix/length) of
> the numbers for various credit card companies, so generating
> a number that looked good should be pretty easy.
>
> However the easiest is probably to just take a hundred
> credit card numbers that you already have stored, and add 1
> to one of the middle digits at random.  It's guarenteed to
> break the check digit algorithm, but other than that it looks
> fine, with no need to actually generate them.
>
>
>
> --
> Brian Hatch                  "In five minutes we're
>    Systems and                going to take a nap."
>    Security Engineer          -- Bri
> http://www.ifokr.org/bri/    "No! Ten Minutes!"
>                               -- Reegen, age 21 months.
> Every message PGP signed

> ATTACHMENT part 2 application/pgp-signature