dotgnu-auth
[Top][All Lists]
Advanced

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

Re: [Auth]My two cents


From: Myrddian
Subject: Re: [Auth]My two cents
Date: Tue, 17 Jul 2001 00:48:07 +1000
User-agent: Mutt/1.3.17i

> >>>>>
> ONE master registrar is bad (too much power) Many registrars which can cross
> sign their identities (and therefore their users one) is perfect.
> <<<<<

Yes very bad :)

 
> What about two (or more) registrars that store half of the information
> each?!
> For example, take two registrars, reg1.net and reg2.net. The user wants to
> store his profile, given as an array of bytes p[i], with these registrars
> without
> trusting any of them. This can be done by taking an array of random numbers
> r[i].
> Registrar reg1.net gets to store the array r[i], and registrar reg2.net gets
> to store the array r[i] XOR p[i]. Both registrars only see arrays of random
> numbers. In order to recreate the original profile, the client has to
> retrieve
> r[i] from reg1.net, and  r[i] XOR p[i] from reg2.net, and XOR these two
> arrays
> with each other resulting in r[i]XOR r[i] XOR p[i] == p[i]. So this reduces
> the
> problem to the problem of reliably updating profile arrays at two registrars
> which can be solved by storing two generations of profile arrays.
> 
> This model would consist of
> - Registrars storing two versions of byte arrays for clients that
> authenticate
>   themselves via a user/password scheme which the end-user has to remember.
> - A client computer module that accesses both registrars, retrieves the
> profile
>   string halfes, combines them into the real profile string, makes use of
> it,
>   updates it, and stores new versions with the registrars.
> - A net of independent registrars all over the world would be needed that do
>  not need to know about each other.
> - Clients would choose two registrars that they have to remember.

Having two core, registers defeats the de-centralized authorazation system idea.
We are trying to avoid that, but I see you have a point.

Problems arise with it though

1) Data consistency (how should the data be updated More importantly how 
frequently)
2) Failure, what happens if one of the servers goes down?
3) Making the user remember two distinc logins defeats the one login anywhere 
idea.
   (But this can be automated, however security?)

Howeer your document is a good start on how we should solve this problem, I 
think this also has been
mentioned in another thread. We should focus this argument more on a specific 
topic.


  

-- 
__________________________________________
Myrddian <address@hidden(nospam)au>
-------------------------------------------
"I stayed up all night playing poker with tarot cards. I got a full house
 and four people died". 

                   -- Steven Wright 


reply via email to

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