Internal security of Rev?

[Dar Scott]

Yes.  I agree with moving passwords off the client computer.

However, either the client computer, the app or the user will need to  
validate the server, or you are liable to MIM attacks.  If the  
environment is such that man-in-the-middle attacks cannot occur, then  
this does not apply.  For SSL, a private cert can be created and then  
the public cert for that can be used at the client end.  That needs  
to be moved to the client in a way that does not allow substitution.

The authentication of the user is still done by password.

You might also want some way to confirm that the user is contacting  
the db from a client computer that he is allowed to do that on.

(BTW, it might turn out that your db will do almost all of this for  
you.  Maybe you can just pull out the security manual for the db and  
turn the crank.  If the db can handle passwords, privileges, SSL, and  
encryption maybe you can exploit all that.)

Dar Scott

On Jul 12, 2006, at 7:37 PM, Brian Yennie wrote:

> I would second that. If you're going to go to all of the trouble of  
> encrypting your database, using SSL, taking thumbprints, etc, etc -  
> then just about any method of storing critical passwords on the  
> client side is going to immediately be the weak link. I would  
> strongly consider just not storing the password on the client  
> computer at all and making them enter it each time.
>
> Chipp's method also would allow you to block all connections to the  
> database that are not local. Make 'em go through an intermediary  
> that only accepts certain commands/requests so that even with a  
> username and password, they couldn't connect directly to the  
> database server. Even for low security web apps, that is typically  
> the case.
>
>> John,
>>
>> Here's how I solve a similar problem.
>>
>> I ask the user to login with a name and a password. They enter it and
>> it goes (securely) to a web page on a server, There the connection is
>> made to the database passing along the username and password for
>> verification. This way there is never a need to store anything but  
>> the
>> address of the webpage in the client app. No users or passwords are
>> ever stored there.
>>
>> best,
>> Chipp
>> _______________________________________________
>> use-revolution mailing list
>> use-revolution at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your  
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-revolution
>>
>>
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your  
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>