4 ms·

As another commenter said, that solution leaks security information - it says "this domain is a customer of ours and is configured to use a special authenticati

As another commenter said, that solution leaks security information - it says "this domain is a customer of ours and is configured to use a special authentication setup." Some big and lucrative customers will object to this leakage. Requiring an attacker to wait for a full page load to test an email address has a rate-limiting effect. An AJAX solution can still be the right tradeoff of user experience vs security for some sites, and the article gave a couple of examples of major sites that have followed your suggestion. But the security downsides mean it's not right for every case.

kijin 7y ago
That information is leaking anyway. Besides, a smart attacker ain't waiting for page loads, he's got scripts. It's all security theater. If a corporate customer insists on objecting, maybe you could charge them $$$ to add a special case for their domain.
isostatic 7y ago
> Requiring an attacker to wait for a full page load to test an email address has a rate-limiting effect. You could rate limit based on IP, or even in the javascript, if you're that concerned -- .onblur sends the request, which typically responds quickly with a "password not needed" flag. You're just trying to stop casual snoopers, as for scripts it's not much different to sending the request as part of the entire form (and seeing if the response is a page or a redirect)
tracker1 7y ago
Agreed... My plan is to wait 1/2 second before processing any login, and add a bit more for failed attempts before lockout. Random amount of time between windows. I've thought about doing a client-side challenge token and subtlecrypto to pbkdf2 that to generate a key, then sign the login request with the generated key. I could use a pool of precomputed keys on the server and associate the key source sent via http-only cookie for the key's id in the DB. Unfortunately still have to support the non-chrome edge browser which seems to have some gaps in browser crypto support.

kijin 7y ago

That information is leaking anyway. Besides, a smart attacker ain't waiting for page loads, he's got scripts. It's all security theater. If a corporate customer insists on objecting, maybe you could charge them $$$ to add a special case for their domain.

isostatic 7y ago

> Requiring an attacker to wait for a full page load to test an email address has a rate-limiting effect. You could rate limit based on IP, or even in the javascript, if you're that concerned -- .onblur sends the request, which typically responds quickly with a "password not needed" flag. You're just trying to stop casual snoopers, as for scripts it's not much different to sending the request as part of the entire form (and seeing if the response is a page or a redirect)

tracker1 7y ago

Agreed... My plan is to wait 1/2 second before processing any login, and add a bit more for failed attempts before lockout. Random amount of time between windows. I've thought about doing a client-side challenge token and subtlecrypto to pbkdf2 that to generate a key, then sign the login request with the generated key. I could use a pool of precomputed keys on the server and associate the key source sent via http-only cookie for the key's id in the DB. Unfortunately still have to support the non-chrome edge browser which seems to have some gaps in browser crypto support.