4 ms·
The mechanism would need to somehow accommodate a login cross site request forgery protection. Maybe following headers: Auth-Spec: type=plain; csrf_token
by mixedbit 13y ago
The mechanism would need to somehow accommodate a login cross site request forgery protection.
Maybe following headers:
Auth-Spec: type=plain; csrf_token='xyz'; action=https://www.example.com/login; method=POST fields=email,password,csrf_token
Set-Cookie: csrf_token='xyz'; HttpOnly
Could do the job? The submit button would need to copy csrf_token value from the Auth-Spec to the login request.
- kijin 13y agoCSRF attacks should be relatively harmless if directed at the login page. They would have zero effect unless they got the credentials right, and an attacker who has access to your login credentials has no need for CSRF attacks, they can just log right in. Edit: I'm wrong. See below.
- mixedbit 13y agoLogin CSRF attacks are known to be harmful: https://en.wikipedia.org/wiki/Cross-site_request_forgery#Forging_login_requests https://en.wikipedia.org/wiki/Cross-site_request_forgery#For... The attacker doesn't brute force someone's credentials, but uses own credentials to log the victim as the attacker.
- kijin 13y agoAh, didn't realize that. Thanks for pointing it out. I suppose the header should contain some sort of nonce, then. To keep things as simple as possible, I propose: Auth-Spec: type=plain; action=/login; method=POST; fields=email,password,nonce:8977340152 The "colon syntax" could also be used where the name of a required field is different from the defaults (another problem that I overlooked). For example, WordPress uses "log" for the username and "pwd" for the password, so it would be "fields=log:username,pwd:password". It wouldn't be possible to require a nonce, though, because it would break backward compatibility with sites that are already vulnerable anyway. As an option for new or updated websites, though, it would be a good idea to add a nonce field.