Question

Working on a login system - the point where customer chooses their password for site access.

Beyond using RegEx to ensure that the password is strong enough, normally on our system all data that will wind up in the database is checked against injection etc and a reasonably restricted character set is enforced on all fields. I don t really want a particularly restrictive character set for the password, as I think it is a bit of an anti-pattern on security to control it too much.

However in the case of the password, I ll be hashing it with a salted SHA-512 for insert anyway which raises a handful of questions:

Is there any point whatsoever in restricting the character set that the customer can use in the password - ie am I exposed to any vulnerabilities outside of injection which I am assuming would be circumvented completely by the hashing?
There must be negatives to an allow-all approach - I can think of the fact that in the future what is an innocent combination now could become a dangerous one - is that a real concern, and are there others I may have missed?
Are there any characters/strings that must be rejected - would they get through the native ASP.NET protection anyway?
A bit more subjective maybe, but given it is a SHA-512 hash - is there any point in restricting the maximum length of password that the user can choose (within reasonable parameters), assuming that a password of significant size/complexity could raise a warning to confirm that they do want to set it.

Thanks for your help.

EDIT: This is an ASP.NET web application accessing a MSSQL2008 database using ADO.NET (not LINQ/EF).

Answer 1

There is little reason to worry about SQL insertion attacks unless you re actually inserting the password into the database in plain text (Danger, Will Robertson, Danger!) and even then if you paramaterize the query it won t be an issue. You should allow [a-zA-Z0-9] plus some set of special characters. Probably the only character to restrict is < which will trigger the ASP.net validation warning. There are a number of fun tools out there to do password complexity checking on the client side. I like this one. It provides some instant feedback to the user as they are typing.

Answer 2

From a non-English perspective - there should be no restrictions on the password.

For example, why restrict a Japanese-language speaker to using the US-ASCII character set? And why should a French speaker not use accented characters?

Given that your hash is persisted correctly there s no technical reason to restrict it.

Answer 3

Since the password is hashed, it will be stored in the database in hex decimal format. Therefore, I see no point of restricting the type of allowed characters. If I wanted to use a Chinese letter in my password, I should be able to do so. If I have installed an extension for Firefox that generates random bytes and uses those for my passwords, I should be able to do so. The lesson here is to not limit your users passwords.

Also note that RegEx has a unicode support that is capable of detecting if the user has used a letter of any languages. That might become handy when you are validating the strength of the password.

友情链接