Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

Welcome to Software Development on Codidact!

Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.

Separation of password cookies from all other types of cookies

+1
−3

When I clear my Google Chrome browser history I can clear both "Cookies and other site data" AND "passwords and other sign-in data".

  • Clearing just one of the two would require me to re-login to any website I already had a logged in account on.

  • It is interesting to note that in Microsoft Edge browser a more modular approach was taken and there it's just "Passwords" (instead "Passwords and other sign-in data") AND "Cookies and other site data", though the behavior is pretty much the same

From both a modular software development standpoint and an information security standpoint, separating passwords and their cookies from all other cookies would make easier life for users who want to generally clear cookies frequently but still keeping their websites accounts logged in.

Why aren't web browser developers separate the two?
(perhaps a separation to "cakes" and "cookies" is a good one, were any "cake" is actually any "password cookie" and any "cookie" is "of all the rest").

History
Why does this post require attention from curators or moderators?
You might want to add some details to your flag.
Why should this post be closed?

1 comment thread

General comments (8 comments)

1 answer

+10
−0

There is a fundamental misunderstanding at the root of this question.

Websites do not store your password client-side

When you login to a website, the website does NOT store your password in a cookie or anywhere else (or, if it does, you should stop using that website).

Cookies store tokens

Instead, when you login to website, your encrypted username and password are sent to the server. The server verifies the credentials and sends back a unique token. This token is usually some sort of string of indecipherable numbers and letters. Next time you make a request to the server, you send along that token, which the server can then verify as the same token it sent you before, thus skipping the login process.

Often the server will have an expiration associated with the token, which is one way a website can automatically log you out after some period of time. Sometimes the token is only valid if use from the same IP address, which may cause your login to be invalidated if you suddenly switch your IP address (such as by turning on or adjusting a proxy or VPN).

However, there is no difference of type between a cookie that contains one of these tokens and a cookie that just contains some preferences, and no way for the browser to distinguish which is which. Only the website (e.g. server) knows which cookie is used for what purpose.

If it helps, you can think of a cookie as an airplane boarding pass. You have to prove who you are when you get to the airport and that you have a valid ticket. You are then issued a boarding pass which contains codes that mean nothing to you, but which can be quickly scanned by security guards and flight attendants to show that you have checked in and belong on a particular flight, as well as possibly additional information such as who you are travelling with and whether or not you have checked bags.

Tokens might not be stored in a cookie at all

There are, of course, other ways of sending along a token, such as in the body of a POST request or in the URL and sometimes websites use those alternatives instead of a cookie. This is especially common for REST services, where crafting a request with cookies might be needlessly complex for the developer. Many REST services accept the token either as a cookie or embedded as a URL argument.

For example, JWT is a common token format

One common format for these tokens is known as "JWT", short for "JSON Web Tokens". However, if done properly, that still won't be very meaningful to the browser as a JWT should be encrypted before sending it to the client, which indistinguishable (reliably, any way) from any other kind of token format.

Browser password managers

Your password might, however, be stored by your browser via a password manager. Some people use the password manager built directly into their browser, while others use password managers installed via plugins or as standalone applications.

When you see the option to clear passwords, it's offering to let you clear passwords stored by the browser, not the website. In this case, the password is stored in some encrypted database the belongs to the browser, not a cookie on the website.

History
Why does this post require attention from curators or moderators?
You might want to add some details to your flag.

0 comment threads

Sign up to answer this question »