Vesting browsers with our trust

We recently wrote about the Quant malware coming with pre-packaged password stealing capabilities. We all understand that physical security is important, choose our locks carefully and consciously keep our keys where we believe they will be safe from being stolen, but do we adhere to the same standards for our passwords? 

Probably not… 

Examples of stolen credentials 

When working with data we gathered from various Quant Loader C2 servers we also validated some of our assumptions regarding average password strength. As expected the majority were not on the strong side and there were some real eye openers.

A Digital Key-Hook 

Unfortunately, as can be seen from the examples above, the intangibility of passwords often results in people being significantly less worried about them than something physical – we need look no further than the recent controversy over British politicians sharing passwords for a real-world example of this.

Voluntary password sharing aside, people are generally unwilling to remember a couple of dozen different passwords and PIN codes and tend to trust in software to remember things for them.

There exist a number of applications which act as 'virtual safes' to hold our passwords and keep them away from prying eyes. Uptake of these services is outside the scope of this blog, but modern web browsers can be considered as minimalistic password keepers as well – and are frequently targeted by 'stealer' malware.

Sticky-Notes, Text Files, and Encryption 

Before we take a look at how some popular browsers do it, let's consider how passwords should be stored. 

Hopefully everyone reading this blog knows not to write passwords down on sticky notes, but potentially few people dwell for long on how their passwords are stored electronically. Similar to the difference in perception between a physical key and a password, it’s often easy to forget that saving a password is effectively writing it down electronically. 

Plain text needs no further explanation: this is effectively the electronic equivalent of a sticky-note, whoever has access to the file can just read our password. 

Passwords are, therefore, generally hashed. Hashing the password means that the value stored is the output of a one-way transformation and cannot be reversed: when something needs to verify your password it hashes the value you entered and compares it to the one stored, thus negating the needs for the storage to be reversible. 

Unfortunately, to retrieve a password where only a hash is available is not always that difficult. Owing to the fact that the hash (be it MD5, SHA1, SHA256, etc.) of a given piece of text will always be the same, it is possible to work backwards from these to plain text values for common passwords very easily - tables of known hashes for common passwords exist for this purpose. This is at least part of the reason why people have long been advised not to use obvious passwords like ‘abracadabra’ and ‘opensesame’.  

Secure local storage therefore incorporates a number of additional steps such as cryptographic salts and peppers, with extra layers of protection (i.e. asymmetric public/private key encryption) for any passwords in transit.

Browser Implementations 

So how difficult is it to steal passwords from a browser? We looked at Firefox and Chrome, two of the most popular browsers of 2017, both of which provide simple solutions for saving passwords for internal and external sites.  

Firefox 

Unless a site is added to its exceptions list, Firefox will ask whether we want it to save passwords for a given web site. If we opt to save our password, data will be stored in an encrypted file named ‘logins.json’ under our profile. Unfortunately, the decryption key is stored in a separate file called ‘key3.db’ which is kept in the same directory. 

That said, there is the additional ability to encrypt saved passwords further by providing a master password. This results in a new popup window asking for our master key the first time a user wishes to use a saved password, after which there won't be another master password prompt in the same session until we restart the browser.  

Assuming a strong master password is chosen – any wannabe thief would need both of the data files and to learn the master password to retrieve the saved credentials.

NOTE: Both of the examples in the screenshots below are for a dummy account created for testing purposes.

Chrome 

Chrome's password manager implementation is very similar to Firefox's offering, with a small exception, by default it is lacking a built-in master password feature. As such, if Chrome is the browser of your choice - and you like to save passwords within your browser - we highly recommend getting a plugin which provides similar functionality. 

Chrome used to take advantage of security features provided by the OS, however, in a default Windows environment, passwords are now stored in a SQLite database file called ‘Login Data’. Similar to Firefox, attackers with local access will be able to gather the additional encryption keys to decrypt the contents of the ‘Login Data’ database.

Recommendations: Usability vs Security 

There will be always a trade-off between usability and security: our desire for the former means that we want to access our favourite services with just a few clicks, but the reality is that we need the latter to ensure we can trust in these services. 

So, what shall we do? As noted earlier, there are any number of third-party credential management tools aimed at both consumers and businesses, the suitability of which is outside of the scope of this blog. 

Alternatively, by choosing our passwords carefully we can ensure that they are memorable and secure. Many people are already familiar with the concept of a passphrase such as: 

MyDog’sNameIsRuffles

This password has 114 bits of entropy (as estimated by KeePass). While these are all dictionary words, running lots of them together makes a brute-force attack take much longer and reduces the chance that someone else has already used the same combination before (i.e. the likelihood that the hash will appear in an already-cracked table somewhere). 

To compare, the following has only 50 bits of entropy:  

S7ng0pl! 

Improving further on this, there are static aspects of web sites and services - such as the URL, title or domain - which could act as a manual-but-memorable ‘salt’ to our existing passwords. Picking or generating a strong ‘core’ password or passphrase and enriching it with such a pre or post fix can result in different passwords for every site, yet ensure that remembering it is simple enough and we won’t be tempted to save it.  

With the extra 'salt' on the end, this password now has 167 bits of entropy: 

MyDog’sNameIsRuffles$4PhotoStorage 

Finally, remember that credentials can still and do get stolen by other means. Combining a strong password with two-factor authentication (2FA) can effectively stop thieves in their tracks: even if they succeed in acquiring your now-supercharged password, they lack the second factor to get into your account. 

Unfortunately, many websites have yet to offer 2FA and, even worse, they often have a weak password policy – would you really trust someone accepting '12345678' as your password or denying 'MyDog’sNameIsRuffles' ^{(NOTE: 1)} due to containing a special character? It's up to us to ensure that we have a strong password, but it may well be time to consider rejecting services which don't support us with this.

Conclusion: Why All of this Matters 

In short: because passwords are the proverbial ‘keys to the kingdom’ for most people. 

In 2017 NIST updated their guidance on passwords to recommend against draconian password changing frequencies and complexity rules, mostly because they do little to combat credential theft and may, in the worst cases, drive users to insecure storage of their hard-to-remember passwords.  

For home users, data protected by passwords will be everything from holiday photos to sensitive personal data which could potentially expose them to blackmail or financial fraud. For business users, the same issues exist but with the added concern that credential theft is a common way for IP thieves to impersonate authorised users. 

While solutions such as Forcepoint UEBA can be used to identify unusual patterns of behaviour associated with stolen credentials, prevention has always been and always will be preferable to post-hoc detection. 

Attackers will continue to focus on the human point of interaction with systems, and until weak password habits – in terms of password choice, storage, and policies – cease to be an easy line of attack, they will remain a prime target. 

It can be easy to look at the myriad ways credential theft takes place and find oneself quite resigned, but it is entirely possible to make a difference: after all, if the safe only contains a blank piece of paper, what was the point in stealing it? 

^{(NOTE 1): The author’s dog’s name is not Ruffles.}