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.

Post History

85%

+10 −0

Q&A Separation of password cookies from all other types of cookies

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 co...

posted 3y ago by JDB‭ · edited 3y ago by JDB‭

Answer

#6: Post edited by

JDB‭ · 2021-04-26T20:45:13Z (over 3 years ago)

Copy Link

Raw

Markdown

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](https://jwt.io/)". 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.

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](https://jwt.io/)". 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.

#5: Post edited by

JDB‭ · 2021-04-26T20:31:30Z (over 3 years ago)

Copy Link

Raw

Markdown

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.
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.
~~**JWT is a common token format**~~
One common format for these tokens is known as "JWT", short for "[JSON Web Tokens](https://jwt.io/)". 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.

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](https://jwt.io/)". 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.

#4: Post edited by

JDB‭ · 2021-04-26T20:20:20Z (over 3 years ago)

Copy Link

Raw

Markdown

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.
~~There is no difference 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.~~
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.
**JWT is a common token format**
One common format for these tokens is known as "JWT", short for "[JSON Web Tokens](https://jwt.io/)". 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_.~~

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.
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.
**JWT is a common token format**
One common format for these tokens is known as "JWT", short for "[JSON Web Tokens](https://jwt.io/)". 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.

#3: Post edited by

JDB‭ · 2021-04-26T20:14:06Z (over 3 years ago)

Copy Link

Raw

Markdown

There is a fundamental misunderstanding at the root of this question.
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).
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.
There is no difference 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.
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.
One common format for these tokens is known as "JWT", short for "[JSON Web Tokens](https://jwt.io/)". 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.
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_.

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.
There is no difference 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.
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.
**JWT is a common token format**
One common format for these tokens is known as "JWT", short for "[JSON Web Tokens](https://jwt.io/)". 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_.

#2: Post edited by

JDB‭ · 2021-04-26T20:10:27Z (over 3 years ago)

Copy Link

Raw

Markdown

There is a fundamental misunderstanding at the root of this question.
~~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).~~
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.
There is no difference 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.
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.
One common format for these tokens is known as "JWT", short for "[JSON Web Tokens](https://jwt.io/)". 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.

There is a fundamental misunderstanding at the root of this question.
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).
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.
There is no difference 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.
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.
One common format for these tokens is known as "JWT", short for "[JSON Web Tokens](https://jwt.io/)". 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.
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_.

#1: Initial revision by

JDB‭ · 2021-04-26T20:08:29Z (over 3 years ago)

Copy Link

Raw

Markdown

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

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).

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.

There is no difference 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.

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.

One common format for these tokens is known as "JWT", short for "[JSON Web Tokens](https://jwt.io/)". 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.

Communities

Post History