5 ms·

2: What I was trying to understand was whether a malicious site can relay the "securelogin://" challenge generated by a good site to the victim. Basically, an X

by md_ 9y ago

2: What I was trying to understand was whether a malicious site can relay the "securelogin://" challenge generated by a good site to the victim. Basically, an XSRF attack. Does the client validate the context of the challenge? 4: I don't think that's true. Gmail has a heuristic recovery based on knowledge tests. It's _easier_ if you have a backup email or SMS, but not required in all cases. As an aside, another downside of this approach is that it requires server-side state. Not a huge deal in most cases, but it can present a scalability limit versus cookie-only (signature-based) auth schemes. If the client were able to relay cookies or redirects back to the browser--which seems like it should be possible by simply opening a redirect in the https:// https:// scheme--you could avoid that, no?

homakov 9y ago
2. Not XSRF but phishing? Yes, https://github.com/sakurity/securelogin#anti-phishing-concerns https://github.com/sakurity/securelogin#anti-phishing-concer... - it only works for callback=ping and native apps 4. Have you tried? Because they seem to ask too hard questions like exact date your account was created. > downside of this approach is that it requires server-side state Using key-value for delivering signed token to first request? there's callback=direct that opens the link instead of pinging it, but it's a huge pain to figure out which browser you used if not the default one.
- md_ 9y ago
  2. Phishing and XSRF are effectively the same in this case, no? We're talking about the phisher relaying the challenge to the victim and tricking them into posting the response--which doesn't really require phishing per se, hence the XSRF. Again, I may be misunderstanding the protocol here. :) 4. Yeah. It's a pain in the ass, but they do offer lost-password fallback. Anyway, I wasn't trying to belabor the point; just noting that big sites will probably always offer some lost-password recovery. > there's callback=direct that opens the link instead of pinging it, but it's a huge pain to figure out which browser you used if not the default one. Where can I read docs on the different behavior between callback=ping and callback=direct? I know I could read the source code, but I do enough of that in the office. ;)

by md_ 9y ago

homakov 9y ago

2. Not XSRF but phishing? Yes, https://github.com/sakurity/securelogin#anti-phishing-concerns https://github.com/sakurity/securelogin#anti-phishing-concer... - it only works for callback=ping and native apps 4. Have you tried? Because they seem to ask too hard questions like exact date your account was created. > downside of this approach is that it requires server-side state Using key-value for delivering signed token to first request? there's callback=direct that opens the link instead of pinging it, but it's a huge pain to figure out which browser you used if not the default one.

md_ 9y ago
2. Phishing and XSRF are effectively the same in this case, no? We're talking about the phisher relaying the challenge to the victim and tricking them into posting the response--which doesn't really require phishing per se, hence the XSRF. Again, I may be misunderstanding the protocol here. :) 4. Yeah. It's a pain in the ass, but they do offer lost-password fallback. Anyway, I wasn't trying to belabor the point; just noting that big sites will probably always offer some lost-password recovery. > there's callback=direct that opens the link instead of pinging it, but it's a huge pain to figure out which browser you used if not the default one. Where can I read docs on the different behavior between callback=ping and callback=direct? I know I could read the source code, but I do enough of that in the office. ;)