https://www.ory.sh/ logo
Join Slack
Powered by
Hi! I am working on the password recovery flow for...
# ory-selfhosting
a
Hi! I am working on the password recovery flow for my app, and have found that kratos automatically sets the session cookie during the recovery process, even before the user has successfully set a new password. This seems like a security risk because the user is now authenticated into other parts of our site without having a password. Is there a way to distinguish a session that is part of an incomplete recovery flow with a regular (logged-in) session?
m
Is there a way to distinguish a session that is part of an incomplete recovery flow with a regular (logged-in) session?
I dont think so. But what is the behaviour you are looking for? To access the settings page / change the password the user needs a valid session which they get during recovery. You can invalidate existing sessions after the user sets a new password but that is IMO seperate from a recovery flow?
a
Yeah, it's exactly the problem that the user needs a valid session to change their password, but before changing their password they can use this session to access other parts of our site (e.g. by changing the url). We want to ensure that, after a user has clicked on a recovery link, they cannot perform any other actions other than changing their password. My solution is to obscure both the recovery flows and settings flows into one backend call, so that the cookie and redirects are hidden from the client and they only see success or fail. This seems like something other developers would run into though?
r
What attack does the current behavior enable?
a
the concern is that someone could have access to your email, request to reset your password, use the link, be authenticated, delete the email and then observe what you’re doing in Crusoe Cloud without you knowing. The issue is not that they have access to your email (we can't control that), but that this attack is silent, i.e. the user would never realize they've been hacked
r
You could inspect the response from the whoami call in your backend to check if it’s from a recovery flow and disallow all actions.
After re-reading, I realize that was your original question 😅
Let me check what’s inside the session.
The session indeed contains this info:
Copy code
{
  "id": "67ea898f-d7d6-4a35-a391-8dcca631d613",
  "active": true,
  "expires_at": "2024-09-22T20:29:23.583417Z",
  "authenticated_at": "2024-09-19T20:29:23.583417Z",
  "authenticator_assurance_level": "aal1",
  "authentication_methods": [
    {
      "method": "code_recovery",
      "aal": "aal1",
      "completed_at": "2024-09-19T20:29:23.583415008Z"
    }
  ],
  "issued_at": "2024-09-19T20:29:23.583417Z",
a
Thanks for this! Can you point me to any docs that explain this 
authentication_methods
field in more detail? I assume that I can look at this list, find the most recent method, and take some action depending on whether it's 
link_recovery
or 
password
And can I assume that this 
authentication_methods
list will always be in chronological order, i.e. the only operations on this list will be appends?
4 Views
Open in Slack
PreviousNext
Powered by