ID:1951831
 
I'm working on a client application that connects to a MySQL Database. The client must connect to the database with a user that has both read and write permissions.

What can I do to ensure this password is 100% secure and cannot be read from memory? I was looking at the SecureString Class, but I'm under the impression that the password is still stored in memory as plaintext at some point.

Any tips from experienced developers is helpful. Keep in mind that my experience is low compared to some of you, please try and explain things in simple terms if you can. Thank you.
You'd need to encrypt it before sending it and it would have to be able to accept that encrypted pass.

I've tried MySQL login/account creation and gave up around the basis of not being able to encrypt the passwords successfully. I managed to get the MD5 function to work, but an MD5 without a salted hash might as well be an unencrypted password for anyone who can crack it.

Since I wasn't able to salt the hashes (which is probably possible, but perhaps out of my league at the time), I gave up.

I used Air Mapsters Crypto Library and Dantom's database library.

Plaintext passwords are a pain. There isn't a 100% certainty that anything that originates in plain text will never be stored that way. The source must be encrypted (hardware level encryption might do this), utilized in its encrypted form and communicated encrypted. Otherwise, at some point, the unencrypted plaintext will be stored or viewed somewhere along the line.

The weakest part of the whole system, is, of course the root or user of MySQL that you utilize. If it has a bum password that is easy to crack, someone gains control of the whole MySQL and if they're smart they can change small things so you won't notice (or just wreck it, if they wanted too).

Other examples of encryption breaking are when the source is decrypted and viewed on a public screen in a public area, or unencrypted by a malicious source and spread around, or left open on a terminal in a workspace/etc. Any time it is displayed unencrypted, it is prone to being broken by anyone in the right place at the right time and with the will. Imagine if you are using Win10 and you have the keylogger on, guess what, Microsoft knows all of the unencrypted passwords AND has your BitLocker encryption key stored on their cloud servers. So, basically, in other words: No Encryption (with such a system).

If others are collecting the plaintext, it is nigh impossible to provide 100% security to that plaintext, once encrypted.

If you need it, I can provide the snips.
The problem is, it's trivial to rip strings out of an executable (same is true for dmb files), so it's really easy to just snatch raw passwords out of things that way. The ideal method is not connecting to the SQL database directly and using an encrypted medium to handle everything.
@AERProductions, I think you misunderstand my situation. This isn't related to account password hashing. The client itself has the raw database connection information stored inside of it and is loaded into memory. The client needs not only read permissions, but write permissions. With this information, someone can extract this information and use it to connect to the database and have full control over it. Restricting remote connections is not an option.

@Nadrew, would sending a HTTP Request over SSL work?