Re: Re - [Auth] Auth system idea cleaned up

[Jeremy Petzold]

but that should be irrelivant since the persons Data is stored on the Client 
machine. the hacker would not get any access that he could not have gotten 
before from just filling out a form.

also, having a registry of trused Auth servers would not be a danger to anyones 
information so it would not be dangerous to implement it.

On Mon, 16 July 2001, Carsten Kuckuk wrote:

> 
> Jeremy,
> 
> > **Data Stored Localy**
> > 
> > 1) client requests access from webserver
> > 
> > 2)webserver requests pertenint Data, the encrypted Authkey, and the IP 
> > addresses of the primary and secondary Auth Servers
> 
> Here webserver unconditionally trusts the information given by a client.
> A hacker could install two computers that implement the Auth Server
> interface and authenticate the hacker who presents a forged ID. In order
> for this to work, the "webserver" would have to have a list of trusted
> Auth Servers which leads to the same kind of problems as with Passport.
> This approach does not work in an open highly distributed system. Or you
> introduce a system of cryptographic  certificates where unknown Auth
> Servers could show certificates from trusted Auth Servers. But this gets
> ugly and complicated which generally is a sign of bad design. 
> 
>  
> > 3)web server sends encrypted key to the primary auth server if key is 
> > verified the web server processes the request for access, if there is no 
> > responce,
> > the webserver resnds the encrypted key to the
> > secondary auth server, if it is rejected, the client data is rejected and 
> > deleted, and a notification is sent to the client.
> > 
> > ----------------------------------
> > **Data stored remotely**
> > 
> > 1)client requests for access
> > 
> > 2) webserver sends a request for pertinent data, the AuthKey,and the 
> > Primary/seconday auth server IPs
> > 
> > 3)client sends request for release of data and the web server's IP to the 
> > DataBank server along with the encrypted DataBankKey.
> > 
> > 4) Databank server verifies key, sends data, authkey, and auth server IPs 
> > to webserver. if rejected, the request is droped and a notification is sent.
> 
> Problem 1: Here the webserver is suddenly contated by an unknown
> computer that states that it is an authserver. It might just be another
> computer owned by a hacker.
> Problem 2: Purely practical: How does the webserver make the connection
> between the client-request and the databank request? These arrive
> asynchronously at the web-server. One of them needs to be stored at the
> web-server till a matching request from the auth server comes. This uses
> valuable memory on the web server and also lends itself to DOS attacks:
> A hacker would just send thousands of requests that are never followed
> by an Auth Server packet. 
> 
> > 
> > 5)same as step 3 above.
> > -------------------------------------
> > this should make my Idea a bit clearer, sorry if it seems redundant, I just 
> > wanted to makesure that it was  very clear.
> 
> Thank you for explaining our ideas. That was very helpful for me. I hope
> I did not miss anything critical.
> 
> > BTW all the transmitions should be done via SHTTP
> 
> Hobbyist usually don't have a certificate installed on their web site,
> so you leave a huge froup out of this concept.
> 
> 
> Carsten Kuckuk <-- on digest
> _______________________________________________
> Auth mailing list
> address@hidden
> http://dotgnu.org/mailman/listinfo/auth

Regards,

Jeremy
Find the best deals on the web at AltaVista Shopping!
http://www.shopping.altavista.com