Jeroen

I was actually referring to the first answer where it states: "If you want to defend against rainbow tables, salts are inevitable, because you need a full rainbow table per unique salt, which is computationally and storage-wise intense."

I'd still recommend using random salts for each hash. Please read crypto.stackexchange.com/questions/34158/…

The stronger computers and their video cards (CUDA like systems) the more likely an algorithm is prone to collision attacks. However, the likelihood of this happening to SHA2 currently is negligible. Please see crypto.stackexchange.com/questions/24732/…

SHA1 is already considered weak due to collision attacks. Please read arstechnica.com/information-technology/2017/02/…

Which is a header

Hmm, that's a company policy? I'd recommend reconsidering that because of new security standards etc. Not to mention the vulnerabilities in older browsers....

handling / support

Oh you're handling older web clients as well? < IE 7?

Indeed

Yeah, sent an OPTIONS request...

Doesn't that prevent a malicious website from sending a POST request to your authentication mechanism?

You also mentioned that CORS is implemented

double submit would do the trick for you but that requires you to also have an anti CSRF cookie - and you can't handle cookies right?

When the user visits the malicious site, it is automatically executed

Oke so from the malicious site you send a request to your application

Through a malicious website.... you mean click jacking?

Let me have a look at your diagram

Please realize that the problem you're describing has a very low likelihood. Most likely the token will expire after X amount of time. So me as an attacker could grab a valid token from the login page and use it in an XSS attack

Another idea that just popped up in my mind is MFA

e.g. checking username and password

if that matches the authentication process can be initiated

If that's valid, check the server side if the token matches

first does the token in the hidden input field matches against the token in the response header

you do two checks

with the token value

So let's say you sent an extra header called X-Anti-CSRF

The response header can not be controlled by an attacker

and response header* (typo)

How would an attacker generate the token? You generate the token server side and validate if the token matches or not, also on the server side. Or do you mean if an attacker grabs a valid token from the login page? In that case you could use both the hidden input field a response header, both need to match and be verified server side.

In your "Sort-of-Solution" you state: "The login attempt is made only if the token is valid......" So at the login page, a token (anti CSRF) is generated and sent in the response of the login page. The token can be placed in a hidden input field. The user enters credentials and sends the POST request, containing the token, username and password. Server side the token is checked, if the token is valid, verify the username and password. If the token is incorrect stop the authentication process.

Many security consultants, including myself, believed that anti CSRF tokens were meant for state changing requests only (authenticated). However, I have changed my opinion on that. Generating an anti CSRF token on a login page will prevent the issues you describe. Using such tokens is only to determine the origin of the request. Anti CSRF tokens can be implemented in two ways, session based (as you described) and also request based. I think implementing this would solve your issue.

Apparently I misunderstood, I thought it was an issue after authentication. After re-reading your message it's a token that you want a user to retrieve and submit during the authentication process. Isn't this what an anti CSRF token is for? That way the system can determine the origin of the request.

Well, that's assuming the attacker knows the username. How about this. Generate a secret token upon registration which is stored in your back-end system(s) and never displayed to your users and use that as one of your secrets during the encryption process.

Instead of using the IP - what about encrypting the username instead?

I'm not an Onavo user so I can't say anything about that. I do use Tor and although it is possible to do this, it is not default behavior. I think you should ask yourself if you want your users to be able to work with your system if their IP addresses change every request.

Ok, can you please elaborate a little bit more on what you mean by an XSS token? Session token?

XSS tokens? You mean XSRF (CSRF) tokens? Even if your users use Tor, the IP is not changed in every request because it will use one exit node until the Tor user decides to change this.

G'd morning (or what ever, depending on your timezone)

Hey all...

Well, it's not here, but.... good afternoon to you

erm evening

Good morning

morning

Good morning everyone

erm *stuff

I also voted for the guy who said why not to vote for him, that was some funny shit

:) Alright....

Guess it did not make a difference

I voted for you :P

@Schroeder Hi!