On Sun, 20 Sep 2020 18:49:12 +0000 coderman <coderman@protonmail.com> wrote:
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Sunday, September 20, 2020 6:41 PM, Punk-BatSoup-Stasi 2.0 <punks@tfwno.gf> wrote:
... But even if you hijack a session, wouldn't the system still re-check that you have access to your phone before allowing you to change all your passwords? It seems to me that it should? (but prolly doesn't because it's too 'inconvenient' for the user?)
note that you don't need to change passwords to accounts to be able to use them. in fact, changing passwords usually requires re-authentication, but extending a session indefinitely is free! :)
well passwords were changed in this case, so that would point to the phone being compromised I guess? Sorry about my ignorance of the working details of 2fa. I never bothered with it. Let me check. Ah yes, I don't even own a cellphone =)
this is the dirty little secret in infosec: authorized session life cycle is almost always too lenient and too long. for example, many services don't even bind a session to an IP,
haha that's just...pathetic. I don't think google-nsa are that incompetent? though the bug can certainly be seen as a 'feature'...
so session jacking you across the globe throws up no issues.
you can have sessions that don't expire upon password change - you must instead go through a separate step to kill existing sessions!
you can have hijacked sessions that simply renew, indefinitely, keep an active connection to your accounts for days, months, years (!!) without ever having to enter credentials.
most of the time this is laziness on behalf of service provider. even the big ones. sometimes usability is given priority over security - can't cause an inconvenience for users! they won't get hacked...
well in this case sessions were regularly closed and if changing passwords still requires access to the phone, the phone must have been compromised, it seems to me.
end result: most services handle sessions sloppily; caveat emptor.
best regards,