I have a MYSQL database (which in itself contains encrypted data MD5 password fields) that I wish to backup and encrypt. The application is PHP on a standard Dreamweaver shared hosted server.
I'm expecting to have to DUMP the entire MYSQL database then encrypt it somehow.
I understand that I will need to shell_exec() a MYSQLdump, then encrypt it with some form of encryption utility.
Can I please have the PHP code to perform this dump/compression/encryption?
If I'm on the right track, I would expect something like:
<?php
1. [connect to database]
2. [perform MYSQLdump]
3. [perform encryption]
4. [write to file: /directory/backup.<timedatestamp>.gz]
5. [create whiskey & celebrate]
?>
As a very low-level PHP developer, I need specific functioning code that I can copy/paste if you don't mind please. I'm fine with Steps 1 & 5 but require hand-holding on steps 3,4 & 5.
If PHP does not have any inbuilt encryption and a third-party utility is required, I will need to know how to establish if it is installed on my server and how to install if it is not.
P.S. Products created in 5. willingly shared.
Related
I'm trying to perform user authentication against a wordpress/Mysql database in ktor. As far as I know, passwords are stored in the wp_users table after a hashing transformation, performed with phpass framework.
Starting from a plain text password, my aim is to compare this password with the hash stored in the database, to understand if I have to authenticate the user or not.
Is there any support between ktor and mysql/wordpress?
Obviously, Ktor itself knows nothing about Wordpress or any other PHP techonology.
Actually, it doesn't know about databases either. There is an Exposed ORM-framework, which is often used in Ktor projects for that. It supports MySQL databases, so it will be suitable in this case too.
But I believe you will have to write this integration by yourself, cause this is a rather exotic combination of technologies (Ktor+Wordpress), and highly unlikely someone else did it before.
I finally made it!
I found out from the documentation that wordpress uses a password hashing function called bcrypt. Then I searched github for a java implementation and I got into this repository by Wolf480pl.
By copying BCrypt.java and PHPass.java files into my project, I just wrote this simple kotlin function to check the match between the hash stored into the database (I used Exposed to connect to the mySQL db) and the plain text password:
fun passwordMatch(password: String, storedHash: String): Boolean {
val checker = PHPass(8)
return checker.checkPassword(password, storedHash)
}
Just that, it works!
I am writing a Windows VCL desktop using c++ builder. The app uses Firedac and a SQLite database.
I want to protect this SQLite database:
Only my vcl app can connect to it and use it
Other programs and people cannot use the SQLite file
So far I found that the easiest thing that I can do is Encryption, you make it so that anybody without a correct password gets a message like "This file is not a database" if he tries to open it.
Yes we can do this with Embarcadero VCL, doc. using a TFDSQLiteSecurity component and these lines :
FDSQLiteSecurity1->Password = "";/* we are protecting (encrypting) our uncyphered database*/
FDSQLiteSecurity1->ToPassword = 'newpassword';
FDSQLiteSecurity1->ChangePassword();
Unfortunately the VCL Firedac app cannot connect to an encrypted sqlite database so it must decrypt it first.
In order to make things work my program starts and decrypts the database ( removes password) then it connects to the database and use it. When finished I recrypt the database again (when closing app).
THE PROBLEM:
During this time (My program is up and running and the database in uncrypted) can I stop other programs from opening the SQLITE database? Is there a better approach, I am opened for any suggestion
Once it is encrypted by FireDac just set the appropriate properties on the FDConnection. Those would be password to the password and encrypt to the encryption method.
Firedac can open a SQLite database it has encrypted itself so the problem resolves itself by doing that as a better approach. Other programs only see the encrypted version on disk and can't open it without the password.
My place of business currently uses Reflection for Unix and OpenVMS to handle a database of customers. I access this database directly through the Reflection emulation. The only way to get data out of Reflection is to navigate to a single customer via keyboard input and print the information to a .txt.
Is there anyway I can access the VM other than through Reflection with the end goal of automating retrieval of customer information from a Java script executed outside of the Reflection environment? This is the information I can gather via the Reflection interface about what I am connecting to:
At the bottom of the Reflection interface - VT500-7 -- HOST_NAME via SECURE SHELL
Via the Connection Setup drop-down:
Host name: HOST_NAME
SSH config scheme: AutoKeyLogin
User name: username
Via the Security... button:
General tab:
Port number: 22
User Authentication: [x] Public Key
[x] Password
User Keys tab:
Use Name Type Location
[x] username1user DSA C:\Documents\PathToSSHKey\.ssh
Host Keys tab:
Host Type Fingerprint
HOST_NAME, 111.1.111.11, 22 DSA 39:14:f3:123:fds:restOfFingerprint
There is more information available if the solution is possible but I have just not provided enough to solve it, so please ask.
Given that I have the host name, port, .ssh, and host key, is it possible to connect to and read from the VM that I am otherwise connecting to normally via the Reflection emulator?
NO. Reflection (other example is PuTTY) is just a dumb-terminal emulator, here using the (secure) SSH protocol to connect to some Operating System. From the information provided we cannot even tell which OS. Maybe OpenVMS maybe some Unix. Most certainly not a 'VM', but a physical box. Maybe a Alpha, Integrity, Sun, IBM or Intel server.
IF, big if, it is OpenVMS you would possibly see something like this flash by on entry:
XXX - HP rx2600 (1.50GHz/6.0MB) OpenVMS IA64 V8.3-1H1
Last interactive login on Thursday, 7-DEC-2017 13:23:19.83
Last non-interactive login on Wednesday, 6-DEC-2017 12:35:45.80
Most likely username uses is set up to always start a (shell) script which starts a menu from which a program is activated, which knows how to access data record. IF is it OpenVMS then the actual data is likely stored in RMS (indexed) files, but it could in a proper (Oracle RDB or RDBMS) database.
If bulk access to the data is needed then you need to talk to the system/application manager for the system 'HOST_NAME' and ask them about the application and its database.
You may find that there is FTP, ODBC or JDBC or natice DB (OCI?) access to the data avaiable already, or that this can be requested. Likely tools in this space are ConnX, Attunity Connect, and such.
First you'll need to find out which OS/Platform/Version, which application (3rd party? home grown? 4GL? Cobol? Basic? and ultimately, which database/storage method.
That's not to say that some terminal emulator cannot be 'tricked' (google -
screen scraping) to be programmed to fetch a series of data on command, but that will always be error prone and laboriously for limited volumes.
You are better of trying to get proper data access.
Good luck! You'll need some.
Hein
I have a problem when trying to connect to MySQL database using Windows OBDC driver. There are plenty of search hits regarding the obvious... people are using old versions, however, I'm not.
mysqld is on CentOS 6.4 32bit
./usr/libexec/mysqld Ver 5.1.69 for redhat-linux-gnu on i386 (Source distribution)
So I'm at a loss to understand where any pre 4.1.1 protocol is coming from. Any ideas?
I guess that if you ask the right question its easier to find the answer.
In this case "my" problem relates to how the passwords are hashed and stored in the database. Legacy passwords were stored with a shorter hash that's now deprecated.
A few important points:
mysql_upgrade cannot and does not upgrade passwords, nor does it warn about it in some versions, see: http://bugs.mysql.com/bug.php?id=65461.
Even it you have mostly the latest server and clients, all it takes is one legacy client somewhere to create a legacy password and then you'll have trouble with that account no matter what client tries to use it.
Different versions have treated the situation differently so you can be sitting on some legacy passwords in your database and then suddenly, for no apparent reason, some accounts stop working... this is because of how different versions chose to handle the situation.
You cannot upgrade passwords. You must know what they are and you must change them.
EDIT: To be more clear, you must change the password that is stored with the shorter hash using a new client that uses longer hashes. By doing so you will be writing that accounts password with the longer hash, at which point nothing should be flagging attempts to access the account any more. If the problem is recurrent you should be looking for the older clients at your site which are still writing passwords with the deprecated hash length.
MySQL Workbench 6.08 in the Manage Server Connections, Connection tab, Advanced sub-tab you must check the box 'Use the old authentication protocol.'
Try installing old version driver 3.51.30: http://dev.mysql.com/downloads/connector/odbc/5.1.html#downloads
It works on my Mysql Ver 5.0.24a-community
I ran into this while using the ODBC Connector for Windows to connect to a Percona 5.5 server. which has secure_auth disabled.
From what I found the ODBC connector, unlike MySql Workbench, does not support an option to authenticate logins which use the old 16-byte hashed passwords. There is a bug report regarding this, but it appears the assignee is/was confused about the feature request (See bug #71234).
I was able to update the mysql login to use the new 41-byte hash using these commands:
set old_passwords=0;
set password=password('yourpasswordhere');
As I mentioned our server has secure_auth disabled, which appears to cause password() to return old_password() results. Running set old_passwords=0; will enable the password() method to generate the new 41-byte hashes (for the duration of your session).
I had a similar error message when remotely trying to access my MySQL database. Using Directadmin I easily changed the MySql database password as suggested above. This automatically generated the password using the newer hash method. This solved the remote connection problem instantly.
I found another solution in case anyone hits this - very weird -
Install the 5.1 64 bit ODBC driver - verify an ODBC connection by itself works, if you can connect then you should be able to after doing #2
Click on Linked Servers - Providers - right click on MSDASQL, click on Properties
uncheck "Allow inprocess" - which is a good thing to do unless you need to insert TEXT and NTEXT fields.
Create your linked server connection or test the one you have been fighting with - lol
When I had "Allow inprocess" checked I still got the error even though the ODBC system DSN worked fine. I'm assuming because I had a mixture of 5.2 (with servers that worked fine) and 5.1 for the servers that didn't, SQL was sharing the processes because the 5.1 driver does not give that error.
If you can't change your server, perhaps you can change your client: http://bugs.mysql.com/bug.php?id=75425
I am connecting to a Teradata database through ODBC with Stata on an Ubuntu server (12.04 LTS). Everything works fine, except that I have my TD userid and password stored in the .odbc.ini file, which seems like a terrible idea. The alternative is to enter them in Stata, which seems even worse and is awkward. Is there a way to do this more securely? The login info that I use to ssh into the server is synced with the TD database. It seems that it should be possible to pass that information along.
In ODBC terms you do not need to store usernames / passwords in any of your ODBC ini files. Both the ODBC SQLConnect and SQLDriverConnect support the passing in of username / password at the time they are called.
SQLDriverConnect would need something in your InConnectionString like "DSN=YourDataSourceName;UID=username;PWD=password".
You could go one step further and pass in the whole DSN as a command line argument thus meaning that you would not need an ODBC data source in an ini file. I'm sure one of the forum readers can post a sample for you from Teradata.
As for passing in the user name and password from your SSH loging. Your application would need to capture that and pass it to ODBC.
If you want to establish a finer grain of security around your odbc.ini file or other files on your Ubuntu server that may contain user credentials I would strongly suggest the use of Access Control Lists (ACLs). Beyond the typical Owner::Group::World permissions you can specify permissions down to the specific user on whether they are allowed or denied an explicit permission for a given file.
Other options regarding security on Teradata include the use of LDAP authentication if your environment supports it. Configuring LDAP on Teradata is beyond the scope of SO and in many cases a billable, professional services engagement with Teradata's Information Security CoE.