Let's say we are setting up some registration form for some website. I know that if input fields aren't sanitized then SQL injection can happen. But let's say all fields are sanitized correctly.
Is there any advantage to having alphanumeric-only usernames? Or is it just as good to allow any symbol?
If you allow any sequence of bytes as an username, you'll get a lot of possible problems users can abuse, and other issues:
For unicode, the same character sequence can be represented as different byte sequences. You'll have to do Unicode normalisation in order to get at least some security against people being able to register another byte sequence representation for some username.
Users can chose similar looking characters (e.g. use two spaces instead of one, etc.) in order to fool people into believing it's some other account.
Users could include the / character inside their name, and change links to pages related to their account (e.g. you assign account urls to http://example.com/user/username, and your code splits by /).
Most sites drive the approach that they assign two values for a user: first, a "technical ID", which is alphanumeric, and a second "full name", which can contain spaces and other symbols. The alphanumeric ID has to be unique, and the "full name" can contain duplicates over your site.
If you are concerned about a text field being abused to perform SQL injection, then input sanitation is not the correct solution to be looking for.
If the text field was completely free form, then every character which could be used for SQL injection would be valid input. If you try to avoid SQL injection by sanitizing inputs, you end up rejecting valid inputs. In other words, you may have avoided SQL injection, but you did so by introducing an additional bug not by fixing one. From the user's point of view, there are at least as many cases of valid input not working as before, maybe even more cases than before.
The proper solution to avoid SQL injection is to use escaping or parameterized expressions (which avoids injection at one layer of the protocol stack by moving the responsibility to a lower layer).
As long as you do escaping correctly in all places, there is no technical reason it wouldn't be possible to let the username field be a free form text field.
There is a different question about what characters to permit in usernames. Though it is technically possible to support free form usernames, it is not necessarily a good idea. There are sound arguments for limiting the set of characters permitted in usernames, but those arguments have nothing to do with SQL injection.
Limiting usernames to only ASCII characters is useful if they ever need to be communicated through channels where you are unsure about encoding.
Limiting usernames to characters which are located in the same location on different keyboard layouts is useful if you are working in an international environment. But I wouldn't enforce such limitations in software, because the set of keyboard layouts used by each user differs.
Preventing usernames which are visually identical can be a good idea in systems where it is important to be able to recognize a username. This means no non-printable characters. And if two characters look the same only permit one (this is rarely an issue if you stick with only ASCII characters). And spaces cannot be permitted at the start and end of the username, neither can two spaces next to each other be permitted.
And remember that restricting which usernames are permitted is not a substitute for generating your SQL safely.
For usernames fields it is not necessary to use alphanumeric-only but you should be careful on blacklisting some special characters like ' and " on input validations.
For Password fields it is must to use alphanumeric and some special characters like @ and # for making our password so strong.
For example it should be in Abc@123# and it should not be in abcd, because if you use weak password it is possible for a attacker to hijack using Brute Force attack
Username can be : abc123, but it is must to validate.
