Re: Salting with hash data
- From: Ilmari Karonen <usenet2@xxxxxxxxxxxxxx>
- Date: Thu, 28 Feb 2008 23:17:07 GMT
HappyCat <noemail> kirjoitti 28.02.2008:
Yes, this is card number data being protected.
There would be around 50-100k log entries monthly, and 6 months of
historical logs kept. On an average month there would be a dozen or so
queries on the data which are mainly used for debugging or analysis.
Hmm... a lot depends on exactly what information might be required for
that "debugging and analysis". I'm afraid there may not be a single
easy solution -- there's not much one can do about the fact that an
adversary who has access to your log can just try out all card numbers
by brute force -- but there might be various measures you could take
to limit the risk.
For example, would it be practical to encrypt the numbers by a random
secret key, and switch the key (without recording the previous one)
every once in a while (say, monthly)? The old data could still be
used for debugging (e.g. to check that two purchases made during the
same month were made with the same card) but would be pretty useless
to an attacker once the key was permanently lost.
Also, can you tolerate a certain amount of false positives or
negatives in your data? For statistical purposes you probably could,
in which case you might be able to use a short hash and add so much
chaff to the database that brute forcing becomes pretty impractical
(since a significant faction of all possible card numbers would yield
false positives).
One measure you could always take to deter brute force guessing would
be to make your hash function slow: if you expect your peak logging
volume to be, say, 10 transactions a minute, choose a hash function
that takes up to 5 seconds to compute on your (presumably fairly fast)
server. One way to accomplish this would be to hash N repetitions of
the card number, where N is some sufficiently huge value; you should
be able to do this without consuming excessive memory, since most hash
implementations should allow you to feed in the string to be hashed in
pieces (and nothing says you can't just pass in the same piece over
and over). Of course, this will not stop an attacker with enough time
and computing power; but even slowing them down, say, ten-million-fold
might still be worthwhile.
--
Ilmari Karonen
To reply by e-mail, please replace ".invalid" with ".net" in address.
.
- References:
- Salting with hash data
- From: HappyCat
- Re: Salting with hash data
- From: Paul Rubin
- Re: Salting with hash data
- From: HappyCat
- Re: Salting with hash data
- From: Paul Rubin
- Re: Salting with hash data
- From: HappyCat
- Salting with hash data
- Prev by Date: Re: CRC of a Data Block Containing an SHA1?
- Next by Date: Re: Salting with hash data
- Previous by thread: Re: Salting with hash data
- Next by thread: Re: Salting with hash data
- Index(es):
Relevant Pages
|
