Re: No Database Encryption
it's not all that dangerous. it just means that you can read your users' passwords. anyone who can read that db table can become any of your users. password fields are just another safeguard against a just in case someone gets read access to this scenario. they also serve to provide more privacy to your users. re: some of your users may not want you / the admins of whatever service you're providing being able to read their passwords. but maybe you want to be able to read your users' passwords, for testing purposes or whatever. -tcl. On Wed, 12 Dec 2001, James McLaughlin wrote: The new programmer for our company is not using the dataType password or any encryption what so ever for our user accounts (accounts that our customers use for getting into our system) in our database. Instead he is using the VarChar dataType. Can someone explain to me how I can exploit this and show them it is very dangerous. Thanks James - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: No Database Encryption
In the last episode (Dec 12), James McLaughlin said: The new programmer for our company is not using the dataType password or any encryption what so ever for our user accounts (accounts that our customers use for getting into our system) in our database. Instead he is using the VarChar dataType. Can someone explain to me how I can exploit this and show them it is very dangerous. It's only dangerous if a customer can trick your web frontend into displaying the output of SELECT * FROM USERS, for example. If the frontend only uses hardcoded queries, or quotes every user-supplied parameter, there's no problem. In fact, you need the password in plaintext to support a I forgot my password; email it to me feature. -- Dan Nelson [EMAIL PROTECTED] - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: No Database Encryption
Yes. 1. Read the manual sections concerning setting up new accounts with special emphasis on passwords. 2. When you thoroughly understand those matters, take the issue to the system administrator and/or management. hth, Doug Only two things are infinite, the universe and human stupidity, and I'm not sure about the former. -- Albert Einstein On Wed, 12 Dec 2001 15:55:04 -0700, James McLaughlin wrote: The new programmer for our company is not using the dataType password or any encryption what so ever for our user accounts (accounts that our customers use for getting into our system) in our database. Instead he is using the VarChar dataType. Can someone explain to me how I can exploit this and show them it is very dangerous. Thanks James - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
RE: No Database Encryption
It's only dangerous if a customer can trick your web frontend into displaying the output of SELECT * FROM USERS, for example. If the frontend only uses hardcoded queries, or quotes every user-supplied parameter, there's no problem. In fact, you need the password in plaintext to support a I forgot my password; email it to me feature. To explain further, MySQL account passwords are encrypted using the (one-way) password function. This works in a similar way to the UNIX passwd file so that people who do have access to the mysql.user table (possibly through a read-only backup account or whatever) can't (without a lot of effort) get any unencrypted passwords back, so they can't log in to the database as another user. You could use PASSWORD to encrypt passwords for user accounts in your database app if there is any chance that unauthorised people could access the table, otherwise it is not necessary. (Plus there is the issue of staff turnover mentioned earlier). As a side note, absolutely *all* user-supplied parameters should be verified. Sure, you can quote, but what if a user paramater includes something like abc; delete from customers; . The quote has been closed, and then the user can do anything he likes. You also need to scan the user input for special characters like and then escape them (\), something which PHP will do for you (if you have it configured that way). Cheers, from Duncan - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
