All posts in “main”

The new Adobe AIR damages the Passpack Desktop’s Local Storage

Your attention, please.

The new Adobe AIR, on some Operating Systems, resets the Encrypted Local Storage where the local Passpack Desktop data are stored. So, please, before upgrading to the new Adobe AIR, do a backup of your local data from “tools > backup” so that, if the data will be lost after the upgrading, you can restore it.

If your data is lost, the only way to recover it is to restore the status of your operating system to a restore point before the upgrade to the last Adobe AIR. Some users were able to recover all the data this way. After recovering the data, please, backup the entries before upgrade again and restore the entries after restarting the account.

Quick PIN on mobile devices

The biggest problem with the mobile version of Passpack is typing a long Packing Key. People often type the wrong one and have to repeat the process. That’s painful on a touchscreen keyboard.

So, I have just released a solution that solves this problem: a 4 character  PIN that substitutes your Packing Key. This PIN is device specific, in other words, you set up a different PIN for each phone and tablet.

It works in a very simple way:

  • your Packing Key is encoded using a randomly generated key
  • the random key is stored in the local storage of the broswer on your device
  • the encrypted Packing Key is send to the our server with the PIN

Next time you login to Passpack on that device, you’ll be asked for the PIN instead of the Packing Key. You have 3 attempts to type the correct one. At the third mistake the PIN will be deleted and yo’ll need to type the Packing Key as usual.

When used with the Remember me option, this is a great time saver!

Managing PINs and devices

From the Settings page, you can see what devices you have already activated and, possibly, remove them.
This is particularly important if you lose your mobile device.

About security

Initially I was thinking to use a numeric touchpad, like the kind many apps use for PIN numbers. But the risk is that you could be tempted to use the same numeric PIN that you use to access your device – and that would be bad. We don’t want anyone who can enter your device to be able to enter your Passpack account as well.

For this reason, I decided to allow a text PIN. This way you have a really better PIN since you can use everything, included international characters. For example, your PIN can be a string like arfk or xsTT but you can also decide to use a crazy strong PIN like Aò高8 that would be impossible to be guessed in three attempt. This strongly increases the security as compared to, for example, an ATM PIN.

Note. The quick PIN system needs an HTML5 browser to work. If your browser is not compatible, you won’t see the option to activate the PIN.

Solved an issue with corrupted exchange keys

From time to time, we receive a ticket from a user who is unable to invite another user, because the recipient can not see or accept the invitation. I have tried to replicate this issue without success, so my workaround has been to manually delete the invitation from the database so that the two users can restart the process. Generally this worked.
The strange thing was that the problem was repeating always within the same teams. As you know, Passpack has been built to be personal and private. So the best practice, in any case, is that one user access one account. If more than one user accesses the same account, this can create unpredictable problems.

A pratical example

We have three users: Bob, Alice and John.
  • Bob accesses his personal account (good!). Instead Alice and John access the same company’s account (bad!).
  • Alice invites Bob.
  • Before Bob has a chance to see the invitation, John checks for updates. The system finds a request for exchanging keys that is related with his current account (that Alice is also accessing, remember), elaborates the keys and delete the original RSA-encrypted keys for security purposes.
  • When Bob checks for updates he finds the invite, but the system is not able to generate its own keys because the original keys have since been removed.
  • The result is that Alice has invited Bob, but Bob can not see or accept the invitation because the exchange keys are bad.

How to fix the issue

When I discovered this practice I finally understood what was causing the key corruption. So I’ve added a more sofisticated control to avoid the problem. But, since it is impossible to propagate a change to previous versions, it was necessary that all the involved users reload their Passpack page to have the latest version of the application. If not, the invitations may seem correct but the user will not be able to see any shared entries because his keys are not compatible with the current keys of the sharer.
If you are experiencing a problem with invitations or with users that can not see any shared entry you should follow these steps:
  • Be sure that you have the latest Passpack version (logout and reload to be sure)
  • If you have tried to exchange secure messages with the user, delete all those messages and ask the other user to do the same
  • From the People tab delete  the invited user
  • Ask the other user to press their check for update button to verify that there aren’t any invitations from you
  • Invite him again

If you have any issues please open a support ticket.

We are going to change the feedback forum

We’ve been using UserVoice for a while to manage user feedback.

UserVoice is a great service to collect suggestions and ideas. It worked very well and now we know what is important for our users. But there are a lot of minor suggestions that are also important which remain without an answer. And, in many cases, people ask for a feature that already exists. If there were a live conversation, some other user might be able to quickly answer: “Hey Joe, you can already do this.” Instead, there  is no live converation and everyday someone adds a suggestion that risks getting lost. This is not good.

So, in the next weeks, we will try to limit the UserVoice forum to big suggestions and we will move the everyday feedback towards our Facebook page. Why Facebook? Because it is easy and social and solves the “conversation” problem. Of course, please don’t consider it a support page and especially don’t write any sensitive information. If you need customer support on your account, please open a support ticket instead and we will help you.

The Passpack Facebook page would like to be a place where you can start conversations with us and with other users about best practices, ideas, issues, etcetera.

What do you think?

 

Our provider has been hacked, but Passpack is safe. Zero data compromised.

First things first: your data is safe. 

Passpack runs on dedicated servers at a provider in Germany. Yesterday, that hosting provider was likely hacked into. Due to our application architecture, and the fact that we’ve completely isolated the servers from any access by the provider, Passpack has not been compromised. All user data is secure.

This announcement is simply because we believe in transparency.

Why Passpack was not affected

Fortunately I don’t trust anybody, not even our hosting providers (Passpack is, after all, built on the “Host-proof” Hosting pattern). As soon as our dedicated servers were delivered to us with the OS installed, the first order of operation was to make it so that our provider was completely unable to access our servers. Every default password was changed and (most importantly) the SSH setting only allows access via keys. Yes, that makes it more complex to handle eventual hardware problems, but it’s worth the trouble. Today, when I read the communication below, I knew it was the right choice.

This is the communication that we received today, like hundreds of others:

Dear Client,

We were informed yesterday, Wednesday 5 October, about an improper access to our internal system.
As far as we can presently reconstruct, the attackers could have been able to access internal customer data on [our] administrative systems.
[...] To our present knowledge we have no information regarding data abuse from customers.
Unfortunately, it is not possible for us to exclude this possibility completely and we would therefore ask that you change all passwords on your [Provider] system immediately as a precaution.
[...] To ensure complete and transparent clarification, we shall shortly be reporting this incident to the regulatory authorities.
[...]

As always, we’ve taken follow-up security available to us for good measure. We immediately updated the credentials to login to the the online account manager. Nobody has accessed the account manager, or changed any settings.

My biggest concern was that with access to the provider’s account management system, though they couldn’t have accessed any user data, a hacker could have been able to reset a server: starting a new installation while deleting all the current data. Fortunately, they didn’t. And the access codes have all since been changed. As you can imagine, this would have caused an interruption in service until we’d have reconfigured everything and restored the data from our remote backups.

A secondary concern would be that they could have gotten physical access to the servers while putting it into maintenance mode. Also in that case, there’d have been a noticeable downtime. There wasn’t. Anyway, as you know, our data are useless without hacking the entire distributed system.

Since we had no problems or outages, I could have easily not informed anyone about this. But I believe that transparency is the most important thing for a service like Passpack. So now you know.

Have a good day, and let me know if you have any questions.

Shared Tags Are On, Also in Bulk Edit Mode

Today we’ve released two long awaited features: the ability to include tags along with the entry sharing and the ability to apply tags in bulk edit mode.

As a background: when we first introduced tags, we had considered them as a personal way to organize your data. Technically the Tags data was encrypted separately from the Entries data, in a different, simpler way and… couldn’t be shared the same as entries could be.

So once you all made it clear to us that you did indeed want to share your tags,  we were faced with the problem of how to introduce that feature securely, without completely overhauling the way entries work (Passpack is stable, why risk critical bugs?).

ScreenHunter_05-Jul.-19-23.30

Initially we were thinking of changing the logic of the Tags collection, but the risk of add critical bugs was too high. So in the end, we opted to use a sort of plugin to the entry to contain extra data. This extra data is perfectly sharable and is integrated dynamically in the Tags collection, without changing any of its rules.

This approach solved the immediate problem of how to share tags, but it also will allow us to expand the entries in the future too. I am sure that you have a lot of ideas about what can be added to standard entries. So let us know!

Oops, I was forgetting that if you want to transfer an entry to another user preserving your tags, set the tags as shared and you are done.

Bulk Tag Editing

ScreenHunter_10-Jul.-24-17.05

We also added the ability to apply tags in bulk edit mode. The options should be self explanatory. A couple of particular cases are:

  1. If you want to delete all the tags, leave the field empty and chose the merging option “No, substitute them instead” (the logic here is that you are substituting all existing tags with nothing – it’s the equivalent of deleting them).
  2. If you want to quickly convert the settings on a bunch of shared entries  to incude tag sharing all at once, without changing any of the actual tags, leave the field blank, leave the substitution checkbox unchecked, and select the “No, activate tag sharing on all of them instead.
For those of you who have been waiting for the shared tags feature, you should find #2 above very useful.
Don’t worry about mistakes, in bulk edit mode the autosave is disabled, so if something looks wrong you can safely undo the changes.

What else?

The version 7.7.7 of Passpack fixes some minor bugs and improves performance a bit. For example, the tags format has been optimized and now during encryption and decryption the process is faster.
Also, as you can see, the entry table has been enlarged and a smaller font size is used to allow for longer titles.
Finally, there are two new themes in Settings > Appearance & Themes. The Warm Grey theme is inspired by Google+ colors, and the Khaki Brown theme was requested by Allen – Allen, if you don’t like it, let me know :)

Passpack is not LastPass. We Have a Big Friend

A few weeks ago LastPass had a serious breach of data. I don’t like to talk about the competitors, but this unlucky event generated a lot of articles, concern and fear. It also caused an increase in emails from Passpack users who are seriously concerned about their security and want to understand if what has happened to LastPass can happen also to Passpack.

I think not, but I can’t be sure because I don’t know the architectural details of LastPass, and I don’t know what happened to their data. I can say however, that compared with what I understood from their post, we use a few different approaches. For example, it seems that they had all the services on the same network. We have always had totally separate sandboxes for the different Passpack properties. This eliminates the risk that a bug in the blogging or support ticket systems could open up the core application to attack.

But speaking more specifically to the data loss and the risk of a dictionary attack issue, we use a non-standard approach to work around this risk. I’ll explain that here, and at the bottom of the post is also some code so that anyone, LastPass included, can employ it if they’d like.

Let me tell you a story

When I was a child, I was fragile, thin, short and delicate. I was the typical victim of children bigger than me. I remember that during a Christmas vacation, after having been bullied yet again, my grandfather said to me: “if you can not defend yourself, you need a big friend that can defend both of you”. I took his advise, got a big friend, and I never had problem for the rest of my childhood.

Still now that I am a grown man, I am more at ease knowing that I can count on a big, trustworthy friend if necessary. We’ve used this “big friend” approach in Passpack as well. It’s one of the components we use in solving the hash problem that is the main focus of this post. The full details are very technical, so please be patient.

About openness and reactions

I don’t always agree with LastPass’ choices (see my post on how sharing “masked passwords” is a serious security hole), however they are a good company, and their choice to inform their users about what was happening in a quick and open way was the right one. They knew the risks of that choice, but they chose to do what was best for their users over what was best for their public image. I applaud them and would surely do the same.

The reaction of the press to their announcement was less impressive. I was surprised by the superficial knee-jerk reactions from some blogs, including the prestigious LifeHacker. Instead of investigating to understand if there could have been ways for an online password manager to have avoided such an incident, they simply assumed there was not and suggested users go back to offline tools.

This is not a solution. It is a step back of at least five years and doesn’t help people that need something that only the cloud can offer – collaboration and access. Every day we all connect to Facebook, Twitter, PayPal and many other services. If we refuse to persevere and solve important issues in the cloud, then we might as well you turn off our computers now. Problems need solutions, not avoidance. Maybe the current solutions are not ideal, but if we stop the progress we will never have a definitive solution.

Premise: your security is your choice

We can call the best engineers in the world to manage our server security, but if you join the name of your sons and use it like your Packing Key you are very lucky if nobody entered your account yet. So, the first thing to do, in any case, is to choose a really strong Packing Key. Believe me, it is not difficult. A good pass phrase could be something like: my grandma had a strange green bbq or when I jump I can not stop laughing. You simply need a sentence that is  easy to remember for you. You will discover that it will be also easy to write. And, most importantly, I can tell you that it will be very resistant to every attack.

About passwords and hashes

Here are some basics. Every web application that doesn’t use a federated authentication system (like Facebook connect) needs something form of password to identify the user. Old systems used to save the passwords directly in a database. Recently (fortunately) most will save a derivation of the password generated using an hash function instead. What is a hash?

cryptographic hash function is a deterministic procedure that takes an arbitrary block of data and returns a fixed-size bit string (via Wikipedia).

There are certain algorithms that can take text, and create a different text that identifies it – it doesn’t transform it, it just identifies it, like a fingerprint. The result is called a hash string, and that string can’t be reversed. For example, if you take the Wikipedia definition above and run it through a SHA1 hash function, you obtain the following result:

e98dc145444d8758633e73d175a1715e1cdb17e7

Now, if you change just one thing, anything in that Wikipedia definition, then you will get a completely different result. For example, if you remove the period at the end of the paragraph, the new hash would be:

e91090189005b016bd20bb05be5c4fb089fec8d3

As you can see the two hashes are the same length, but they are totally different.

Here’s another example. If you hash the word “password” you get another different result, but again, it’s the same length, 40 characters:

5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8

So every string that you hash with a SHA1 function has always the same size, being (almost) always different. It doesn’t matter how long or short the original text is, it will always produce the same size hash. Both your ATM PIN number and “War and Peace” would both have a hexadecimal 40 character hash. This makes hashes perfect for identifying something without knowing what that something actually is.

In fact, hash functions are used in your ATM and credit cards to protect the pin.

The problem with hashes

Unfortunately there are methods to discover the original string, starting from the hashed one, even though it’s not technically a reversal. The most used hacking method is the so-called Dictionary Attack. A dictionary attack simply means that the attacker takes an entire dictionary of words, and tries to guess your password. Alas, people tend to use always the same passwords or very common words. Some time ago Twitter banned 370 common passwords from use in  its accounts because it was really dangerous to allow users to choose a password like password, testingnaked, stupid, 123456, etc.

Since hash algorithms are known, an attacker can simply run all the dictionary words through the algorithm and compare the result with an existing hash (perhaps that he’s somehow stolen) and see if they match. When the two hashes match, he then knows what the original password was.

Of course, to make hacking more efficient, there are dictionaries of the hashes of the dictionary words (so called Rainbow Tables), available for the outputs of all the major algorithms (SHA256, MD5, etc.). Therefore,  the very first step in protecting users is to salt their hashes. This means that before running a string through a hash algorithm, some additional text is “mixed in” with it  (like adding a dash of salt to your hash browns :) so that the result is at least not so easily looked up in the dictionary of hashes.

At Passpack we use several different combinations with iterations of SHA256 adding in the user’s clientcode as salt. Since that is unique for every user, even if two users use the same Packing Key the hashes will be different. Does that completely solve the problem? No, not yet. It’s a first step to raising the bar a bit since it wards off mass attacks, forcing a potential hacker to try and match hashes one by one.

So at this point, if you’ve been paying attention, you should realize that if you chose a strong Packing Key, then you would not be susceptible to these dictionary attacks (and if you don’t have a strong Packing Key, now is as good a time as any to change it).

We can urge you all the time to create a good Packing Key, but it’s still our job to build the system to be as a secure as possible, regardess of your choices. That means that for all the work we do to build a secure server infrastructure, and make it as close to impossible as we can to penetrate it, we still need to plan for the rare case in which someone does, indeed, get in. Everyone works hard to make sure that this doesn’t happen, but sometimes it still does. This is what just happened to LastPass.

So what are the possible solutions to protect users?

A common solution: iterations

One of the methods used to minimize the risk of a dictionary attack is a strong key derivation function like PBKDF2. According to their post, this is the solution LastPass is looking into.

It works like this: instead simply saving the hash to the database once you receive it on the server, you first run it through another algorithm… many, many, many times. For example 50,000 times. Then you save that to the database. By doing so you slow down the potential hacker by the same number of times. This makes cracking the hash wildly inefficient for the hacker, if not impossible.

The problem with this method is that the server has to work intensively to derive the original hash and you’ll wind up with some serious performance issues. The result is that you can not use this method if you have a lot of users because you risk continuous server downtimes. PBKDF2 is therefore not a real solution for web applications.

The Passpack solution: distribution

Passpack is a small company. We do our absolute best to build the safest infrastructure possible, but we can not spend a lot of money to build our own bomb-proof servers. So I decided to find a big friend, someone that  can share with us the work and, in defending himself, defends us as well.

I wrote a super simple application on Google App Engine called Spino. Spino runs on a Google account that I use only for this app and for nothing else. Spino collaborates with Passpack to create a distributed solution for the hash problem.

How does it work? It’s quite complex, but here’s a simplified description:

  • The User types his Packing Key
  • The Browser applies an hash function to the Packing Key using the clientcode as salt
  • The Browser sends the hash of the Packing Key to Passpack
  • Passpack sends the temporary hashes to Spino
  • Spino verifies it is receiving the hashes from the real Passpack
  • Spino applies a secret hash function to the original hashes and sends it back to Passpack
  • Passpack saves this result in the database

Until some time ago, Spino was on another server and probably in the future we could move it on some other one. Also, to further strengthen the pattern we could distribute the hash manipulation across multiple, external apps on multiple servers using different technologies.

The risk in a solution like this is that if the external platform — in our case Google App Engine — goes down, it would be impossible to login to Passpack. But since we’ve implemented this solution, we’ve had no such complaints. On the other hand, the big advantage is that even in the rare event that an attacker were to grab the Passpack database, he would not be able to do anything with it unless he is also able to penetrate Google.  And Google is a really big friend.

To maintain good performance, once again, we use an encrypted cookie as a distributed cache. In fact, only the server can decrypt the cookie, but the server needs the browser to access the cookie itself.

As you can imagine, Passpack uses other techniques to strengthen the theoretically weak points, though I can not tell you all of them. Another thing that my grandfather used to say often was: “Always tell the truth, but keep a little something for yourself”.

Do you like Spino?

If you like Spino’s approach, feel free to use it. It is open to all.

When I decided to move it from the previous server to Google App Engine, in a week-end I learned Python and I ported the script, so I am sure that you can create and deploy your app from scratch in 20 minutes using the following code.

#
# Spino, a remote hasher
# version 1.2
# Copyright (c) 2009+ Francesco Sullo, Passpack SRL
# Licensed as Open Source under MIT License
#

import hashlib
import os

from google.appengine.ext import webapp
from google.appengine.ext.webapp.util import run_wsgi_app

def hashx(val):
    salt = 'Wow! I am a super salt. Please change me!'
    # just a few interactions
    iterations = 20000
    cont = 0
    while cont < iterations:
        m = hashlib.sha256()
        m.update(salt + val)
        val = m.hexdigest()
        cont = cont+1
    return val

class MainPage(webapp.RequestHandler):
    def get(self):
        self.response.headers['Content-Type'] = 'text/plain'
        try:
            a = self.request.get('a')
            e = os.environ['REMOTE_ADDR']
            # set your authorized referer IP or IPs:
            if e == '100.100.100.100':
                ret = hashx(a)
                self.response.out.write(ret)
                return
        except:
            pass
        self.response.out.write('Hello, World!')

application = webapp.WSGIApplication(
    [('/', MainPage)],
    debug=True)

def main():
    run_wsgi_app(application)

if __name__ == "__main__":
    main()


This is a simplified version. But it works :)

UsePass: Third Party Chrome Extension For Passpack Autologin

Four weeks ago Kenneth Henderick contacted me because he wanted to build a Chrome extension to substitute the Passpack It! button, improving it. I really liked the idea, so we worked together a bit and I added some features to Passpack in order to provide him with what he needed to build UsePass.

If you are a Chrome user, you can download and install it from here.

UsePass supports multiple accounts. So, if you administer a company account and have also you personal account, you don’t need two buttons anymore.

It also supports a keyboard shortcut. This is very useful because one of the limitations of the Passpack It! button is that you need to visualize the button bar of your browser to click it. So when a login form is displayed in a popup window – without bars or a menu – it won’t work simply because you can not click it. With UsePass you can press your keyboard shortcut and magically you login to the website.

What About Security?

As you probably know, the Passpack It! button contains a special Autologin Key used to encrypt and decrypt the data necessary in order to autologin to websites. This is important because it also guarantees that the autologin data temporarily stored in our database is encrypted and fully adheres to Host-Proof Hosting.

UsePass, to do its job, needed to know this Autologin Key. Since it can only access DOM elements in the Passpack page, I added some special hidden DIVs containing the User ID, Autologin Key and the Autologin Key reduced hash. UsePass, during configuration, reads this data and has all it needs to do its job.

A note. UsePass simply runs the same process the Passpack It! button runs. So, if the autologin doesn’t work on some website don’t write to Kenneth, write us. :)

Have Fun

I installed the extension and it works perfectly. Also, Kenneth told me that if the UsePass for Chrome is appreciated by users, then he could develop a Firefox version as well. That would be great, wouldn’t it? So give him your feedback.

NOTE: Currently UsePass doesn’t support the double-click of the button. You need it, for example, to add a new entry in your account directly from the signup page of a new website or to copy/paste your credentials when autologin doesn’t work. Don’t’ worry, Kenneth will add it soon.

 

Why Masked Passwords Are a Serious Security Hole

Time after time, there are users that ask for the possibility to share “masked passwords” with other people. What is a “masked password”? It is something that you share with another user in a way that allows him to use it (for example for autologin) without actually seeing the password itself.

When I respond that this isn’t possible to implement in a secure way, and that I don’t want to open a security hole in the Passpack experience, people have pointed out to me that other software offers this feature. Unfortunately, several users have left Passpack for this missing “feature”. So I’d like to explore the matter further with you.

Look At How Easy It Is

You probably are not a Javascript expert. And you probably think that it is necessary to be a Javascript ninja to intercept a “masked password”. However, that isn’t so. Look at the following code:

var Jq;
(function () {
  var D = document,
  h = D.getElementsByTagName('head')[0] || D.documentElement,
  s = D.createElement('script');
  s.src = 'http://ajax.googleapis.com/ajax/libs/jquery/1.5.2/jquery.min.js';
  h.appendChild(s);
  function run() {
    if (typeof jQuery != 'undefined') {
      Jq = jQuery.noConflict(true);
      Jq('input:password').change(function () {
        alert(Jq(this).val());
      });
      alert('Ready.');
    }
    else setTimeout(run, 50);
  }
  setTimeout(run, 50);
})();

Even if you don’t understand what’s written there, you’ll notice that it’s short. This bookmarklet code loads a standard Javascript framework (in this case jQuery) and runs the red code that “watches” every password field. When the content of a password field changes, this code will cause the browser to show you an alert revealing the password in the field.

Now imagine that you had shared a “masked password” with a co-worker. You may feel safe because you believe that since he cannot read your password, then he can not access it. This false sense of security would likely lead you to ignore the best practices while sharing — ex. changing the password everytime that you remove someone from sharing. In other words, you would probably continue to use your no-longer-safe password.

Without knowing any programming language, your co-worker could load a login page, run a simple Javascript code like the one above, click the button that starts the autofill… et voilà, he’d know your top-secret “masked password”.

Do You Want To Try?

Drag the following link (containing the code above) on the button bar of your browser:

Afterwards, go on every site that you want and try for yourself how is easy to capture your passwords. Alas, you can also verify that it works with all the popular password managers, regarldless of whether or not they use password masking.

What About If There’s No Javascript Enabled?

Imagine that there is a super-magical-auto-filler that deactivates Javascript before filling the password field. Would this make you safe? No, because your “masked passwords” can be captured even without using Javascript.

How? Here’s an example for which you would need more than a few lines of code, and would need to be a little more creative. You could install a web server like XAMPP on your computer and create a catch-all index file that prints everything it receives. This would require just one line of PHP:

print_r($_POST);

Then:

  • You connect to the website that you want the password for, for example Google
  • You edit your local hosts file and assign google.com to your local IP 127.0.0.1
  • Click the autofill button to login to Google
  • When the browser complains that the certificate is wrong, click “ignore it and continue”

As you can guess, the next page will print the content of the form that should have been received by Google, but was instead intercepted and printed to your screen. Once again, the masked password has been revealed.

Conclusion

There are plenty of other techniques that a person could use to capture a password field from within his browser. The real take away here is that you understand it is not possible to truly mask a password that transits in the browser of a user. So, please, don’t tempt fate. Change your password everytime it is necessary, especially after having removed someone from sharing it.

 

 

 

 

New themes for Passpack

Are you tired of always seeing the same colors in your Passpack account? Or would you simply like a change?

From today you can. We added the possibility to select a theme in ‘Settings > Appearance’. There are only three themes for now, but we can certainly add more as time goes on if you like it.

And to stimulate you guys to actually try out the new functionality, we’ve changed the default theme from the original cool-green to a brighter one.

Personally, I love the new green, but if your prefer the old one or want to try the new ice-white, you can simply go to Settings > Appearance to change it back. You’ll be able to see the change in real-time in your browser.

Last but not least, if you want to suggest a new theme with your preferred colors, let us know and we will add it for you.