All of your suggestions could also be implemented in centralized
database, if desired.

But the key management seems potentially unwieldy if you want every
parent and every scout to be able to access the database.

Charles

-----Original Message-----
> From: Shane Hathaway <[EMAIL PROTECTED]>
> Subject: Re: [Ldsoss] Scout Tracking
> Date: Tue, 13 Jun 2006 10:32:44 -0600
> To: [EMAIL PROTECTED],
>       LDS Open Source Software <[email protected]>
> Reply-To: LDS Open Source Software <[email protected]>
> 
> Steven H. McCown wrote:
> > The reason that I proposed the non-centralized storage option is that not
> > that security is more or less, but because attacks on very small databases
> > yield very small rewards.  In contrast, attacks on highly-centralized
> > databases offer greater rewards for the attacker.  
> 
> The architecture I suggested would effectively turn the centralized
> server into warehouse of small, practically unbreakable databases.
> 
> A desktop application will be the only way to use the database.  The
> database will be encrypted with high grade encryption and using a long
> key.  When users enter their password, they will enter the password for
> accessing the key, not for opening the database.  The key will be stored
> on the user's hard drive (or even in the TPM module embedded in their
> computer), not on the web server.
> 
> To allow a new user to access the database, that user needs, at a
> minimum, both the key to the database (an RSA key, perhaps) and the
> password for using that key.  Users will be required to copy keys
> between computers using removable media.  Even administrators of the web
> server won't be able to access the databases because they won't have the
> keys.  It wouldn't even matter if they guessed passwords.  A password of
> "123" is OK as long as the key is guarded.  If everyone loses their
> keys, the database will become impossible to access.  There is no
> "master" key.
> 
> The only practical way to break such a system is to steal private keys
> one at a time or find a flaw in the way the software is using
> cryptography.  Conceivably, someone could write a virus that steals
> private keys, but *any* desktop application is vulnerable to that
> attack, so that's merely an argument for not using operating systems
> that have a lot of vulnerabilities.
> 
> So the only concern is that the application has to use cryptography
> correctly.  Now that we have OpenSSL, that's not very hard.
> 
> Shane
> 
> _______________________________________________
> Ldsoss mailing list
> [email protected]
> http://lists.ldsoss.org/mailman/listinfo/ldsoss

-- 
Shaving brushes
You'll soon see 'em
On the shelf
In some
Museum
Burma-Shave
http://burma-shave.org/jingles/1943/shaving_brushes
_______________________________________________
Ldsoss mailing list
[email protected]
http://lists.ldsoss.org/mailman/listinfo/ldsoss

Reply via email to