Enancement: Saved tab state should include HTTP auth

Talk about code development, features, specific bugs, enhancements, patches, and similar things.
Forum rules
Please keep everything here strictly on-topic.
This board is meant for Pale Moon source code development related subjects only like code snippets, patches, specific bugs, git, the repositories, etc.

This is not for tech support! Please do not post tech support questions in the "Development" board!
Please make sure not to use this board for support questions. Please post issues with specific websites, extensions, etc. in the relevant boards for those topics.

Please keep things on-topic as this forum will be used for reference for Pale Moon development. Expect topics that aren't relevant as such to be moved or deleted.
jb_wisemo
Moonbather
Moonbather
Posts: 56
Joined: 2016-01-27, 02:09

Enancement: Saved tab state should include HTTP auth

Unread post by jb_wisemo » 2021-12-03, 11:57

When something crashes Pale Moon, the next run offers to reload the state of all tabs. This is a nice feature, but has a limitation which I suggest to improve:

If any of those tabs accessed the page with HTTP(S) auth rather than cookie-based auth, the restored session does not include the auth data, and thus the user is prompted for entering credentials again.

The suggested enhancement is to include the HTTP auth data (appropriately encrypted) in the crash restore state, just like it may contain appropriately encrypted cookies, POST parameters etc.

This may be vaguely related to Bugzilla bug #789062, which is about that restore being done incorrectly in Fx 13.x

Analysis of the 7 thinks to think about (viewtopic.php?f=5&t=5647):

1. No this is not specific to a workflow, other than the general case of a browser crash when using the fundamental HTTP Auth browser feature.
2. This does not add any gadget or toy, it is merely to have an existing core feature work with another existing core feature.
3. This feature is culturally neutral as far as the two involved core feature are culturally neutral.
4. Websites using HTTP Auth may be rare these days, but do exist. That is the only aspect that might be considered "advanced usage"
5. I know of no extension or extension mechanism to add more state (especially state for core components such as HTTP) to the session restore file.
6. Yes, this improves overall quality as it removes a situation where users have to reenter their login after a browser crash.
7. This suggestion does not hinder access to any resource.

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 35402
Joined: 2011-08-28, 17:27
Location: Motala, SE
Contact:

Re: Enancement: Saved tab state should include HTTP auth

Unread post by Moonchild » 2021-12-03, 13:18

Sorry, but no.
Saved tab state should not include http auth credentials because there is no way to either (1) safely store this data and (2) by design this kind of authentication is scoped within a single session.

Compromising security for the convenience of recovery from a shutdown or crash is unacceptable. You can store credentials in the password manager for automatic logging in if you need to use auth for a certain site regularly -- this will have all the proper security measures to prevent credential theft and will allow swift authentication to http auth protected resources.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

jb_wisemo
Moonbather
Moonbather
Posts: 56
Joined: 2016-01-27, 02:09

Re: Enancement: Saved tab state should include HTTP auth

Unread post by jb_wisemo » 2022-05-18, 04:37

The security compromise is already present for sites that use cookie-based authentication, as authentication cookies survive the crash-restore cycle, and general history/restore concepts suggest that a "session restore" would, by definition, be the same logical session, thus already including session cookies from before the crash.

Protecting the crash-recovery saved session data from theft is an entirely separate issue, also affecting any other potentially private information (such as confidential or embarrassing URLs, like nextcloud sharing URLs for private files). If this used the master password, separate from saved password storage, that would be one of multiple potential implementations.

User avatar
moonbat
Knows the dark side
Knows the dark side
Posts: 4942
Joined: 2015-12-09, 15:45
Contact:

Re: Enancement: Saved tab state should include HTTP auth

Unread post by moonbat » 2022-05-18, 06:07

Cookies can have an expiry set to several days or months later, as compared to an HTTP session which is meant to be short lived.
"One hosts to look them up, one DNS to find them and in the darkness BIND them."

Image
Linux Mint 21 Xfce x64 on HP i5-5200 laptop, 12 GB RAM.
AutoPageColor|PermissionsPlus|PMPlayer|Pure URL|RecordRewind|TextFX

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 35402
Joined: 2011-08-28, 17:27
Location: Motala, SE
Contact:

Re: Enancement: Saved tab state should include HTTP auth

Unread post by Moonchild » 2022-05-18, 13:38

jb_wisemo wrote:
2022-05-18, 04:37
The security compromise is already present for sites that use cookie-based authentication
I'm sorry but that is a completely different kind of compromise that is also very heavily dependent on the server-side implementation. Sites implementing cookie-authentication should also combine it with other parameters (IP, expiration/rotation, hashing, browser checks, etc.) to validate the session cookie login to prevent e.g. replay attacks. Still, that would be the responsibility of the website owner, and not a compromise in the browser. Cookie handling is well-established. Cookie authentication should also never store raw credentials if people use it in any decent way (if not, the web designer should be re-educated about basic site/account security). Storing basic auth credentials would.
jb_wisemo wrote:
2022-05-18, 04:37
If this used the master password, separate from saved password storage, that would be one of multiple potential implementations.
And how, pray tell, would you handle such protected storage of session data in a crash scenario?

No, I really don't see any argument whatsoever for this request to be honoured. if you use the password manager with a master password, simply providing the auth credentials from secure storage when recovering from crash (you'd have to enter that password anyway if session data would be stored protected...) is just as fast as any alternative that would store these credentials as session restore data.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

Locked