Skip to Content.
Sympa Menu

bluesky - Re: freenet

bluesky AT lists.ibiblio.org

Subject: Global-Scale Distributed Storage Systems

List archive

Chronological Thread  
  • From: steve jenson <stevej AT sieve.net>
  • To: Global-Scale Distributed Storage Systems <bluesky AT franklin.oit.unc.edu>
  • Subject: Re: freenet
  • Date: Sat, 11 Aug 2001 15:26:36 -0700


Quoting Josh (josh AT mercuryfs.net):

> It is true that credit card fraud does make a lot of money. My goal is a
> global method whereby a person does not need to be assigned another ID to
> remember. I figured that since credit cards are global, I can utilize them.
> Visa and Mastercard currently are not deployed in China, but they are
> virtually everywhere else. Since our charges will be 25 cents or less, any
> abuse should show up easily.
>
> Even though its going to be a virtually open source design, we will probably
> keep the credit card module closed source, so people cant modify it and
> redistribute it in order to steal credit card numbers. This should help with
> that issue.

For about 5 minutes until somebody reverse engineers your code. If
keeping your source closed on this is your measure of protection then
you're in deep trouble. There's no security through obscurity.



> We believe that the business model of charging an end user an
> insignificant amount in order to authenticate them, is a valid model. An
> added byproduct of using a credit card is that the bill is an audit log.
>
> Technically, the credit card number is not ever stored locally, and its not
> transferred across the internet in an unprotected form. Basically, a UNI ID
> is a hash of a credit card number and password. To see this, click here


> www.mercuryfs.net/design/uni_id.pdf

First, why are you making people download PDF's and shockwave files when
regulare HTML and animated gif's would suffice?

>From uni_id.pdf
>A UNI ID is a globally unique identification, in the form of an
>email address. Example: bigassunreadblestring AT universal-id.net

I thought you just said that you weren't going to be giving people another
ID number to remember?

"no two people have the same card number"

I think this was already pointed out to be not true.


"When a credit card is invalidated, its UNI IDs no longer test valid"

I would appreciate you going into depth regarding exactly how you generate
the ID from the Credit Card number and Pin in such a way as to make it easily
provable to be invalid without central ID repository lookups. Banks already
know that central lookups for every transaction will not scale. (Refer to
Ross Anderson's excellent 'Security Engineering' chapter 9)


"When a user sets up a UNID ID account, 3 passwords are given."

You get an F- in usability, son.


"4. The party wishing to validate your ID will have just received either
VALID or INVALID."

ooh!! I get all sorts of excited when I read about authentication schemes
that never hand back a token that can be guaranteed to prove the end state
of the transaction. If you don't know why, that doesn't surprise me.


(skipping ahead.. getting bored with techno-babble):

"User and Server types operate the same, but Groups rely on universal-id.net
to be the trusted source of the private key

When a member requests a groups private key..."

huh? Do you know anything at all about public key cryptography?


"When you login to a PC connected to the Internet and slide your credit
card thru (sic) your keyboad (will soon be a standard)"

This is just stupid. Nobody will do this.


Well, I could do this all day long but I think I'd rather go work on a
useful project.


> Our goal will be to engineer the system to a near foolproof and automated
> level.

Ah yes, who doesn't have this goal?

> ... ... ...Personally, I blame Hollywood. I think they turned
> most of the women around here into stuck-up bitches.

This sentece tells me that you should work more on your lady skills and
less on thinking up vapourware.


cheers,
steve


--
steve jenson <stevej AT sieve.net> http://sieve.net/
PGP fingerprint: 79D0 4836 11E4 A43A 0179 FC97 3AE2 008E 1E57 6138




Archive powered by MHonArc 2.6.24.

Top of Page