Re - [Auth] Auth system idea cleaned up

[Carsten Kuckuk]

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