For some reason MySQL is putting all passwords as the same even after md5 and using the password('$md5_password').
Let's say the password is abc123 the password stored in mysql is 11ab5e691dcc370b. But when I try to save a password of frogs the password stored is 11ab5e691dcc370b, which is the same. I have the same script on other databases and is working flawlessly.
The above would explain why no one is logging in unless I hard set the 11ab5e691dcc370b password. Then others can login.
The mysql user has full rights.
I used Google to reverse 11ab5e691dcc370b. It seems to be the hash of d41d8cd98f00b204e9800998ecf8427e, which is an MD5 of a blank string.
You might want to check the code that actually calls md5.
Assuming PHP based on the $md5_password in your question
Use double quotes or remove them completely.
md5($password);
If you use single quotes it will literally hash the string $password
md5('$password');
See this page on string literals http://www.php.net/manual/en/language.types.string.php#language.types.string.syntax.single
Related
SELECT * FROM Customers WHERE password LIKE '%%';
This statement is incorrect but is there a way to find password that start with '%','''','!',etc.
I am Trying to find password that start with any symbol in front ? How can I do that ?
Example Password :%$rk3d+R&
Note that you should not be storing clear text passwords in your customers table. Doing so exposes your site to significant risk, if someone ever finds a way to read your database table. Instead, you should always store an irreversible hash of the password in the customers table. Then, for user authentication, hash a user's input password and compare against the table.
That being said, the % has a special meaning when used inside a LIKE expression, and it means any number of characters. You may escape it via a backslash in this case to mean a literal % symbol:
SELECT * FROM Customers WHERE password LIKE '\%%';
More generally, to find customers having passwords starting with any symbol, use REGEXP:
SELECT * FROM Customers WHERE password REGEXP '^[##$%^&*]';
You need to escape the special character here like below.
SELECT * FROM test where password like '\%%';
Demo DBFiddle
Is there any way to encrypt only data that are not encrypted yet?(Is there any way you can tell encrypted and non-encrypted data apart?)
Please assume that I have a column that some data are already encrypted but some are not.
Code for encrypt
update usersExample3 set password=aes_encrypt(password,'1234');
I have a stored procedure that I have to fix it but not sure how:
DELIMITER //
CREATE PROCEDURE de ()
LANGUAGE SQL
DETERMINISTIC
SQL SECURITY DEFINER
COMMENT 'A procedure'
BEGIN
while(there is any not encrypted data in the table)
--if(usersExample3.password is not encrypted yet)
update usersExample3 set password=aes_decrypt(password,'1234');
--else (do nothing)
END//
;
Sample of my database:
select * from usersExample3 where userId<=5;
userId username password salt
1 Tom Password1234 NULL
4 bdfg θ¨¾jj;öN/yë‘ bcv
5 test test test
So here I want to update all data that are not encrypted yet(in this sample are userId 1 and 5.
the problem is that everyone add data in database so when data saved in table, I have a trigger(after insert) that call this stored procedure to encrypt the new data automatically.
Thanks
In the general case - no, you can't tell encrypted and non-encrypted data apart. Buuut, looking at your example, perhaps we can come close. The non-encrypted passwords will have "normal" characters that people can type on their keyboards. The encrypted ones will have all sorts of binary junk that doesn't make sense. So the first idea is to simply check if the password has characters with ASCII codes <32 or >127.
However this is not fool-proof yet. Sometimes people use more complicated characters too. If someone enters Glāžšķūņu rūķīši as their password, it's still legit words in some language (Latvian in this case) but you'll probably think it as encrypted.
Which brings us to the question - what is the character set of the column? And this is one place which looks suspicious to me from the start, because how are you storing both normal text and binary junk in there? Smells like someone doesn't understand characters sets, because doing this would under normal circumstances create a big mess.
Anyway, in case it's utf-8 text stored in a latin-1 column (a common situation), you can actually use it to your advantage for now - all the cells that are not a valid utf-8 string (plus those that have characters <32) will be encrypted.
(However if this really is the case, I strongly advise you to fix it soon and ensure that utf-8 is used EVERYWHERE from the beginning to the end. MUCH less headache that way. Here's mandatory reading about the whole character set thingy)
I need to update my records. I want to change our plaintext passwords into MD5 encoded passwords. This is what I tried to use:
UPDATE testing SET password = MD5('Manojano234')
This query was working for the string I put in there, but I need to be encoding the password and not just that one string
This is really what you want to do. Appending a MD5ed salt to and MD5ed password is not the way to go. An attacker would see that there are two MD5ed strings concatenated together, as the last part of every password would be the same. Appending them and then MD5ing is the way to go. Use this:
UPDATE testing SET password = MD5(CONCAT(password, 'A Custom Salt You Pick'));
You have to write something like this:
UPDATE testing SET password = CONCAT(MD5(password), 'plain text')
You can write your query like :
UPDATE testing SET password = CONCAT(MD5(password), MD5('Your plain text')) WHERE "Need to write your condition to update this record"
This is one way to convert your plain text passwords into MD5 passwords. I am also appending a salt.
UPDATE testing SET password = CONCAT(MD5(password), MD5('plain text'))
this is the password :
sha1$265b1$5ff32d53cf53bdef243b6f83e33e513514352406
sha1$73f58$b037706983a566e2a2b4bab7ef062c2e84f4a33e
this two string's password all are '123456',
but why they have different string ?
thanks
Until django 1.3 was for "salt" the raw password:
The password attribute of a User object is a string in this format:
hashtype$salt$hash
That's hashtype, salt and hash, separated by the dollar-sign character.
Hashtype is either sha1 (default), md5 or crypt -- the algorithm used to perform a one-way hash of the password. Salt is a random string used to salt the raw password to create the hash.
But after django 1.4 the "salt" part isn´t recorded in the database and it uses another algorithm by default.
As stated in the Docs, django uses a salt to hash the password. The salt is the few characters between the 2 $, so technically you can update 1 of those rows with the other value.
For more regarding salt-hashing see This question
that decide to your algorithm, some algorithm's results are not same
Does MySql 5.1 and SQL Server 2008 (Web edition, Standard) have any functional password limitations other than length limits? Are metacharacters in any form a bad idea to use, like bang, pipe, hash, any slash, carrot, and so on?
I know that MySql 5.1 has a password length limitation of 16 characters that is hardcoded, but I was wondering, are any metacharacters (i.e. non alphanumerics) a bad idea to use? And is this true in SQL Server 2008 Web edition, Standard?
So specifically: can symbols like:
/`~>:}{[]^ be used successfully?
I would hope it doesn't matter to the database, but I don't understand enough about password storage in enterprise database systems yet to know for sure, and I was looking for confirmation or an explanation.
All these characters are good in SQL Server passwords, but the docs to back it up are sketchy.
The MSDN documentation on SQL Server password strength implies that any symbol including whitespace characters is allowed in SQL Server passwords, but if it contains white space it must be delimited in T-SQL statements.
Microsoft SQL Server passwords can contain up to 128 characters, including letters, symbols, and digits. Because logins, user names, roles, and passwords are frequently used in Transact-SQL statements, certain symbols must be enclosed by double quotation marks (") or square brackets ([ ]). Use these delimiters in Transact-SQL statements when the SQL Server login, user, role, or password has the following characteristics:
Contains or starts with a space character.
Starts with the $ or # character.
The MSDN documentation on password policy explicitly confirms the following characters are allowed: ! $ # %
And, as you'd already know, the same documentation strongly encourages that you use passwords which are "as long and complex as possible."
mysql> create user test identified by '/`~>:}{[]^';
Query OK, 0 rows affected (0.13 sec)
yes - you can actually login now with this command line:
C:\Documents and Settings\rbouman2>mysql -utest -h127.0.0.1 -P3351 -p
Enter password: **********
I tried entering the password directly after -p, but that didn't work for windows - it thinks i want to invoke more if I do that. but I am 100% sure that's on the windows shell. MySQL itself feels this is a valid password.
In my experience, it's the backslash \ and the single quote ' that you'll want to avoid in a MySQL password. From my tests, the following special characters appear to be fine to use:
!##$%^&*:./?=+-_[]{}()<>
Also, 32-character passwords seem to be okay to use, too.
Watch out, even though MYSQL may work, your php/http daemon/.htaccess may do some wierdness to the req's before passing them along, I had a password with ( $ and ! in it, and it did NOT work from php-mysql based web page, but DID work from the console... 8 character password. $db_pass = "($JlKl1!";
And what do you know, it fails.
change the password to "test" . and bam, it works.
Change the password to something ridiculously long, (and entirely devoid of "$" or "!" or "(" ) and it also worked.