Proper handling of user information, how does ASP.NET do it?

Question

I've used ASP.NET MVC with entity framework (most recent of both) to extend an existing website's data model, but without changing user accounts and user authentication. Feel free to answer this by pointing me to other documentation or learning resources.

My question is: How does ASP.NET handle the passing of user credentials over the wire, the authentication of those credentials, and storing user account credentials? And, how would I do that myself 'manually', in terms of securing their information on front end, in transit, processing, and storage?

Security at the various stages:

Front End - No idea, but make sure forms are validated, I'm guessing? Is this the user's problem?

Transit - Use an encrypted protocol (HTTPS?), but I'm not sure how to set that up in terms of appropriate controller methods, views, and certificates.

Processing - Decrypt username/password to plaintext, hash both and find matching record in the user account table, overwrite or make sure plaintext variables aren't hanging around in code.

Storage - Only store hashes of username/password on the database.

Then once authenticated, create user-session/key that will expire at some point. Again, I'm not sure how to do this 'manually' with ASP.NET, but I know that it happens with the built-in/default login setup.

Answer 1

Front End

Data is not secure. Passwords are entered in an input with type "password", which will obfuscated the entered information (preventing over-the-shoulder style attacks). However, the plain-text value is exposed via JavaScript and can be read by keyloggers or other client-side malware. There's not much you can do about any of this. Ultimately, the end-user is responsible for the security of their machine.

Transit

Always, always, always use HTTPS. It's not foolproof, as was seen by the recent Heartbleed attack, but it's better than just sending everything plain-text over the wire with HTTP. Except for fundamental flaws like Heartbleed, with HTTPS, you need only worry about protecting your certificate's secret key. HTTPS is utilizes two-way encryption with secret and shared keys. The shared key is sent to the client allowing them to encrypt what it sends, but not decrypt, while the secret key allows the encrypted text sent by the client to be decrypted server-side. Hence, the need to protect your secret key.

As far as your controller actions go, if you want to enforce HTTPS only on the action, such that if the user can only access your login page, for example, at https://domain.com/login, rather than http://domain.com/login, you'd add the attribute, [RequireHTTPS]. This attribute can be added at the action level to protect just that action, at the controller level to protect all actions within that controller, or globally to force your entire application to be HTTPS only.

Processing

You do not manually decrypt the username/password. If you're using HTTPS, your application will be handed the already decrypted values by the web server. Dealing with plain-text in your application code is not problematic and is pretty much necessary. I suppose that if some malware running on your server could gain access to the IIS process in memory and decompile the machine code at runtime into to something usable where they could get at the plain-text password, etc., it would be possible to exploit this, but it's a non-trivial hack and would require your server to be severely compromised already.

Storage

Of course you only store hashes in persistent storage. These are created with one-way encryption, where you have a key and generally a randomized IV value. As long as you do not leak both the key and the IV, it is impossible to decrypt the stored value into the original string. The only vector for attack is collisions, where you essentially encrypt millions of different strings in different ways and check for a match against the target encrypted value. However, most modern encryption algorithms make this sort of attack nearly impossible, requiring even a supercomputing platform hundreds or even thousands of years to ever create a viable collision. Just stay way from MD5, which does regularly emit collisions and has entire blackhat databases devoted to matching up encrypted values to plain-text values.