I've got a couple of questions around storing/retrieving passwords with MySQL / Visual Studio 2010 (VSTO Visual Basic). I hope they are straight forward!
SHA-2 QUESTION
I'm making a table using MySQL (through the PHPMyAdmin Interface) to store just two columns: User ID & Password. After reading through SO and a bunch of other resources it seems that storing the password using SHA-2 encryption and salting is a viable option. Is this correct?
VISUAL STUDIO 2010 QUESTION
I am building a VSTO project in Visual Studio 2010 and will be accessing the data in the table using Visual Basic - how can I encode a user-inputted password with the SHA-2 algorithm? I can't seem to find any 'current' guides on this process. I'd imagine I have to download/install an extension that can process the SHA-2 algorithm into VS2010. The process here is, I have a 'login system' built within Excel but I want to verify the username/password combination by comparing it to the already existing data in the MySQL table.
SALTING QUESTION
Also, Salting is HIGHLY recommended practically everywhere I read so I decided to use a random string like 's#w0s9w%$x" or something like that and obviously store this/use it every time I need to encode + match a password to the database. Is this secure enough? How would you use a different salt word for every user but keep track of this? Would you simple save the username/salt-word combination in another table and extract it later?
EDIT: Added more info!
Don't try to create your own password hashing scheme. Instead use a well known one. Generally there are three options: Bcrypt, Scrypt, and PBKDF2. These are designed by security professionals, and have been around for a long time and have not been broken. Implementations are available for many languages.
For the salting question, you have the basic idea right. Usually the salt is stored with the password in the database. The salt is not considered to be a secret, but it should be unique for every user. Bcrypt hashes already contain the salt in itself, so you don't need to worry about that.
Related answer in security.se: https://security.stackexchange.com/a/6415/20774
A nice article on the subject of password hashing: http://crackstation.net/hashing-security.htm
Related
I am very sorry if this has been answered before, but I have searched for 2 days and cannot find the answer. I have 2 databases and I need to import users from the current database to a new one. The new database is for a chat system that has recently bee installed and I would like all users to be added to it.
So I thought I would simply manually add the users in the new database using information from phpmyadmin. But the encryption for the password is a different format and will not work.
For example in the first database the encryption is:
z70I9QINffX2Hh7FxQ==
In the second database the format is:
3eb5c61f784aa3c2e11d879382387d420f7c4ebf
Neither seem to be MD5 and I can't find out which type it is.
I know this is a stretch but does anyone know of a way to detect the type of encryption and how I can take a password, such as 'password' and encrypt it using the correct encryption type?
Thank you
You could try using a generic password for the root user, or logging into mysql as the root user & creating another user manually. Not sure what kind of access you have, but that's been the best bet in my experience.
Hope it helps.
The password encryption mechanism would be stored in the application's code. The 1st example looks like Base64 but can't be sure without comparing others. The 2nd example appears to be SHA1/MySQL5 Sha1(Sha1(pass)).
You're going to have to research the apps that are using these databases and to determine how it's creating and storing these account passwords in the database. Either way, you are trying to link 2-dbs that have different password mechanisms, that might require standardization of the passwords which might mean a password resets.
There is a harder way, you have a database of one-way hashed passwords. It will require a bit of focus in scripting... You would have to generate hashes for the cryptographic hashes used and compare to your users passwords to get the plaintext password. Then you recreate their accounts in the new DB using their passwords to create the new user with same credentials.
I want to build a VB.NET application that will connect to a MySQL database.
I was thinking of putting the MySQL password on the My.Setting file, but that's easy to read. Which would be the safest way to put the password on the program?
I don't want to ask for it on start-up, I want it to be embedded on the software, but WHERE?
Wellll..... If it's stored in an automatically program-readable format (aka, the user doesn't have to enter any kind of password or credential to enable the application to make use of said database password), then there isn't exactly a "safe" way since any kind of meaningful encryption requires that the user enter some credential to retrieve the encrypted information. You could store it in a module as Base64 text for obfuscation, but that's not really "safe." At all. It's just encoded differently (NOT encrypted).
The bigger question to me is, is the environment safe? On the back end of a website for example, the password for sql databases is usually stored in-the-clear in the php config files... but that's because the environment is secure: php source cannot be obtained by the public, and trusted users with access to the backend are assumed to be non-malicious.
So, that raises some questions:
Where is the application running from?
Where is the MySQL Database, local or remote?
How many people have access to this database or will be using this app?
These are all considerations that should be accounted for.
One other thing - if you're building a .NET application, there are certain .NET code-obfuscators out there that play with your compiled code to make it quite difficult to pillage once compiled. This may be of interest to you. I believe Dotfuscator ships standard with Visual Studio? You can register for a free account with them.
I'm in the process of moving a Magento store into WooCommerce. The problem is that Magento and WordPress have different password authentication algorithms.
The way Magento stores the password: md5($salt.$password).':'.$salt;
The way WordPress stores the password: md5($password)
Is there a way to export existing Magento customers into WordPress and keep their passwords?
No, there isn't. As you noted, Magento stores its passwords with a salt
password:salt
Wordpress also stores its passwords with a salt — except the salt is an empty string and the same for everyone (i.e. Wordpress doesn't use a salt).
The is a security feature of Magento's hashing, and is meant to stop exactly the sort of thing you're trying to do.
In theory you could generate a rainbow hash table for each of the unique salts in the database, use this to crack your users passwords, and recreate them in Wordpress with a salt-less hashing. However, that's a non-trivial task if you're not familiar with the implementation of hashing algorithms, and would also take a significant amount of time.
The usual approach to this is to create new accounts in the new system, and then automatically email users a password reset link the first time they attempt to login (with additional messaging explaining things)
You could also look into changing Wordpress's login functionality — but that sounds like a different question.
Try this WordPress plugin. It allows to migrate customer passwords to WooCommerce. After finished the migration, just contact them and they will send you an additional plugin that allows your customers log in using their old passwords.
Plugin link: https://wordpress.org/plugins/nextcart-woocommerce-migration/
Tt works like a charm!
I am currently planning a project in which revision safety of the database data is important. This means: we want to be able to proof that the data in the database was not tempered with since it was imported - no user changed the value, no db admin logged into the database and changed it.
What is the best way to achieve this?
Till now, I like the idea of signing the database row best: I create a MD5 hash of all the fields in the row, then send it to a timestamping signing server (have a look on wikipedia) and store the created signature with the row. From this time on, we can prove that no one changed the row since this stamp was created.
Any better ideas? And, if you like the idea as much as I do, what timestamp server should I use and how can I access it? The Verisign Timestamp Server seems to be used a lot, but I could not find any documentation on how to use it "raw", e.g. without the Microsoft code signer tools etc.
Thank you!
Time stamp servers are usually not free-to-use.
Alternatively you may use an HMAC-MD5 (or HMAC-SHA1) instead and use a password that is only known to the authorized user. The password is of course not directly used, better via PKCS#5 or at least hashed with a seed. Without the password noone can verify or recreate the HMAC-MD5
I just realized that there is no best way to hide MySQL string connection password in my executable file, especially in JAR file. Even encrypting it in EXE would only slow down the process (although I'm not sure how much time would it take to get an encrypted password from an EXE file).
So, from my understanding, I need something in the middle that would do the add, edit, delete etc to the database. Seems like a job for REST API or maybe SOAP services.
My question is, which one should I use? Or should I use something else? I was thinking Zend Framework to create those REST APIs. Then, I would use Qt to create a desktop application to call those APIs. But if I proceed with REST, my application would be a 3 tier application. Wouldn't it be better if I just create a web application? Maybe I should just stick to desktop application call those APIs since the application is already finished and I just need to change from connecting directly to MySQL to calling those APIs to perform tasks rather than changing the whole application to a web.
Any advice would be very helpful. Thanks in advance.
UPDATE:
I'm looking for a security that would protect my MySQL password connection.
Obfuscator would only obfuscate the code, it won't hide my string database information which In my opinion can be easily found using grep after decompiling the JAR using tools like JAD.
About my application:
Using a centralized MySQL database
Thousands of user
Contains sensitive information
My client uses Linux and Windows
My server uses Linux
All access are done in LAN, no outside connection (from Internet etc)
My current solutions (comments please):
Using REST APIs (safer since MySQL password is in the server)
Using Qt with encryption to the password
It depends on what kind of security are you looking for. Is this to protect the application from the user? To protect the user's data from other users? To protect multiple users' data from one another? To protect the user's data from an attacker?
In a lot of applications there's nothing wrong with storing the database login credentials in plain text. In other cases, you might try:
encrypting a user-chosen database password using a reasonably strong algorithm, e.g. Blowfish, using a hard-coded key;
having the user provide the password and "log in" to the program each time;
storing the database password in plain-text, but encrypt the data using a hard-coded key;
same as the above, but encrypt each user's data using their own provided password;
same as 2 but store each user's data in their own database with their login info as the database credentials;
storing the data on a secure remote database that users have to log into to access via a SOAP API;
using the native filesystem permissions to protect the configuration file holding the login credentials;
same as #1 but rolling your own really elaborate key-generation system: e.g. run the machine SID or a hardware id through MD5 using a randomly-generated salt, and then using the result to encrypt the login credentials.
Remember, there's no such thing as perfect security, so whatever you settle on doesn't need to be unbreakable. It just needs to be tough enough to break to make the hassle of circumventing the security mechanism exceed the value of the data. So, for example, if the data is a list of the top scores in Minesweeper, then ROT13 would probably be enough.
Edit:
I just want to add that, even if you can't get around having to hard-code an encryption key in your application, there are obfuscators for Java, .NET, and most other popular languages/frameworks. One of the key uses of these tools is to hide sensitive hard-coded strings like encryption keys.
Edit 2:
Given the additional details about the app in question, only 1, 6 and 8 would apply in this case. And a SOAP API is more appropriate for #6 as George rightly pointed out.
I also want to mention that there are Java resource obfuscators that encrypt string literals. This is just one example.
It pretty much depends in what environment your app runs
a) db and client local
b) db and client in a local network
c) db is in the internet
my two cents:
a) I would create a single db user and wouldn't use a password but restrict acces to localhost
b) direct connect to the database is fine but I would each user have to login with his own password and grant only the permissions he needs.
c) It's a bad idea to allow mysql connections to a public server. In this case webservices would be a good solution.
Anyway if your case is b or c I would stick with a login dialog for the user.
Maybe you should have a look at this http://www.greensql.net/ tool.
It is like a firewall but for mysql/postresql
So you can deny anything and only allow queries you want to.
If you are using Java for implementing your database desktop application, I would recommend to use Java DB as the database. There is a few ways of securing it, and there are alternatives to having a password in the connection string. I would recommend to read Java DB Security - Security Features in Java DB Release 10.4
It is easy to deploy your application with Java DB, since you can have much of it embedded in the same jar file. I have used it in a Point of Sale application implemented in Java.