@ton.yeung If you use the stored bcrypt hash has the HMAC key, then what the server stores is sufficient to fool the server. This allows an attacker to escalate a read-only breach (e.g. stolen backup tape) into a read-write access. That's not necessarily a good thing.
what are you trying to achieve ?
I mean, what security property are you after ?
You use HMAC to prove... what exactly ?
@ton.yeung Anyway, regardless of how you do the authentication part, you need to make sure that the requests sent by the client are not surrepticiously altered by some evildoer.
So the authentication and the requests must go through some sort of armored transport mechanism
Once you have SSL, you may as well use it fully, and let it handle all this HMAC business.
@ton.yeung SSL uses HMAC to make sure that transmitted data is not altered.
When you have a SSL session and have performed some sort of authentication within that session (e.g. client showed the proper password), then SSL guarantees you that all subsequent data sent through that session comes from the authenticated client. You don't have to recompute some extra HMAC for every message from the client; SSL already does that for you.
Since the general concept of SSL has already been covered into some other questions (e.g. this one and that one), this time I will go for details. Details are important. This answer is going to be somewhat verbose.
History
SSL is a protocol with a long history and several versions. First protot...
@ThomasPornin Are you aware if there's any institution in QC that specializes in offering education security-wise? Perhaps a certificate or something like that?
@ton.yeung With IIS, the normal way of doing things is to configure only SSL for your application, so everything which reaches your application has necessarily gone through SSL. And you let IIS handle the authentication anyway.
@ton.yeung I don't watch videos from this machine (bandwidth goes through a 3G phone, it is expensive)
ASP.NET offers an extra layer to protect your application from XSS attacks and injection in general which is called Request validation.
On their official topic, they mention that:
Even if you're using request validation, you should HTML-encode text that you get from users before you display ...
@Simon That's theoretically valuable, but only if you know what it's doing and what it's not doing. It certainly couldn't be considered protection against anything.
Kind of like the "data firewall" idea Rasmus Lerdorf has been trying to push. A general inspection of input data simply doesn't cut it for an output-related attack. It can't be made to work as a general solution, but might protect against very specific attacks.
@Simon Didn't read what it's supposed to do but I doubt it has anything to do with MS features ... if anything, then rather lack of them. If you don't HTML-encode output then chances are greater input that properly escapes sanitizer will still be malicious (there's literally gazillion of ways to achieve that). Problem is, MS prolly thought they can't possibly protect from all types of exploits and not cause it to be only usable in rare few cases, so they add the notice to it.
@Simon How can you be too tired at 5 pm? Aren't you supposed to be young and all that? And you're here so I'm pretty sure you didn't have too much sex either :O
@Simon I imagine the function exists because it was useful for some internal team, but they don't intend to update it because they know doing so would be a battle they can't win.
@Simon that's request validation... you can't validate all on input and not expect it to cause other problems, that's why you have to have certain output validation in place also, that's where HTML-encoding comes in play (or possibly other ways, depending on what you need the output for). I wouldn't consider it a bug personally, imagine all the problems you'd have to parse user input if it came in your parser already HTML-encoded
@Simon well he doesn't like space, so let's take that as an example - "Welcome Simon The Road Runner!"
or URL-encoded: "Simon+The+Road+Runner"
chances are, you don't really wanna deal with HTML/URL-encoded strings in your code... but they do solve the problem that was described in that link... but on output.
@Simon Have you found any problems with the request validation for that? I honestly don't wanna go dig into its documentation what all it's supposed to prevent, I have limited interests in .net and it's also rather late here :P
@Simon oh so you're wearing black hat not white hat, sorry I thought you wanna protect something not the other way around LOL ... dunno, run some vulnerability scanner on it
@Simon meh that's why they're called hats, easy to change... a practice that's been in some folklores for centuries (including ours, we have some hat changing dance / drinking activity) and even Beckett's play doesn't make it any less absurd LOL
ASP.NET offers an extra layer to protect your application from XSS attacks and injection in general which is called Request validation.
On their official topic, they mention that:
Even if you're using request validation, you should HTML-encode text that you get from users before you display ...
