My users are using MS Access and ODBC connector to connect to my remote MySQL database. I wonder how secure this is, in the sense of possible password disclosure to 3rd party. Is the mysql protocol authentication safe to eavesdropping or even man-in-the-middle attacks? I would be quite happy with safety against eavesdropping. Note that my concern is only authentication, I'm not concerned about data disclosure.
Please don't reply that I should use SSL. I know this would be ideal however the setup doesn't seem very simple. Anyway, I would like to know what is the safety level of plain mysql protocol.
What is it that you want to be "safe to eavesdropping or even man-in-the-middle attacks"? Your password, or your data?
The title of your question refers specifically to authentication. MySQL does a reasonable job of protecting your password from eavesdroppers (it is not sent plaintext, and the use of a nonce defeats replay attacks). Citing MySQL protocol internals:
MySQL 4.1 and later
Remember that mysql.user.Password stores SHA1(SHA1(password))
The server sends a random string (scramble) to the client
the client calculates:
stage1_hash = SHA1(password), using the password that the user has entered.
token = SHA1(scramble + SHA1(stage1_hash)) XOR stage1_hash
the client sends the token to the server
the server calculates
stage1_hash' = token XOR SHA1(scramble + mysql.user.Password)
the server compares SHA1(stage1_hash') and mysql.user.Password
If they are the same, the password is okay.
(Note SHA1(A+B) is the SHA1 of the concatenation of A with B.)
This protocol fixes the flaw of the old one, neither snooping on the
wire nor mysql.user.Password are sufficient for a successful
connection. But when one has both mysql.user.Password and the
intercepted data on the wire, he has enough information to connect.
However, authenticated sessions continue in plaintext: an eavesdropper will be able to see all queries and results; and a MITM would be able to make alterations to the same. As stated in the manual:
By default, MySQL uses unencrypted connections between the client and the server. This means that someone with access to the network could watch all your traffic and look at the data being sent or received. They could even change the data while it is in transit between client and server.
Whilst you may not like the answer, SSL is the tool designed to defeat both data eavesdropping (how else can the communications be encrypted?) and MITM attacks (how else can either party verify that its peer is who it thinks it is?). Indeed, if the mysql client-server protocol alone defeated these threats then there would be no reason to use mysql over SSL (and thus it would be unlikely to be a supported configuration).
Short answer: Yes, the protocol is safe from Eavesdropping and MITM attacks.
Only if the attacker manages to sniff an authentication attempt AND if the attacker knows the contents of mysql.user, then he can subsequently authenticate against the server. For example if you're using the same password on two different mysql servers and the attacker gains access to one of them, he can also connect to the second server.
Related
I found an old question in ServerFault on the same topic but I am not sure what has changed with MySQL 8. Do I need all 3, the server-ca, client-cert and client-key to make successful SSL connections to MySQL 8? I don't really care for client certificates (all my clients are exactly the same). So do I still need all 3? Also looking at Google Cloud MySQL and it lets me download just the server ca. Seems like the client certs are optional. However I can't seem to connect without the client certs.
The bit that's really important is the client key.
In my experience with GCP, depending on the exact setup, you can often just use the client key and client cert, rather than needing to supply the server certificate (which GCP stores on their end anyway).
Cloud SQL allows you to simply download the server CA because, fundamentally, it isn't as sensitive as the client cert/key. Those are private and only available once, when you first generate them. After that, if you didn't securely save them somewhere else, you cannot get them again (although you can revoke them if they ever get leaked).
The good news is that you can generate lots of client key/certificate pairs (whereas generating a new server certificate will likely schedule it to be rotated in at some point in the future), so there's no problem with your going ahead and generating some new ones.
A security audit was performed on my network and the auditor flagged an issue which he feels is a high-level threat regarding our MySQL 5.7.24 installation on an IIS server.
When browsing to http://%myIP%:3306 the visitor receives the following message:
[���5.7.24-log�C���.m[aUg&$�ÿ÷�€����������p;}fQ^Z?Ia�mysql_native_password�!��ÿ„#08S01Got packets out of order
The auditor feels that MySQL is possibly revealing a user name or password in this response.
I doubt this is the case, but wanted to get responses from the experts.
Also, is this (what appears to be a login prompt) necessary? Is there a way to turn this response off?
Some things:
Using unencrypted rather than TLS-encrypted MySQL connections is a far bigger vulnerability than MySQL responding with error gibberish when you hit it like it's a web server. Badguys can sniff your customer data.
You should consider firewalling your MySQL instances so they can only be hit from the machines needing their services. If this audit probe comes from the public network, this is definitely something you must remediate. "True positive."
MySQL here announces its available authentication method (mysql_native_password). It also indicates its confusion upon receiving HTTP protocol data rather than MySQL protocol. packets out of order. So it is functioning as designed and revealing nothing except that it is MySQL. "False positive."
If this auditor insists this is still a problem after you explain it, then you should consider switching to TLS connections to your MySQL instances.
For what it's worth, I've never seen an auditor who knew much about protocols other than HTTP/S.
I have an encrypted connection from my ios app to my mysql database. My question is whether or not they would be able to intercept the connection form the ios app and find the domain with or without an encryption
whether or not they would be able to intercept the connection form the ios app
Yes, they would be able to do so. At least surely using a jailbroken device - for jailbroken devices, there are a couple of factors that make hacking easier.
On the one hand, on a jailbroken system, it is possible to prevent Apple's encryption of the app executable (by dumping the unencrypted program code from memory to the disk) and run a utility called "class-dump" to obtain the Objective-C class information (it is also possible to use the GDB debugger on the device or IDA Pro in order to reverse engineer the application logic).
On the other hand, the same MobileSubstrate library that is used for making iOS tweaks can be used to alter the behavior of any given application (I have successfully used this technique for circumventing some code obfuscation at runtime), so in theory an attacker would alter the communication logic of your application and dump the unencrypted data of yours and your users.
On the gripping hand, most standard and less-used Unix utilities usable for such kind of hacking are ported/compiled for jailbroken iOS - including the popular network sniffing tool nmap, the "John the Ripper" password cracker, the infamous aircrack-ng WEP/WPA key cracker, the GNU debugger (GDB), etc. These are also useful for executing an attack you described.
If the connection itself is encrypted, then, in theory, your data should be safe while in the wire. This still doesn't prevent the MobileSubstrate-based approach to exploitation. It is also true that the IP address of the server you're connecting to can be found relatively easily (end even the domain it is matching, since there are also known techniques for obtaining reverse-DNS information using a known IP address).
I'm not sure if this is possible without a jailbreak, but a similar man-in-the-middle attack was performed against Apple's in-app purchases by a Russian hacker (effectively rendering ineffective the underlying payment system and allowing purchases to be freely downloaded), merely by requiring users to install SSL certificates, profiles and using the hacker's own proxy server, so I'd suspect it is possible even without a jailbreak. Note that in this case the connection was also encrypted, and it was not the encryption that mattered.
You should not imo create a direct connection to the mysql-database but instead pursue a connection with a server program/api with a connection to the database in question. To answer the question more directly users should not be able to intercept the connection from the ios-app if it is encrypted correctly but still, is it worth that risk?
If the connection is encrypted, the data are secure. But not the domain. The iPhone is connecting to an IP Address, and that IP Address is obviously not encrypted.
Create a PHP interface between your app and the Mysql. Doing this they will be able to hack only app-accounts not the entire database! Your Mysql credential will be stored in the remote domain where the PHP code runs.
I've setup a web server and can exchange data between it and my iPhone by using JSON.
Is JSON already encrypted? I'm trying to make an app that people can use. I'm not sure how to securely verify a user. Right now I'm having them send some information that uniquely identifies them along with their GET requests.
But couldn't someone easily pick this up, and then replay the GET request to the server to access the same information?
What's the right way to do this?
JSON is not automagically encrypted, no.
Secure your server with SSH. This should prevent most MITM type attacks. If you are extremely worried about replay attacks from the client side (browser), you will probably need oAuth + a secure nonce.
No security measure will protect you 100%, you have to compromise security vs performance.
If you are worried about MITM attacks, most likely someone sniffing requests on your network and then replaying them, you could set up SSL and send the JSON request via that, which would prevent the attack.
The only other thing is that via GET your security variables will be exposed in the URL.
Whether it is ideal form is what kind of information you are transferring and what other authentication you are using.
http://joekuan.wordpress.com/2010/05/08/quick-steps-on-setting-up-apache-ssl-php-json-on-freebsd-8-0/
We have recently implemented Transparent Data Encryption in SQL Server 2008 for local databases on our developers laptops to keep them protected in the case a laptop is stolen or lost. This works fine.
Now we are trying to figure out a way to have the certificate expire everyday, forcing an automated process (a script at logon maybe) to go out to a network path and grab a new certificate with an expiration for a day later. This would ensure that if something unforeseen happened, the data would not be usable the next day.
I also looked into using a Cryptographic provider but there doesn't appear to be any "providers" out there. Maybe I'm wrong.
I am open to suggestions. If there is a better way please let me know. Thanks!
Short answer: No
Long answer: Once a message (piece of data) is encrypted, that same key will decrypt the same encrypted message, regardless of what time the decryption algorithm is applied. If the key is changed every day, the data must be decrypted with the old key and re-encrypted with the new. If this process doesn't occur (i.e. someone stops the piece of code that performs the re encryption from running), the old key will still work. Even if you do create a cryptographic provider to check the date, someone else can create a new provider to perform the decryption without first checking the date.
T address the question rather than the motivation. If you set up a Microsoft CA with a derived template (Set to expire for a day) and also allow autoenrollment on that certificate template. You could then set your SQL machine to be part of a OU within the Directory that uses autoenrolment (Technet will give you resources on this requires the use of goup policy). That way when the certificate expires the machine will automagically request a new one.
http://windowsitpro.com/article/articleid/40948/windows-server-2003-pki-certificate-autoenrollment.html
Mark
Not true! There are options available for SQL Server 2008 encryption. Check out the database encryption solutions here at TownsendSecurity.com. Townsend's Alliance AES Encryption is a NIST-certified solution that would put you into compliance with the regulations around health care, credit cards, and banking. Also see the white paper on Alliance AES Encryption.
Businesses with sensitive data in database applications
want to encrypt the data in order to secure it from loss.
Protecting sensitive data increases customer trust and
loyalty, reduces legal liability, and helps meet regulatory
requirements for data security. Examples of databases
that might contain sensitive information are Oracle
Database, IBM DB2, Microsoft SQL Server, MySQL,
and Microsoft Access. Regardless of the disk or folder
encryption technology that might be used, the actual
data should be encrypted to prevent loss
Full disclosure: I'm an intern at Townsend Security.
Without additional detail I fail to understand how your TDE setup will protect data in case it is lost or stolen.
If you are not using full disk encryption (via Bitlocker, Truecrypt, etc) then I as an attacker in physical possession of your hardware can easily reset the local admin password, boot up the laptop and access the SQL Server instance with the local admin credentials. At that point I am a sysadmin on the database server and am able to extract any data I want or to turn off TDE.
In addition since all of the encryption keys and certificates are stored locally it is relatively easy for an attacker in physical possession of the device to gain access to them. TDE is only meaningful for data protection when you physically separate the Database Encryption Key protectors (stored in the master database) from the encrypted database.
If you are using full disk encryption than the usage of TDE is not providing any additional deterrent to an attacker and is only adversely affecting system performance of your developers laptops.
You're right - what you want is a cryptographic provider, and you're right that there's none out there yet.
If you're going to the PASS Summit in November, talk to JC Cannon from Microsoft. He's doing a session on compliance, and he's the head of the SQL Server Compliance group. He's tied into the vendors that are currently working on building cryptographic providers, and he may be able to talk to you about vendor names. Right now they haven't come out publicly to announce who's doing it yet.