I have a web application done in ASP.NET MVC 4. It has users, that are stored in SQL Server database in tables webpages_UserProfile and webpages_Membership, etc.
I have another application, and what I need to do is to query the table webpages_Membership, where password of users are stored encrypted, and compare them to a plain text password.
So I tried doing something like
SELECT *
FROM webpages_Membership
WHERE PwdCompare('mypasswordsend', Password) = 1
But it doesn't works. I know the column is a nvarchar(128).
How can I compare it?
Let's look at the second argument to PwdCompare (emphasis mine):
password_hash
Is the encryption hash of a password. password_hash is *varbinary(128)*.
So, if your column is storing the password in plain text, or is storing a string representation of the binary hash, it's not going to work. You should either change the column to be correct or you will need to convert it first, e.g. check this script:
SELECT PWDENCRYPT(N'mypassword');
Yields:
0x0200D422C0365A196E308777C96CBEF3854818601DDB516CADA98DBDF6A5F23922DC0FADD29B806121EA1A26AED86F57FCCB4DDF98F0EFBF44CA6BA864E9E58A818785FDDEDF
If we try to compare that value as a string, we get 0:
SELECT PWDCOMPARE(N'mypassword', N'0x0200D422C0365A196E308777C96CBEF3854818601DDB516CADA98DBDF6A5F23922DC0FADD29B806121EA1A26AED86F57FCCB4DDF98F0EFBF44CA6BA864E9E58A818785FDDEDF');
If we try to compare it as a varbinary value, we get 1:
SELECT PWDCOMPARE(N'mypassword', 0x0200D422C0365A196E308777C96CBEF3854818601DDB516CADA98DBDF6A5F23922DC0FADD29B806121EA1A26AED86F57FCCB4DDF98F0EFBF44CA6BA864E9E58A818785FDDEDF);
If you can't fix the table, then you can perform this expensive explicit conversion in your query every time (note that the trailing ,1 is important):
SELECT PWDCOMPARE(N'mypassword',
CONVERT(VARBINARY(128), N'0x0200D422C0365A196E308777C96CBEF3854818601DDB516CADA98DBDF6A5F23922DC0FADD29B806121EA1A26AED86F57FCCB4DDF98F0EFBF44CA6BA864E9E58A818785FDDEDF'
, 1));
Related
I don't know how to explain but I'll try, into my database in a table, I have one record with many fields.
The username field, for example, contains the value = 'any-user-test' but if I execute a "SELECT" clause and in the WHERE section I compare username='any-user-test' the result does not contain the record.
But if I compare using username LIKE '%any-user-test' the record is returned.
And as further proof using:
WHERE CONVERT(username USING ASCII) = 'any-user-test'
the record is returned too.
The database is MariaDB in a server Ubuntu using encryption and CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci.
Any idea how to identify the problem?
I have a db2 database where I store names containing special characters. When I try to retrieve them with an internal software, I get proper results. However when I tried to do the same with queries or look into the db, the characters are stored strangely.
The documentation says that the encoding is utf-8 latin1.
My query looks something like this:
SELECT firstn, lastn
FROM unams
WHERE unamid = 12345
The user with the given ID has some special characters in his/her name: é and ó, but the query returns it as Ă© and Ăł.
Is there a way to convert the characters back to their original form with using some simple SQL function? I am new to databases and encoding, trying to understand the latter by reading this but I'm quite lost.
EDIT: Currently sending queries via SPSS Modeler with a proper ODBC driver, the database lies on a Windows Server 2016
Per the comments, the solution was to create a Windows environment variable DB2CODEPAGE=1208 , then restart, then drop and re-populate the tables.
If the applications runs locally on the Db2-server (i.e. only one hostname is involved) then the same variable can be set. This will impact all local applications that use the UTF-8 encoded database.
If the application runs remotely from the Db2-server (i.e. two hostnames are involved) then set the variable on the workstation and on the Windows Db2-server.
Current versions of IBM supplied Db2-clients on Windows will derive their codepage from the regional settings which might not always render Unicode characters correctly, so using the DB2CODEPAGE=1208 forces the Db2-client CLI drivers to use a Unicode application code page to override this.
with t (firstn) as (
values ('éó')
--SELECT firstn
--FROM unams
--WHERE unamid = 12345
)
select x.c, hex(x.c) c_hes
from
t
, xmltable('for $id in (1 to string-length($s)) return <i>{substring($s, $id, 1)}</i>'
passing t.firstn as "s" columns tok varchar(6) path '.') x(c);
C C_HEX
- -----
é C3A9
ó C3B3
The query above converts the string of characters to a table with each character (C) and its hex representation (C_HEX) in each row.
You can run it as is to check if you get the same output. It must be as described for a UTF-8 database.
Now try to comment out the line with values ('éó') and uncomment the select statement returning some row with these special characters.
If you see the same hex representation of these characters stored in the firstn column, then this means, that the string is stored appropriately, but your client tool (SPSS Modeller) can't show these characters correctly due to some reason (wrong font, for example).
I have an sql server script which inserts known fixed guid values into a table. It looks like:
INSERT INTO MyTable (ID)
VALUES ('BBD098BF-58F0-4A84-90C2-F806D6D06061')
Note that guid is in human-readable form.
Since ID is uniqueidentifier sql server understands how to convert a string to guid data type.
I need to make the same script for Oracle, ID is of RAW(16) type. Taking the script directly doesn't work because Oracle interprets a string just like a binary, it should be some "other" string, a string representation of a correct binary chunk.
Does anyone knows a way to convert human-readable sql server string to a string required by Oracle?
So far I can only think about saving a guid to Oracle in .net code, for example, and than making a select in oracle script to get a string. But this is crazy.
Thanks!
According to this link
Sqlserver reverses the 3 first sections so you need to do:
hextoraw(substr(guid,7,2)||
substr(guid,5,2)||
substr(guid,3,2)||
substr(guid,1,2)||
substr(guid,12,2)||
substr(guid,10,2)||
substr(guid,17,2)||
substr(guid,15,2)||
substr(guid,20,4)||
substr(guid,25,12)
)
(guid is like 'BBD098BF-58F0-4A84-90C2-F806D6D06061')
I currently have a database schema that contains a user's password in plain text. I've added a new column called password of type binary(16) with the intent of hashing the current plain text password via MD5. When I do this, I'm finding that the value stored in the password field is wrong. Here's my conversion query:
UPDATE my_table SET password=HASHBYTES('MD5', plain_text_password);
For one of my records, the plain text password is asdf. The correct MD5 value of this is 0x912ec803b2ce49e4a541068d495ab570. However, the record is being updated to 0xEC81AFD2DF2BDA47850F9182F4AC300D instead.
Has anyone every seen issues like this before? I'm using SQL Server 2008.
Update:
Thinking about this a little more, I converted the plain text password field from varchar(MAX) to varchar(50). It displays the same way within SQL management studio, but I'm wondering if the underlying encoding from when the data was in varchar(MAX) format somehow got copied over to the new varchar(50) format, causing the discrepancy.
So I figured out what was going wrong here. After I converted all the plain-text password fields (or perhaps this was true all along, I'm not sure) a bunch of \0's were appended to the end of the field. So instead of the word 'apple', it was 'apple\0\0\0\0\0'. SQL Management studio doesn't show these \0's, but the Visual Studio debugger did. After removing all the trailing \0's, my problem goes away.
The website i worked was recently attempted to be hacked by the following SQL injection script
boys' and 3=8 union
select 1,
concat(0x232425,ifnull(`table_name`,0x30),char(9),ifnull(`table_rows`,0x30), char(9),0x252423),
3,4,5,6,7,8,9
from `information_schema`.`tables`
where table_schema=0x62646B3032 limit 44,1 -- And '8'='8
This injection returned the mysql table name. This was reported by the error reporting system on that website and we managed to fix that part however I am not able to understand what does the above injection mean?
Anyone can explain this?
Penuel
They're using a select from the Information Schema views in mysql server :
http://dev.mysql.com/doc/refman/5.0/en/information-schema.html
They use some clever hacks to rout out simple sql injection prevention techniques.
According to this the MySQL concat()
Returns the string that results from
concatenating the arguments. May have
one or more arguments. If all
arguments are nonbinary strings, the
result is a nonbinary string. If the
arguments include any binary strings,
the result is a binary string. A
numeric argument is converted to its
equivalent binary string form
So 0x232425 is converted to #$% which is simply added to the begining and end of the table_name field. Maybe just to make it easier for them to pull out the Table names later using Regex.
Later on the char(9) is equivalent to a tab as you can see here and is just there to format the output nicer.
The 3,4,5,6,7,8,9 is just there so that the columns match the boys table that they are performing the Union on.
This injection returned the mysql table name.
Do you mean that your website displayed the table name when you gave it this input, or that the query returns that when run from the mysql client? If it showed on your website, then the attacker has the ability to inject much more harmful queries. Check your data.