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
[email protected]
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
