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
