hi, but this is not solving the issue, we are adressing in the 1st place (get access to the system with a stolen session token)
I’ve tested the way diabling users, yes works fine as expected.
2things to mention if you run it
- you’ll disable ALL users and ALL their connected devices
- the stolen session token is still active and valid
ad 2) you have to shut all your users down / out of NC (disable them) until your
login_cookie ( Defaults to
60*60*24*15 seconds (15 days) )
session_lifetime ( Defaults to
60*60*24 seconds (24 hours) )
runs out … means you have to wait at least 24 hours or in some cases longer but lets play with the defaults.
Where I come from 24 hours BUSINESS STANDS STILL is kind of mission critical and will get your ass pretty fast escorted out of the building.
yes we have kicked them (the bad ones) out (with all the others)
next step we have to compare and check log-files and get a list,which user is connected with what kind of device (webIf / windows client / mobile device / and on and on) then you have to run these IPs grouped by user through some GEO-IP filter/information to check if eg your German users are conneced from German IPs (yes i know there are VPNs and no one would be stupid to attack without hiding at least the origion of his public IP) and not via IPs from another part of the world (cross check against your firewall / vpn gateway to rule out your legit users, who are gonna call you right away when you kicked em out of service while on a meeting in Los Angeles)
what you got so far is a rough validated list of
user IDs | IP Adress | Geo Info
next step sort all the inactive people out of the list, (you have to do some calculation if their session is expired or not but get it simple this time)
then you get a list
user IDs | IP Adress | Geo Info | active within $session_lifetime - now |
active now will not do the trick cuz this session token could be stolen / compromised too !
with this information you can now start to disbale the user and keep them out until the $session_lifetime is expired.
BECAUSE there is at the moment as far as i see
NO WAY to revoke the session token and forece the user (that means you know exact which user) to reauth with their credentials.
I hope you now got a better understandig @Kerasit why this is not solved.
Kill / revoke all session tokens at once would be an interesting thing to test.
but again kill all session tokens or only the active ones …
so there is more into that because this is a pretty awesome product and all over the world more and more people store personal and protectabel information with this product, so we the community have to help em out when shit hits the fan, in a way thats also doable for the non IT professional.