Use session-based approach for viewing recovery codes?

[jeremyevans]

Rodauth's current implementation for viewing recovery codes works as follows:

1. User enters password on view recovery codes form
2. Assuming password is valid, Rodauth displaying the recovery codes, without redirecting

This approach was reported to me as a security issue a while back. However, I'm not sure whether this is an actual security issue worth fixing, and would like input from the community. I probably should have asked for input back when I received the disclosure, but better late than never.

Here's an edited version of the disclosure I received:

We use Rodauth as the authentication framework for our app, it's great.
We're having a security assessment done by a third party and they
identified an (admittedly minor) issue and we are hoping for a change to
Rodauth to help fix it.

To summarize the vulnerability, if a user left their computer unattended, the
password could be retrieved from browser state. We actually had this security
finding in the past and we have a proposed patch to Rodauth.

Here was the proposed patch:

diff --git a/lib/rodauth/features/recovery_codes.rb b/lib/rodauth/features/recovery_codes.rb
--- a/lib/rodauth/features/recovery_codes.rb
+++ b/lib/rodauth/features/recovery_codes.rb
@@ -39,6 +39,7 @@ module Rodauth
     auth_value_method :recovery_codes_label, 'Recovery Code'
     auth_value_method :recovery_codes_param, 'recovery-code'
     auth_value_method :recovery_codes_table, :account_recovery_codes
+    auth_value_method :recovery_codes_session_key, 'recovery-codes-authenticated'
 
     auth_cached_method :recovery_codes
 
@@ -87,7 +88,11 @@ module Rodauth
       before_recovery_codes_route
 
       r.get do
-        recovery_codes_view
+        if recovery_codes_authenticated_session?
+          render_recovery_codes
+        else
+          recovery_codes_view
+        end
       end
 
       r.post do
@@ -99,14 +104,17 @@ module Rodauth
                 add_recovery_codes(recovery_codes_limit - recovery_codes.length)
                 after_add_recovery_codes
               end
-              set_notice_now_flash recovery_codes_added_notice_flash
+              set_notice_flash recovery_codes_added_notice_flash
             end
 
             self.recovery_codes_button = add_recovery_codes_button
           end
 
-          before_view_recovery_codes
-          add_recovery_codes_view
+          if defined?(json_request?) && json_request?
+            render_recovery_codes
+          else
+            set_recovery_codes_session_key_and_redirect
+          end
         else
           if param_or_nil(add_recovery_codes_param)
             set_error_flash add_recovery_codes_error_flash
@@ -123,6 +131,29 @@ module Rodauth
 
     attr_accessor :recovery_codes_button
 
+    def render_recovery_codes
+      if can_add_recovery_codes?
+        self.recovery_codes_button = add_recovery_codes_button
+      end
+
+      clear_recovery_codes_session_key
+      before_view_recovery_codes
+      add_recovery_codes_view
+    end
+
+    def recovery_codes_authenticated_session?
+      param_or_nil(password_param) || session[recovery_codes_session_key] == true
+    end
+
+    def set_recovery_codes_session_key_and_redirect
+      session[recovery_codes_session_key] = true
+      redirect add_recovery_codes_redirect
+    end
+
+    def clear_recovery_codes_session_key
+      session[recovery_codes_session_key] = nil
+    end
+
     def two_factor_need_setup_redirect
       super || (add_recovery_codes_redirect if recovery_codes_primary?)
     end

I had forgotten about this, until I was going through old email looking for something else. However, I think it's worth discussing whether this is a security issue at all, and if so, whether it is worth fixing. The attack vector seems to be that:

1. User fills out password and submits form, leaving it on page to view recovery codes
2. User leaves computer unmonitored
3. Attacker gets access to computer
4. Attacker introspects browser state to recover password user used.

I'm not sure how step 4 is accomplished, and why switching to a session-based approach would prevent it. Does anyone have more information in this area? I'm open to switching to a session-based approach if that's what users would prefer, but don't want to make changes if this is really a false alarm.