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.
Related
I am using Visual Studio 2008 and Access 2013 as my database.
When I use special characters in a password field, my VB.Net code produces an SQL query error, especially when I am using a special char at the last chat.
For example, if I use jdjdj' as the password then an error occurs.
Normal passwords work. For example:
Admin123
123admin
123
admin
Where is the problem and how can I fix it?
You need to pass the password to the query as a parameter rather than concatenate it into the query string.
It doesn't just stop issues like this, it's also to stop malicious users deliberately taking advantage of your shortcut, to easily gain access to the database.
Check out How do I create a parameterized SQL query? Why Should I?
I was tasked with moving an installation of Orchard CMS to a different server and domain. All the content (page content, menu structure, links, etc.) is stored in an MSSQL database. The good part: When moving the physical files of the Orchard installation to the new server, the database will stay the same, no need to migrate it. The bad thing: There are lots and lots of absolute URLs scattered all over the pages and menus.
I have isolated / pinned down the tables and fields in which the URLs occur, but I lack the (MS)SQL experience/knowledge to do a "search - replace". So I come here for help (I have tried exporting the tables to .sql files, doing a search-replace in a text editor, and then re-importing the .sql files to the database, but ran into several syntax errors... so i need to do this the "SQL way").
To give an example:
The table Common_BodyPartRecord has the field Text of type ntext that contains HTML content. I need to find every occurance of the partial string /oldserver.com/foo/ and replace it with /newserver.org/bar/. There can be multiple occurances of the pattern within the same table entry.
(In total I have 5 patterns that will need replacing, all partial string / substrings of urls, domains/paths, etc.)
I usually do frontend stuff and came to this assignment by chance. I have used MySQL back in the day I was playing around with PHP related stuff, but never got past eh basics of SQL - it would be helpful if you could keep your explainations more or less newbie-friendly.
The SQL server version is SQL Server 9.0.4053, I have access to the database via the Microsoft SQL Server Management Studio 12
Any help is highly appreciated!
You can't manipulate the NTEXT datatype directly, but you can CAST it to VARCHAR(MAX), then use the REPLACE function to perform the string replacement, then CAST it back to NTEXT. This can all be done in a single UPDATE statement.
update MyTable
set MyColmun = cast(replace(cast(MyColumn as nvarchar(max)), N'/oldserver.com/foo/', N'/newserver.org/bar/') as ntext)
where cast(MyColumn as nvarchar(max)) LIKE N'%/oldserver.com/foo/%'
The WHERE clause in the UPDATE statement below is used to prevent SQL Server from making non-changes, i.e. if the value does not need to be changed then there is no need to update it to itself.
The CAST function is used to change the data type of a value. NTEXT is a legacy data type used for storing large character values, NVARCHAR(MAX) is a new and more versatile data type for storing large character values. The REPLACE function can not operate on NTEXT values, hence the need to CAST it to NVARCHAR(MAX) first, do the replace, then CAST it back to NTEXT afterwards.
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));
I have an old access database that I have converted to Office 2010 format and then moved the one data table to SQL. There is only one form that is associated with the one linked table.
Once it was all done I compared the data from before and after and found that all the ≤ had been converted to =. I had mistakenly set the field as varchar so I updated it to nvarchar. I then inserted some corrected data via SQL Server Mgt Studio and all looked good.
The issue is that if I enter ≤ symbols via access they look fine, but once I close and reopen the front end they aren't there. They seem to be being converted to = when access writes to the sql back end table.
My research says that it may be that the ODBC connection is stuffing up the Unicode character, but then other places say it should be fine. I am not doing the update via sql so I can't try the N in front of unicode text.
Any suggestions?
The comment from Gord was right on the mark. When you make changes to the SQL table in the back end Access will not update the linked table. You need to remove it and re-add it.
Just use the same name as before and everything will work fine.
We currently use the SQL Publishing Wizard to back up our database schemas and data, however we have some database tables with hashed passwords that contain the null character (chr(0)). When SQL Publishing Wizard generates the insert data scripts, the null character causes errors when we try and run the resulting SQL - it appears to ignore ALL TEXT after the first instance of this character in a script. We recently tried out RedGate SQL Compare, and found that it has the same issue with this character. I have confirmed it is ascii character code 0 by running the ascii() sql function against the offending record.
A sample of the error we are getting is:
Unclosed quotation mark after the character string '??`????{??0???
The fun part is, I can't really paste a sample Insert statement because of course everything that appears after the CHR(0) is being omitted when pasting!
Change the definition of the column to VARBINARY. The data you store in there doesn't seem to be an appropiate VARCHAR to start with.
This will ripple through the code that uses the column as you'll get a byte[] CLR tpe back in the client, and you should change your insert/update code accordingly. But after all, a passowrd hash is a byte[], not a string.