Problems with Encrypted password

rfazendeiro

Centurion
Joined
Mar 8, 2004
Messages
110
hi to all,

I'm currently workin in a aplication that is requires user autentication. I'm using vs 2003 and access.

Now when i run my app the login form shows up for the user to input its username and password. If it's the first time that the user is loging in (the password is blank) a form shows up to allow the user to change his password.

When the user submits it's new password, the password is encripted and a query is submited, like the example below

Code:
UPDATE Utilizadores SET User_password='.w\"2HXՏ,1\0#~@MV_KTF*uXlhN[*\tЭ#\aE', User_reset=0 where User_id=1

to execute the query i use the following code

[csharp]
public static int ExecuteNonQuery(string query)
{
OdbcConnection cs;
OdbcCommand cmd;

try
{
cs = OdbcConnection connection = new OdbcConnection("APP");
cmd = new OdbcCommand(query, cs);
cs.Open();
cmd.ExecuteNonQuery();
cs.Close();

return 0;
}
catch(OdbcException ex)
{
MessageBox.Show("Método: ExecuteNonQuery\r\n" + ex.ToString(), "ERROR", MessageBoxButtons.OK, MessageBoxIcon.Error);
return -2;
}
}
[/csharp]


it's here that i get the error.
Code:
System.Data.Odbc.OdbcException:ERROR[42000][Microsoft][ODBC Microsoft Access Driver] Syntax error in string query expression ''.w\"2HXՏ,1'

The stange thing is the if i run the exact same query directly in access the query returns no error.

Can anybody help?
 
Somehow it seems like the ODBC-driver thinks the string ends at \0. Could it be that it treats those two characters as end of string delimiters?
If I were you I'd use a parameterized query instead of what seems like a concatenated statement.
There are lot's of threads here about parameterized queries

HTH
/Kejpa
 
I have had the same thing happen to me

What I do now is scrub my encryptions and force normal letters and numbers onto them

It might seem less secure and, in fact, it is, but there can come a day when you want to write your program into a Web app, and a minor inconvenience becomes a major heartache
 
Or use parameterised queries like kejpa suggested as this will not be any less secure, is more maintainable and isn't open to exploits such as SQL injections.
 
Back
Top