C# Get Username and password from the Client using sockets ?

Yes. Of course, there is no such function as SHA256, there is a class I referenced in my past answers.
I hope you are pretty close now and will later accept my answer formally (green "Accept" button). If you have more follow-up questions, you are welcome to continue this discussion.
—SA

Yes, there are some options.
First, instead of raw sockets, it's much more convenient to use the classes TcpClient/TcpListener. See also my past answers:
http://www.codeproject.com/Answers/536542/anplusamateurplusquestionplusinplussocketplusprogr#answer2,
http://www.codeproject.com/Answers/165297/Multple-clients-from-same-port-Number#answer1.

Performance won't suffer, but they are easier to use; you will use just the streams. Note my recommendations on threading above.

Also, you can define any thinkable data structures and transparently pass them using serialization. If text data (actually, XML or JSON) is fine (traffic is not a great issue), the most convenient serialization ever is using Data Contracts:
http://msdn.microsoft.com/en-us/library/ms733127%28v=vs.110%29.aspx.

(Yes, they came with WCF, but they absolutely don't require you do use WCF.)

—SA

Also, don't use ASCII, use UTF8, otherwise a user using Unicode (all .NET application will let the user enter Unicode) will get into big trouble.
Besides, depending on what you are using in other messages, you might consider using, say, BinarySerializer instead.
Also, if the messages are very long, you can consider compression.
—SA

Well, there are many ways to screw up things. Again, never compare password to password. Compare hash with hash.
—SA

This is a pretty bad answer.
And I already explained: don't use ASCII with .NET (except some rare special cases).
For persistence and networking where some text is involved, always use UTF8.

As I say, there are many ways to screw up things.
Is the problem with username (no hash), or with password (with hash)?
Whatever it is could you create two separate functions and show some round-trip (without network):
1) Take user input, serialize to arrays of bytes, put to stream;
2) Get from stream, deserialize to string.
A stream could be a file, for now...
—SA

No, not something I could immediately present and show...
We are now addressing a different problem, trying to find a bug in your code. And then, a little fix. You already done some round trip, the question is: how?
—SA

Start learning serialization, consider Data Contract. This is quite easy.
—SA

This is not a "packet struct". This is serialization of some class/struct. You define it and claim serializeable (say, add attributes). Then you tell a serializer to serialize, get array of char, put to string. And visa versa.
—SA

Yes, but you need Serializeable attribute. You will find a lot of samples.

It could be simpler:

[DataContract]
struct Login {
[DataMember] internal string Username { get; set; } // no need to make it public, can even be private
[DataMember] internal string Password { get; set; }
//...
}

—SA

It might work, but I don't understand why so complex? You already had a sample with serializer...
—SA