views:

128

answers:

2

Hi,

I'm trying to sanitize any data that's inputted by making sure the data is valid for a particular field (e.g. a name can't contain special characters/numbers etc..) However, I'm not sure what to do when it comes to a password field. Would I even need to bother with any sanitization as the password is simply hashed? If the user was to inject anything malicious via the password textbox, should I bother checking for anything suspicious? AFAIK, some users may (should!) have special characters such as '< >', which would normally trigger a potential attack alert. Should I just leave the password field unsanitized? Limiting input for passwords is a last resort for me, as I feel users should use all sorts of characters in their passwords.

Thanks

+3  A: 

As long as you are hashing it in your application, you should be OK.

A bit off topic considering you are using asp.net, but a notable exception to that would be if you are using PHP and MySQL and doing something like this:

UPDATE users SET password = PASSWORD('$pwd') WHERE userid = $uid

In that case you would want to sanitize $pwd first.

Eric Petroelje
Thanks for the reply. I'm using ASP.NET membership controls to do all this, so hopefully I won't have to do any manual password changes. Therefore, only the hash will ever be stored, which I guess means that there's no threat.
SSL
+2  A: 

If you're concerned about SQL Injection attacks, you should start using parametrized queries to interact with your database. As it's a business rule to determine what's valid characters to password, I wouldnt strip anything while my customer don't say so.

All other input should be sanitized, as they could also be displayed on your page output and could lead to XSS attacks.

Rubens Farias
SSL
bottom line is: its doesnt matter, as it always will replace < by <
Rubens Farias
That's a fair point and as long as I'm working on the project, that's fine. I'm just thinking in the long run, if the project changes hands, other developers may start interacting directly with the passwords and not encoding them in the same method which could cause some confusion. Although this is highly unlikely, I like to err on the side of caution.
SSL