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).