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.
Related
I'm using the MySQL Command Lind Tool on MacOS using the command: mysql -u root -p;
To avoid repetition and to save time, I tried using TextEdit (MacOS's Notepad counterpart) to type queries and then copy them into the MySQL command prompt.
Here I noticed a problem when I was copy-pasting syntactically correct queries.
e.g. select * from club where COACHNAME=‘coolname’;
I finally found that the problem was with the apostrophes.
In any text editor, the apostrophes are tilted in different directions: ‘See the left and right tilted apostrophes on both sides’
But the same doesn't take place in the terminal, or in MySQL (not sure whose default it is).
Wherein the same apostrophes are used for both the start and the end: 'Notice the un-tilted and uniform apostrophes on both sides'
Hence when I was copy pasting: select * from club where COACHNAME=‘coolname’;
I was meant to change the titled-apostrophes to the uniform kind that are built-in, i.e.
select * from club where COACHNAME='coolname';
You can even notice that the apostrophes on Stack Overflow by default are the uniform kind,
whereas those in TextEdit and Notes (and maybe also in Notepad, if somebody could confirm that) are the tilted kind.
Im limiting my clients from entering certain characters.
Right now I allow:
All the numbers
All the english letters
-
_
I do not allow:
'
"
;
What other safe characters and/or unsafe characters exist when doing a query via programming using a textbox or such?
The safest way to work with any SQL (MySQL included) is to use parameterized queries. This will allow your clients to enter any characters they want and prevent any SQL injections.
You didn't mention what language you are working with so here's a .NET example for working with MySQL: http://dev.mysql.com/doc/connector-net/en/connector-net-tutorials-parameters.html
I have encrypted data in a mysql table stored as a text field.
Everything was originally written in Windows perl and that still works without issue.
My problem is that I am running the same code on Linux and when I query the table the text result in perl tells me it is longer (which causes my decryption to blow up since it is too long).
This happens running the same script so I know there is not a code difference.
Mysql server is 5.1.63 running on OpenSuSE Linux 11.4 x64.
Linux perl is v5.12.3
Windows perl is 5.10.1
The field in question is defined as text, utf8_general_ci and when I access it via JDBC the data reports 128 bytes,
the SQL in question is simple (pruned down to just what matters here)
my $gatherSQL = "select
table.encryptedText from action.theTable table
where table.custno=" . $dbHandle->quote($custno)
my $getHandle = $dbHandle->prepare($gatherSQL);
$getHandle->execute();
my $arrayRef = $getHandle->fetchall_arrayref();
foreach my $myrow (#$arrayRef)
{
$type = $$myrow[0];
}
$getHandle->finish();
#DB Handle is opened with a simple
my $workSQLhandle = DBI->connect("dbi:mysql:$dataDB:$dataServer:$dataPort", $userToUse, $pwToUse);
return($workSQLhandle);
When I run the code in Windows (through a samba share) I get a length of the field of 128 (which decrypts)
Same code on the same machine run from a command prompt tells me the same return string is 193 chars long (and won't decrypt)
I did a compare of the results coming back and they are identical but perl tells me one is longer than the other.
Any thoughts on how I can address this and what the root cause is?
check if perhaps mysql/perl are doing some translations on the text. e.g select length(table.encryptedText) to see what mysql thinks the length is. encrypted text tends to look like binary garbage, and if you're storing it in a TEXT-type field, it WILL be subject to automatic charset translation. encrypted data should go into BLOB fields, which are otherwise identical to TEXT, but are NOT charset-sensitive.
I am concerned about inserting text in a MySQl table w.
I have to insert/update text that contains characters such as / " and '
The escape character / could be inserted only if the NO_BACKSLASH_ESCAPES SQL mode is enabled. wich interfere with the characters " and ' see this link http://dev.mysql.com/doc/refman/5.1/en/string-literals.html#character-escape-sequences
If anyone can explain to is in earth the mysql_real_escape_string() I don't came to understated
I would like to find a pure mysql solution
I am not using php. What I am trying to do here is to "simulate " Content Management System: I am about to write a C# coded solution that manage the content in its different forms(article, category ,tag, etc..) and generate .html files, the MySQl database is local in my computer next i will upload the .html files to the server.
I did this to ensure that all my html pages are html valid and because I don't trust any existent solutions (not only when it concerns coding but in life in general)
Please help
each php db connection extension (mysql, mysqli, pdo) has a special way to safe query against sql injections, when you are using mysql extension, it's strongly recommended to use mysql_real_escape_string() function to make safe all variables used in query, it's most widely used function. i think there isn't any pure solution (when you are using mysql extension in php).
from php.net:
mysql_real_escape_string()-Escapes special characters in the
unescaped_string, taking into account the current character set of the
connection so that it is safe to place it in a mysql_query().
Whatever string data can be inserted into SQL query, if formatted according to 2 rules
it is enclosed in quotes (preferably single ones)
it is passed through mysql_real_escape_string()
if both rules followed, there would be not a single problem with whatever characters, either slashes, quotes or anything.
According to your question, / has no special meaning in MySQL. It's \ that is escape character. It can be escaped by another backslash as well.
$str = 'slashes \ quotes \' or whatever " else symbols';
var_dump($str);
$str = mysql_real_escape_string($str);
$sql = "INSERT INTO table SET str='$str'";
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