Skip to main content

Share access without giving away your password with SessionBox

Share your sessions

Did you ever wish to pass over one of your accounts to a friend of yours? Or is your company using shared accounts for your daily activities? Well, there are some solutions, but all of those include sending over your password to the other party - sometimes client side code tries to hide this fact, but any savvy user can easily get around that.

With our latest release (1.0.35) we have added a new feature, called Session sharing. With this brand new possibility we provide a new way of sharing your accounts, without sharing the password itself. Moreover, you can limit the timespan of the sharing itself, so if you just want to show something to your friends, you can give them access for an hour, then they won't be able to access your account again.

How to start sharing?

  1. Open up the context menu for the session you wish to share. You can see a new item here, called "Share..."

  2. Select the domains you want to share.

    Browsing around on the internet injects many cookies into your browser, even from sources you don't expect. As a rule of thumb, always filter out cookies that do not belong to the site you wish to share. This is important, because if you share a session to which you logged in with Google, you SHOULD filter out the google.com domain, until you wish to share your Gmail as well.
  3. And lastly, you can enter the receiver's email address, and set a time limit for the share.

    When setting a time limit, please note that sessions can expire, in which case, the receiver won't be able to use it, as they will be logged out, just as you would be. We are working on improving this experience. If the receiver is not yet a SessionBox user, we send them an invitation. After their registration, you will need to restart the sharing process. This is for your safety, our safe, Zero knowledge security technology requires us to have public keys from the receiver, without which we have no way of safely solving sharing, so we are not allowing it.
  4. Congratulations, you shared your first session!

Comments

  1. افضل خدمات الستلايت الان و علي اعلي مستوي الان ستلايت السالمية من الان من لتميز من خلال افضل ارقام فني ستلايت الفروانية متخصصين افي اعمال الستلايت الان و علي اعلي مستوي فني ستلايت حولي الكويت الان من التميز فني ستلايت الجهراء هندي و بافضل كفائه الان في اعمال التركيب و تعديل الاشاره الان من خلال موقعنا فني ستلايت الكويت تواصلو معنا الان واحصل الان علي افضل الخدمات الان

    ReplyDelete

Post a Comment

Popular posts from this blog

An introduction to SessionBox - what's this and why we are doing it? Develop web applications, test new features, log out of personal Gmail, log in with a test account, then repeat to check with another one. Probably use different browsers, or Chrome profiles, so that I won't need to re-login for every test. Quite a pain. Mainly this continuous context switching and re-login (mostly even with 2FA) was the reason why we started thinking about finding a solution, that could persist different contexts in one single browser, using different tabs. And that's exactly what SessionBox does. Handle both Personal and Work related sessions in the same browser window. Eg. multiple Google / Gmail accounts can be easily used at the same time. Our pain of dealing with continuous user context switching lead to a hobby project, that has already reached over 38.000 downloads, and more than 25.000 monthly active users. This was the number at which we thought this might lead

Be secure with SessionBox

A large percentage of web based attacks can be avoided with careful planning and implementation of the website's code. However, a large portion of attacks directly target the user's browser, where the protection imprinted into the server side architecture is many times not enough. This is the area where SessionBox helps you. A number of different attack methods base their attack vector on the fact, that users are already logged into other websites. Let's take an example. You are probably logged into Facebook. When you visit a site - let's call it example.com - this site runs many scripts inside your browser. Where you have active sessions for Facebook.com. This means that example.com can for example send requests to Facebook.com - where you are already authenticated - and make actions on your behalf. Moreover, example.com might be a trusted site, but they can also be attacked, and if they are not prepared against XSS attacks, a savvy hacker can inject their scrip