What are Device Bound Session Credentials (DBSC)?

What are Device Bound Session Credentials (DBSC)?

Device Bound Session Credentials (DBSC) is a cutting-edge security feature developed by Google to counter cookie theft. Its unique approach stands apart from traditional security measures. Here’s a breakdown of its operation:

Goal: Disrupt cookie theft by linking authentication sessions to a specific device. This means stolen cookies become useless as they can only be used on the device from which they were obtained.
How it works: DBSC utilises a combination of factors:
- Public/Private Key Pairs: When a session starts, a unique ‘key pair’ is created on the device and stored securely using the Trusted Platform Module (TPM).
- API for Servers and Browsers: Websites can initiate DBSC sessions with browsers. The browser creates the key pair and uses it to prove possession during the session.
- Focus on Freshness: DBSC ensures short-lived cookies are refreshed through a dedicated DBSC endpoint.
Benefits:
- Reduced Account Hijacking: DBSC makes it significantly harder for attackers to hijack accounts by rendering stolen cookies useless.
- More Effective Malware Detection: Since attackers must be on the device, malware becomes more accessible to detect and remove.
- Privacy Focused: DBSC doesn’t disclose device information beyond what’s required for secure storage; users can delete keys anytime.

Overall, DBSC aims to improve web security by making cookie theft a less effective tactic for attackers. It’s currently under development to have a working trial by the end of 2024. The project is being developed openly on GitHub to become a standard other browsers and web services adopt.

Who is Device Bound Session Credentials (DBSC) for?

Device Bound Session Credentials (DBSC) is primarily for two groups:

For web users, DBSC is a game-changer. It offers significant security benefits, especially for those concerned about account hijacking. By making cookie theft a dead end for attackers, DBSC helps keep user accounts more secure. This is particularly valuable for users who access sensitive information or online accounts through their web browser, providing them with a sense of enhanced security.
Website Developers: DBSC provides website developers with a tool to strengthen user authentication. Since DBSC makes session hijacking through stolen cookies much harder, it reduces the risk of unauthorised access to user accounts and protected website resources. This is particularly important for websites handling sensitive information like financial information or healthcare records.

Web Users

Here’s a breakdown of how Device Bound Session Credentials (DBSC) benefits web users:

More robust Defense Against Account Takeovers: DBSC makes stealing cookies pointless. Even if malware or hackers manage to steal your cookies, they won’t be able to use them to hijack your accounts on other devices. This significantly reduces the risk of someone else taking control of your online accounts.
Improved Security for Sensitive Activities: If you frequently access online banking, investment accounts, healthcare portals, or other websites with sensitive information, DBSC provides an extra layer of security. Making cookie theft ineffective makes it much harder for adversaries to gain unauthorised access to your data.
Potential for Smoother Logins: While DBSC is still under development, it could lead to smoother login experiences in the future. Since stolen cookies become useless, the need for overly complex login procedures (like multiple layers of verification) might be reduced in some cases.

Here’s a tip: While DBSC is still under development and won’t be available immediately, it’s a technology worth looking forward to. In the meantime, you can still improve your web security by practising good password hygiene, using multi-factor authentication whenever possible, and keeping your web browser and software current. This reassurance about the ongoing development of DBSC can give you a sense of anticipation for its future implementation.

Website Developers

Here’s how Device Bound Session Credentials (DBSC) can benefit website developers:

Enhanced User Authentication: DBSC strengthens user authentication by rendering stolen cookies ineffective. This makes it significantly harder for attackers to hijack user accounts and gain unauthorised access to website resources. This is especially valuable for websites handling sensitive data like financial information, healthcare records, or private user content.
Reduced Risk of Security Breaches: By mitigating cookie theft, DBSC minimises your website’s vulnerability to account takeover attacks. This minimises the risk of a security breach and the potential damage it can cause, improving user trust and potentially reducing costs associated with managing breaches.
For website developers, DBSC is a powerful tool that can simplify security measures. With DBSC making session hijacking less of a threat, you might be able to streamline some security measures currently in place. This could involve reducing reliance on complex CAPTCHAs or overly stringent password requirements, potentially improving user experience and empowering you to manage website security.
Alignment with Privacy Focus: DBSC is designed with user privacy in mind. It doesn’t disclose unnecessary device information and allows users to delete keys anytime. This aligns with the growing focus on user privacy regulations and gives you a solution that adheres to these principles.

Things to Consider:

Browser Adoption: As DBSC is under development, it might take time for all browsers to adopt it. You’ll need to consider how DBSC will work alongside existing authentication methods for users on non-supporting browsers.
Integration with Existing Systems: Integrating DBSC with your existing authentication system might require some development effort. It’s essential to assess the complexity of implementation for your specific setup.

Overall, DBSC presents website developers with a promising new tool to bolster user authentication and enhance website security. While there are some implementation considerations, the potential benefits for user trust, reduced security risks, and a more privacy-focused approach make DBSC a technology worth considering. Take the first step by exploring how DBSC could fit into your security strategy.

How do we implement Device Bound Session Credentials (DBSC)?

Device Bound Session Credentials (DBSC) are currently under development, so there isn’t a finalised implementation process yet. However, we can discuss the general approach based on the information available:

Current Stage:

DBSC is still in the prototype phase, and Chrome-based browsers like Google Chrome offer experimental flags to enable testing: https://groups.google.com/a/chromium.org/g/blink-dev/c/xvZJPpXNS8Y.

Expected Implementation (when finalised):

Server-Side Integration:
- Websites must update their server-side code to interact with the DBSC API. This likely involves adding functionalities to:
  - Initiate DBSC sessions with browsers.
  - Negotiate registration parameters for the key pair.
  - Handle and verify session refreshes with cryptographic proofs.
  - Potentially manage session termination from the server side.
Client-Side Integration (Browser):
- Major browsers will need to integrate DBSC functionality. This might involve:
  - Responding to server requests to initiate DBSC sessions.
  - Securely generating and storing key pairs using the Trusted Platform Module (TPM).
  - Sending the public key to the server during registration.
  - Managing and using the private key to prove possession during requests while the session is active.
  - Potentially refreshing sessions with the server using the DBSC endpoint.

Resources for Developers (During Development):

While a finalised implementation guide isn’t available yet, you can follow the development process through resources like:
- The official DBSC explainer on GitHub https://github.com/sessions/trusted-device?return_to=%2Fsettings%2Fsecurity.
- Discussions on the WICG proposal repository https://github.com/sessions/trusted-device?return_to=%2Fsettings%2Fsecurity

Remember:

The implementation specifics will likely change as DBSC development progresses. Stay updated by following the resources mentioned above.
As of today (April 4, 2024), DBSC isn’t ready for production use.

I hope this clarifies the current status of DBSC implementation for website developers.

Is Device Bound Session Credentials (DBSC) like another security header?

No, Device Bound Session Credentials (DBSC) fundamentally differ from security headers’ approach to web security. Here’s a breakdown of the key differences:

Security Headers:

Function: Security headers are instructions a web server sends to a browser to improve security settings. They typically configure browser behaviour related to things like:
- Content Security Policy (CSP) restricts the resources (scripts, images, etc.) that a webpage can load.
- X-XSS-Protection: Mitigates Cross-Site Scripting (XSS) vulnerabilities.
- Strict-Transport-Security (HSTS): Enforces HTTPS connections.
Focus: Security headers protect web pages from malicious attacks like XSS or clickjacking. They don’t directly address user authentication or session management.

Device Bound Session Credentials (DBSC):

Function: DBSC is an API (application programming interface) that creates a secure session between a web server and a specific device. It utilises public/private key cryptography to:
- Link user sessions to a particular device.
- Render stolen cookies are ineffective for unauthorised access.
Focus: DBSC tackles session hijacking, a common tactic where attackers steal cookies to gain access to user accounts on other devices. It strengthens user authentication by making cookies irrelevant for attackers without the physical device.

Analogy:

Think of security headers as adding locks to your house windows and doors (the web page). DBSC is like implementing a two-factor authentication system for entering your house (the user session). They serve different purposes but can work together for a more comprehensive security strategy.

Here’s a table summarising the key differences:

Feature	Security Headers	Device Bound Session Credentials (DBSC)
Type	Server Instruction	API
Focus	Web Page Security	User Authentication & Session Management
Method	Configures Browser Behavior	Public Key Cryptography
Example	Content-Security-Policy (CSP)	Linking session to a specific device

drive_spreadsheetExport to Sheets

In conclusion, DBSC is a more sophisticated approach to security than traditional security headers. It offers a new layer of protection against unauthorised access by focusing on securing user sessions rather than just the web pages themselves.

Technical details of Device Bound Session Credentials (DBSC).

While DBSC is still under development, here’s a dive into some of the technical details available so far:

Cryptographic Core: DBSC leverages Public Key Infrastructure (PKI) using elliptic curve cryptography to establish trust between the browser and server.
- During session initiation, a key pair (public and private key) is generated on the device using the Trusted Platform Module (TPM) to store the private key securely.
- The public key is then shared with the server to associate the session with the device.
API Interaction: DBSC relies on an API for communication between servers and browsers.
- Websites can initiate DBSC sessions by calling the API to signal the browser to create a key pair.
- The browser responds with the public key, and the server stores it for verification during the session.
- The API also facilitates refreshing sessions with cryptographic proofs to confirm the private key is still on the device.
Session Management:
- DBSC sessions are designed to be short-lived, likely relying on short-lived cookies along with the DBSC verification for added security.
- Refreshing the session involves the browser proving possession of the private key through a cryptographic challenge-response mechanism.
Privacy Considerations:
- DBSC is designed to be privacy-preserving.
- It doesn’t reveal any information about the device beyond its ability to store keys securely.
- Users can delete keys anytime, revoking access for that specific device.
Development Resources:
- The ongoing development of DBSC can be followed through the WICG (Web Incubator Community Group) proposal on GitHub https://github.com/LHCGreg/dbsc. This repository includes technical discussions and design documents.
- The Chromium Blog also offers insights into the project’s goals and technical approach: https://blog.chromium.org/2022/.

Things to Remember:

These details are based on the current development stage and might change before final implementation.
DBSC is still in the testing phase, so specific details on implementation might not be publicly available.

Cryptographic Core

In the Device Bound Session Credentials (DBSC) context, the cryptographic core refers to the underlying cryptographic mechanisms that ensure secure communication and key management. Here’s a breakdown of its potential functionalities:

Public Key Infrastructure (PKI): DBSC likely utilises PKI to establish trust between web servers and user devices. PKI involves using digital certificates and cryptographic keys to verify the IDs of the communicating parties.
- Elliptic Curve Cryptography (ECC): ECC is a public-key cryptography believed to be more efficient and secure than traditional RSA for DBSC’s purposes. It uses elliptic curves for key generation and encryption/decryption.
Key Management: The cryptographic core plays a crucial role in managing the key pair (public and private key) used in DBSC:
- Trusted Platform Module (TPM): This secure chip on a device is likely used to generate and store the private key safely. The TPM offers hardware-based security mechanisms that make it difficult for attackers to extract the key.
- Public Key Exchange: The public key is securely exchanged with the server during session initiation. This key allows the web server to verify that subsequent requests during the session originate from the authorised device.
Session Refreshment: DBSC sessions are designed to be short-lived. To maintain an active session, the cryptographic core might be involved in:
- Challenge-Response Mechanism: The server might send a cryptographic challenge to the browser. The browser uses the private key stored in the TPM to generate a response that proves it possesses the key. This verifies the legitimacy of ongoing requests from the device.

Overall, the cryptographic core in DBSC serves as the foundation for secure communication and key management. Only the authorised device with the private key can participate in the DBSC session, strengthening user authentication and mitigating session hijacking risks.

Here are some additional points to consider:

The specific implementation details of the cryptographic core might vary depending on the final design of DBSC.
Security researchers actively develop and evaluate the cryptographic core to ensure its robustness against potential attacks.

API Interaction

Device Bound Session Credentials (DBSC) relies on an API for communication between websites (servers) and browsers. This API facilitates initiating DBSC sessions, managing key exchange, and refreshing sessions securely. Here’s a closer look at how this interaction might work:

Session Initiation:
- The website initiates a DBSC session by calling the DBSC API function on its server.
- This API call likely specifies parameters for the session, such as its intended duration.
Browser Interaction:
- Upon receiving the API call from the server, the browser activates the DBSC functionality.
- The browser utilises the Trusted Platform Module (TPM) to securely generate a public/private key pair on the user’s device.
- The public key is then returned to the server via the DBSC API.
Key Exchange and Verification:
- The server receives the public key from the browser through the DBSC API.
- The server stores the public key securely and associates it with the user’s session.
- From this point onwards, the server can use the public key to verify subsequent requests during the session.
Session Refreshment:
- DBSC sessions are designed to be short-lived, likely relying on cookies with short expiration times.
- The server might initiate a refresh process through the DBSC API to maintain an active session.
- This refresh might involve the server sending a cryptographic challenge to the browser.
- The browser uses the private key stored in the TPM to generate a response that proves it possesses the key.
- The server verifies the response using the stored public key, confirming the legitimacy of the ongoing session.

Benefits of API Interaction:

Standardised Communication: The DBSC API allows servers and browsers to interact and manage DBSC sessions. This ensures interoperability and simplifies developers’ implementation.
Secure Key Exchange: The API facilitates the secure public key exchange between the server and the browser. This public key verification helps prevent unauthorised access attempts.
Separation of Concerns: The API separates session management logic from the core website functionality, improving code maintainability and security.

Current Stage:

The specific details of the DBSC API might change as the technology progresses through development.
Public information on the exact API functions and parameters might be limited while DBSC is under testing.

Resources:

For potential insights into the API design, you can follow the development process and discussions on the WICG (Web Incubator Community Group) proposal on GitHub: https://github.com/LHCGreg/dbsc.

Session Management

In Device Bound Session Credentials (DBSC), session management revolves around creating secure and short-lived connections between users and websites using a combination of DBSC verification and cookies. Here’s a breakdown of how it might work:

Traditional Session Management vs DBSC:

Traditionally, web servers rely on cookies to track user sessions. These cookies contain session identifiers that link a user’s browser to their session data on the server. However, attackers can steal cookies, enabling session hijacking.
DBSC introduces an additional layer of security. It utilises public/private key cryptography to verify that ongoing requests originate from the authorised device that initiated the session. Even if an attacker steals cookies, they won’t be able to use them on another device because they lack the private key stored securely on the user’s device.

Critical Aspects of DBSC Session Management:

Session Initiation:
- A user logs in to a website that supports DBSC.
- The website initiates a DBSC session through the DBSC API, potentially specifying the duration.
- The user’s browser securely generates a public/private key pair on the device using the Trusted Platform Module (TPM).
- The public key is transmitted to the server via the DBSC API.
- The server stores the public key and associates it with the user’s session.
- A short-lived cookie (likely with additional security features) might also be created to manage the session state on the server side.
Session Maintenance:
- During the session, the user interacts with the website as usual.
- The server verifies the legitimacy of each request by checking if it originates from the device with a valid private key.
  - This verification might involve challenge-response mechanisms where the server sends a cryptographic challenge, and the browser utilises the ‘private key’ to generate a response that proves its possession.
Session Refreshment:
- DBSC sessions are designed to be short-lived to minimise the window of vulnerability if a cookie is compromised.
- The server might initiate a refresh process through the DBSC API before the cookie expires to maintain an active session.
- The refresh process involves verifying the private key possession, as mentioned earlier.
Session Termination:
- The end user logging out can terminate the session, or it might time out if the user is inactive for an extended period.
- The server likely invalidates the session cookie and removes the associated public key information.
- The user’s device might also have options to revoke access for the specific website, essentially deleting the private key for that session.

Benefits of DBSC Session Management:

Reduced Session Hijacking Risk: By requiring the private key stored on the device for session verification, DBSC makes stolen cookies ineffective for attackers.
Enhanced Security for Sensitive Actions: DBSC provides an extra layer of security for actions involving sensitive data, making it harder for unauthorised access.
Potential for Smoother Logins: In the future, DBSC might allow for smoother login experiences if the need for complex verification steps (like multiple-factor authentication) is reduced due to the strengthened session security.

Remember:

DBSC is still under development, so the specifics of session management might change before final implementation.

Privacy Considerations

Device Bound Session Credentials (DBSC) are designed with user privacy in mind. Here’s a breakdown of the critical privacy considerations and how DBSC aims to address them:

Limited Device Information: DBSC doesn’t disclose unnecessary details about the user’s device. It focuses on verifying the device’s ability to store the cryptographic key, not its specific characteristics securely. This helps protect user privacy by not creating a unique device fingerprint.
User Control Over Keys: Users control the keys used for DBSC sessions. They can delete keys associated with specific websites, revoking access from that device. This allows users to manage their privacy preferences and limit access to websites they no longer trust.
Transparency and Standardization: The development of DBSC is happening openly through the Web Incubator Community Group (WICG). This allows for public scrutiny and ensures the protocol adheres to privacy-focused regulations like GDPR and CCPA.
Focus on Session Security: By strengthening session security, DBSC aims to reduce the reliance on invasive tracking methods currently used by some websites to prevent fraud. This can be a positive step for overall user privacy.

Challenges and Considerations:

Long-Term Key Storage: While DBSC doesn’t collect extensive device data, the long-term storage of keys on user devices raises some privacy concerns. Mitigating strategies like secure key deletion and user control mechanisms are being explored.
Integration with Existing Login Systems: Integrating DBSC with existing login systems (like social logins) might require careful consideration to maintain user privacy throughout the authentication process.

Overall, DBSC prioritises user privacy by design. It offers a way to secure user sessions without compromising user data or creating extensive device profiles.