[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Jeremy Petzold
Subject: Re: Re - [Auth] Auth system idea cleaned up
Date: 16 Jul 2001 13:59:07 -0700

also, I just realized that it is almost pointless to worry about authorization 
if the client is holding the data. the secod senerio however works well, I 
think, as the Data Bank requires a valid key before it will realese the 
information to the website, which then must ask for authorization before it 
processes the access request. and then we could just leave out the actual 
physical server all together and make the auth server part of the client 
software, and then pehaps we could work out a dynamic key generation system.

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


Find the best deals on the web at AltaVista Shopping!

reply via email to

[Prev in Thread] Current Thread [Next in Thread]