Re: Database Encryption
Craig, At 10:02 AM 3/3/2002 , you wrote: In an effort to encrypt private data in my database (national id numbers, credit card numbers, passwords) I have had to resort to writing code in my application using the Blowfish algorithm. Is there any facility for doing this within MySQL (on Windows)? Any third party tools out there? For speed reasons, I don't want to encrypt everything, just the private data in database? If I have to use the Blowfish algorithm in my client app, is there any standard way of handling keys. I realize this opens up a huge area, but I was curious if there are any simple ways of key handling short of storing it in the executable code of the client app. What can I say except perhaps, Good Luck.g Blowfish isn't as secure as Triple-DES but if you're only protecting against wanna-be hackers it should be ok. You have to weigh the level of security you need against the speed of the algorithm. It would be really nice if MySQL supported table wide encryption so if someone found a backdoor into your data directory, all of your data would be safe from prying eyes. Also if someone broke in and stole your server, table wide encryption will slow them down. Table wide encryption is also needed on web servers where you may be sharing database files with other web applications. There are a lot of problems involved in trying to encrypt individual columns, especially if they are indexed. Read on. Because MySQL doesn't support table wide encryption, you're going to have to program your encrypt/decrypt function every time you update, insert, or select data (which is a real pain). The more programs you have accessing the database, the bigger the pain. This is going to be made easier once triggers are implemented. You didn't say if this was a web application or not. If you're using PHP then there is a PHP library called php_mcrypt.dll that you can use. It has several encryption algorithms including blowfish. You will need to compile it for Windows because the binaries are not available. When the data field is encrypted, so is the corresponding index. This is fine from a security standpoint, but limits the usefulness of indexes.This means to search for an encrypted customer#, you will have to encrypt the customer # you are searching for, before it gets put into the Select statement. $CustId = ToSQLText(Encrypt(1342, secretpw)); $Sql = select * from customer where cust_id = $CustId; The ToSQLText function will escape any quotes and other binary characters (like returns/linefeeds) that may be generated by the encryption algorithm. Now this also presents a problem. Encrypting a number like 1342 will usually produce binary unprintable characters and would be invalid characters for MySQL Integer or other Numeric column types. So that means changing your column types to character for the encrypted fields (OUCH!), or find an encryption algorithm that does not produce binary characters. Perhaps one that just scrambles the text from this is a test to s sttahi its e or from 1234 to 3241. That way you can keep your same data types. (before anyone blows a gasket, the pw would not use the same pattern each time!) As for your Char and VarChar columns, if you encrypt them to binary data then these columns will have to be set to Binary. Of course encrypting indexes also means you can't do ranges like Select cust_id from table where cust_id 100; won't work any more because encrypted data is random. Once the data is retrieved by the Select statement, you will need to decrypt the fields. In PHP you would return the results in an array and decrypt the encrypted fields. Of course you also need to know if the wrong password was given because then you don't want to decrypt the fields into garbage because then it would be re-encrypted to garbage when the record is saved with the wrong password, then no one will be able to access the encrypted data. So encrypting individual fields is wrought with problems. I would not recommend it unless it was really necessary and you're willing to spend the time and effort implementing it. :( Also, while we are on the subject, any recommendations of inexpensive SSH server (and client) software for connecting two Windows 98 machines? Win'98? Yikes! Why not just put your database in a cardboard box and put it on the stoop? It would probably offer more security especially if you use thick corrugated cardboard.g You shouldn't use Win'98 because the operating system doesn't have any real security. If you're serious about security, upgrade to Win2k (XP?) which has much better security. Their NTFS drives can also be encrypted at the OS level (you need to check around to see if there is any problem running MySQL on an encrypted NTFS partition). NTFS encrypted drives won't stop everyone, but it will slow most people down. You can also run Apache on Win2k and that is capable of SSH. You don't need to use IIS or PWS with
No Database Encryption
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
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
