From: John Saylor <[EMAIL PROTECTED]>
Date: Mon, 7 Feb 2005 17:42:15 -0500
Greg London:
> > > > Would it be any less secure than having the user
> > > > set up an account and their own password?
> John Saylor wrote:
> > yes, more prone to spoofing since it's only one piece of info [trakcing
> > number] instead of 2 [username/pw].
That depends on the number of possible tracking numbers vs. the number
of possible "username.pw" strings. Since you can make the tracking
number as long as you like, you can always make this solution
arbitrarily less spoofable than username/pw.
( 05.02.07 17:08 -0500 ) Greg London:
> Is this if the tracking number / one-time password is
> tied to the email address that made the order?
> Or does this describe a tracking number with no associated
> email address?
I assume this is not actually a "one-time password", since the user
might want to check progress on a given order multiple times, but a
"one-transaction password."
well, if there is an algorithm to generate the tracking id, it can be
spoofed. so maybe the email is used there, and maybe not [maybe the
date, maybe a counter, w/e].
Again, that depends on how many bits you choose. And if you use a
counter, you lose. Unless, of course, you push the counter value
through a trapdoor algorithm before handing it to the user, so that
consecutively assigned numbers seem random. That is the basis of some
crypto random number generators (e.g. Yarrow).
i'm also not taking into account the fact that many passwords are easily
guessed here. i'm just talking about the information needed to
authenticate in some way. someone else wrote in about how many passwords
are very easy to guess.
a password is probably going to be easier to guess than a tracking id
[user error], but it may be pretty easy to generate a tracking id or
two.
Trivial, in fact. You can take your internal transaction ID and
transform it with SHA1, or even MD5, and then pick off as many bits as
you decide you need to keep the odds of successful brute-force guessing
acceptably low. I've done this before, in a protein structure analysis
server that isn't anonymous but could be made so (and would have been if
licensing restrictions didn't interfere). 1 in 10^15 is probably
adequate; this is the chance of guessing an exceptionally good
8-character password. (I used the first 16 digits of MD5, which is
about 10^20, and undoubtedly overkill. Then again, credit cards are 16
decimal digits, so maybe not by much.)
You could also dispense with the email address, and take a crypto
hash of the credit card number, suitably salted. You then have
something close to a "per-customer password" instead of a
"per-transaction password," and a way to collect marketing data on those
pesky folks who want to believe they can remain anonymous on the
Internet. Two problems: (1) You have no way to contact the customer in
case there are problems with the order; and (2) users may consider it
spooky that the system remembers who they are based on only their credit
card number -- they may not believe you're not storing the card number.
Of course, this all hinges on keeping those URLs and/or cookies that
contain the tracking number secure. The user would probably want to
bookmark the status page; wouldn't that also be vulnerable to Javascript
exploits?
-- Bob Rogers
http://rgrjr.dyndns.org/
_______________________________________________
Boston-pm mailing list
[email protected]
http://mail.pm.org/mailman/listinfo/boston-pm
