4 ms·
So I could take the cookies from my browser, send them to a friend, and my friend could then save the files and use the cookies? There’s no process to verify it
by elliekelly 5y ago
So I could take the cookies from my browser, send them to a friend, and my friend could then save the files and use the cookies? There’s no process to verify it’s being used in the same browser or computer?
- shadowgovt 5y agoThere should be. You can't guarantee it will always work, but it's certainly possible to encode some fingerprinting into the cookie so that if the fingerprinting no longer matches what the client requesting data from the server looks like, the server throws up a red flag and asks for the authentication challenge response to be repeated. But no, it sounds like Slack doesn't do that, which is a problem.
- excitom 5y agoSecurity I implemented in the 90's: Encode the client IP address into the cookie. Also include a timestamp to force re-authentication at some point. This isn't rocket science.
- jshmrsn 5y agoWouldn't the cookie then be invalidated if you e.g. switched between WiFi and cellular on mobile?
- __turbobrew__ 5y agoYes, it would be invalidated. This would not work well on roaming devices.
- josho 5y agoAnd now as I connect between ipv4 to v6, connect to my VPN, switch from wifi to mobile data each change requires a login and I very quickly abandon your app for one that doesn’t force multiple authentications throughout the day.
- tgv 5y agoNot only that. I tried the same approach, but one of our clients has some kind of VPN and the user’s IP address would change regularly.
- VectorLock 5y agoGood luck with that on mobile.
- ohyeshedid 5y agoUntil CGNAT cripples your concept.
- j4yav 5y agoDevices are much more portable since the 90s and are likely to change networks frequently.
- teawrecks 5y agoThis is non-trivial to do without gathering more info about someone's browser than users would be comfortable with (aka fingerprinting). Ideally, a website/app knows nothing about the machine it's running on and is perfectly sandboxed away from everything else. A private key shouldn't be device dependent. 2FA was the solution here, but was not enforced properly. They were able to social engineer IT into resetting their 2FA token without any proof they were who they said.
- dwild 5y agoThe IP is something someone isn't comfortable with? It seems to be quite trivial to include the IP in the cookie/session and verify it's the right one. Sure it's not perfect in a world where IP are not necessarily static (and a VPN may change it), but having to login again is not that bad, even more so if you are using SSO.
- Jenk 5y ago> The IP is something someone isn't comfortable with? No good. Slack's biggest userbase is corporate, behind corporate VPNs. Many users have the same IP.
- coopsmoss 5y agoStill seems reasonable for preventing an outside attack though.
- meowface 5y agoIt can help, for sure. I think the main reason it typically isn't enabled in general is that it's pretty common nowadays for people to switch IPs regularly. It'd be annoying to have to re-login to Slack multiple times per day as you move around with your phone or take your laptop to different places. (Especially if it's a user who isn't in a corporate environment, where your public IP will probably differ when you connect to different wireless networks. On a corporate network you're more likely to retain the same public IP no matter which room or building you're in.) If they don't, they should provide an option for corporate administrators to enable IP locking for session cookies.