Hacker News Reader

Comment by homakov | Hacker News Reader

1. Will try. it would take 2x much text.

2. I'm not sure if that's what you meant but I just realized pretty bad bug in current callback=ping flow. When malicions page opens my.app for me and second later opens securelogin://#state=THEIRSTATE... so my sltoken will be matched with their state and they will log into my account. That requires good timing so not super severe but definitely will be fixed: if someone opens the app twice in a raw it will notify the user. Thanks

3. There's pretty much no alternatives working cross platform.

4. Which paragraph are you refering too? When I try to reset my Gmail password it boils down to: "dude you forgot your password, no backup email... we cant help here".

View on HN

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:// scheme--you could avoid that, no?

2. Not XSRF but phishing? Yes, 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.

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. ;)

>When I try to reset my Gmail password it boils down to: "dude you forgot your password, no backup email... we cant help here".

Have Google changed something? I had to go through account recovery a while back on a gmail account (with no backup email/number set).

They asked a bunch of questions to try and prove whether I was actually familiar with the account (when did you create the account, provide an address you've emailed more than once in the last month etc). It was a PITA, but I eventually regained access

I did my best and answered these questions honestly. We could make some kind of poll and see how many people can gain access back?

> 4. Which paragraph are you refering too? When I try to reset my Gmail password it boils down to: "dude you forgot your password, no backup email... we cant help here".

Checking now, I cannot setup a gmail account without a phone number or backup email. I can also reset my password as long as I have access to my phone which is currently logged in.

> In the end of any authentication scheme there will be a password that you just cannot forget. In SecureLogin we removed unnecessary levels of "backups" and "recovery codes", our scheme boils down to one master password, not to master password and backup file/paper/SIM card/email account etc.

I don't think a backup is "unnecessary". It lowers the chance of being completely locked out.

What happens if I forget my master password? Does it mean I can never log into the sights using the same account ever again?

Backup with 3rd party == giving up access to 3rd party. #1 principle of this protocol is not giving up access, at least by default. You are free to email your password to yourself, write it on a note, but it will never offer to send your password on your phone number. We live in a hostile world.

> Does it mean I can never log into the sights using the same account ever again?

It's up to the websites, they could use your email for reset + lots of personal info you have about account activity.

Right. My point was only that most people may want a lost-password fallback; this scheme doesn't prevent implementers from providing that, so it's not really a big deal.

I think a good model for crypto code documentation is https://github.com/defuse/php-encryption#getting-started

Reply on news.ycombinator.com