In 2015, the UK government released an article advocating the use of 3 random words in passwords, citing "pragmatism and algorithmic strength against common issues like brute force attacks".

#Thinkrandom when creating passwords – #use3randomwords to make them https://t.co/6BlS8EqK7v pic.twitter.com/qtA43ffLf6

— Cyber Aware (@cyberawaregov) April 21, 2017

2 years later and a plethora of respected Twitter users continue to push this advice. If you're one of them (looking at you @WMPDigitalPCSO @DurhamCyber @SurreyPolice @nerccu @ncsc @HP_Cyber @metpoliceuk @cyberawaregov), I implore you to read this article thoroughly and reconsider your position.

Understanding the basics...

After you've entered your chosen password, a responsible site should store it using a suitably-strong password hashing algorithm (bCrypt, PBKDF2, Argon2 etc). Note, I said "password hashing algorithm"... this is a different concept from a cryptographic hashing algorithm. More on that shortly.

The developer, mindful of the threat landscape, value of the data & server resources... will configure their chosen algorithm such that each hash takes a set time to compute. For example, it's reasonable to expect a hash to be generated in 400/500 milliseconds (or roughly half a second). This delay is crucial, as it dramatically increases the time required to brute-force their way into your account. A 0.5 second delay is insignificant to the real user, but a real burden to an attacker needing to try trillions of various passwords.

In an ideal world, sites would all use a well-configured algorithm & users would opt for strong, truly random passwords. But, that's rarely the case.

Getting the basics wrong...

Another, entirely inappropriate storage method is a cryptographically strong hashing/digest algorithm. The underlying principle remains the same; derive a fixed-length output for any given input. However, these hashes are blisteringly fast to compute... making brute-force far easier. Examples of such hash algorithms are MD5 (still very common and possible to brute-force at a rate of 200 billion permutations a second), SHA1 (70 billion a second), SHA256 (23 billion a second), SHA512 (8 billion a second) and so on.

As this article & indeed most password advice is aimed at the end-user, it's important to choose a password based on the worst case scenario; assume the site stores our credentials in the weakest possible way and mitigate that risk first.

Characters vs words; the premise behind the advice

Long, strong, unique & complex passwords are inherently difficult to remember... especially if you use several websites. This inevitably leads to password re-use, recycling & insecure storage. On that basis, I fully understand the need for an alternative, more-pragmatic approach.

However, are words really a secure alternative? Let's dive in.

The Maths

For an attacker, carrying out a brute-force attack is a last resort; the process of trying every possible permutation in order to break a password hash. It is however, a guaranteed way (given sufficient time & resources) to gain access to an account.

To understand the challenge our attacker faces, we first need to understand exponents.

If our password consists of 8 possible characters and is 3 characters long, the calculation would look like so:

In this example, there are 512 possible permutations; meaning our attacker is guaranteed to access our account after 512 attempts.

Let's take it one step further with a real-world example...

If a password consists of a-z, A-Z and 0-9, we have 26 characters + 26 characters + 10 numbers. Our "base" in this example would be 62. Now let's assume it's 12 characters long, meaning our exponent is 12.

62^12 = 3226266762397899821056 permutations (three sextillion, two hundred twenty-six quintillion, two hundred sixty-six quadrillion, seven hundred sixty-two trillion, three hundred ninety-seven billion, eight hundred ninety-nine million, eight hundred twenty-one thousand & fifty-six)

Obviously, that's an enormous burden to our attacker and results in a password they're never going to break, assuming the password is chosen at random.

It's not all about the base

Now you understand how passwords are stored & broken, we can begin to understand why some believe 3 (or more) random words are a better, more secure alternative.

Compare these...

"MTLWcAXfY4Dy" is a 12-character, random password.
"jumpdeskpolish" is a 3-word, random password. It just so happens to be 14 characters too.

We can represent "MTLWcAXfY4Dy" as upper-case, lower-case & numbers... giving us a base of 62. It's 12 characters long, giving us our exponent of 12.

We've already done the maths on 62^12 earlier, so we know it to be unbreakable if chosen at random.

If we represent "jumpdeskpolish" in the same fashion, it's just lower-case... giving us a base of 26. Despite being easier to remember, it's also longer at 14 characters, giving us our exponent of 14.

26^14 = 64509974703297150976 permutations (sixty-four quintillion, five hundred nine quadrillion, nine hundred seventy-four trillion, seven hundred three billion, two hundred ninety-seven million, one hundred fifty thousand, nine hundred & seventy-six)

Purely on the maths alone, we can see this password has far fewer permutations and is undoubtedly weaker... but that's not the whole story.

64509974703297150976 (permutations) / 200,000,000,000 (speed in seconds to break an MD5 hash, the weakest widely-used algorithm) is just over 10 years!

Success! We've managed to use far fewer characters, made our password easier to remember and it's still going to take over a decade to break. By any reasonable measure, this can be considered secure.

Or is it?

The Combinator Attack

Modern password cracking machines can just as easily rotate characters as words, so "AA/AB/AC" consumes near-identical resources as "appleapple/appleardvark/appleangle" and so on.

But now we're using words, there's a much faster way to break our password.

Instead of representing "jumpdeskpolish" as 26^14, why can't we represent it as 171,000^3?

Confused yet? Let me explain.

The latest figures suggest there are 171,000 words in the English dictionary, meaning our "base" increases dramatically. Our password is 3 words long... so let's replay the maths again.

171,000^3 = 5000211000000000 permutations (five quadrillion, two hundred eleven billion)

Remember, our attacker can break MD5 hashes at a rate of 200 billion a second.

5000211000000000 (permutations) / 200,000,000,000 (speed to break an MD5 hash, the weakest widely-used algorithm) = just shy of 7 hours!

Just by altering the attack, our password no longer provides 10 years security... but a much less confidence-inspiring 7 hours.

It gets worse...

We've assumed 171,000 is the maximum number of words in a modern English dictionary. By doing so, we know that any password containing 3 English words will fall in 7 hours or less.

However, that's not the whole story either.

Let me introduce Susie Dent...

If you're in the UK, you'll likely recognise Susie as the lexicographer and dictionary expert from Countdown. Susie's research demonstrates the average active vocabulary of an English-speaking adult is 20,000 words; with their passive vocabulary being closer to 40,000.

If you're wondering... an active vocabulary consists of words you can recall and use regularly yourself. A passive vocabulary consists of words you recognise & understand, but aren't able to use yourself.

If we take Susie's expert opinion at face value, our calculations now look like this.

20,000^3 = 8000000000000 permutations (eight trillion).

8000000000000 (permutations) / 200,000,000,000 (speed to break an MD5 hash) is 40 seconds. FORTY SECONDS!

We've gone from 10 years, to 7 hours, to 40 seconds. This is simple mathematics folks, no opinions or interpretation here.

Not to cast aspersions on Susie's expertise, but there has also been research which demonstrates a college-educated adult has a vocab of around 80,000 words (or around half of all words in the dictionary). So, if your linguistic ability is comparable to Jacob Rees-Mogg, are you secure?

80,000^3 = 512000000000000 permutations (five hundred twelve trillion) or, at the same rate as before, your 3 "random" words falls in just 42 minutes!

Adding numbers & special characters

I have noticed a couple of Twitter'ers adding "use numbers & special chars too" as a caveat to using 3 random words. This not only undermines the entire premise of memorable words, but has little/no security benefit either.

In the example above, we've gone from a base of 20,000 to 80,000. If quadrupling the base has no tangible effect on security, such that it's broken in under an hour, adding 100 special chars & 10 numbers really won't make a dent.

The underlying issue here is the low exponent... making it exponentially easier to break.

Stronger hashing

Now it's true... I've focussed on the weakest & fastest possible hash which is still widely (and sadly!) in use. If the hash is slower, the time to break the hash increases significantly.

But, if we choose a password assuming the worst possible scenario (MD5, notwithstanding plain-text), it actually doesn't matter how they're stored; it's already either immensely-strong, or unbreakable.

What method should I promote?

Password managers. Nothing else.

The machine-generated passwords they provide (assuming you're using a respectable one!) are quite literally unbreakable at 12 upper/lower/numbers or more, even with the weakest storage algorithms.

Before promoting anything, research & understand the concept and ask yourself... could I/do I do this myself? If you can remember 30+ (or possibly hundreds of) random, 12-character passwords, great... but the majority can't! Rather than promoting passwords as security measures, instead sell the added usability & convenience of never having to deal with passwords again.

Forget the semantics & subtle nuances of password security; upper-case, lower-case, special characters, numbers, words, lengths, storage, entropy et al... humans don't do random, at least not well.

FAQs

"Is 4 random words enough?"
The NCSC's article, upon which the above advice is based, actually suggests 4 random words, not 3. It's not clear why someone arbitrarily opted to lower the quantity of words. But, now we're increasing the exponent, not the base... it'll have a significant impact upon your password's security. However, it's still not enough.

20,000^4 = 160000000000000000 permutations (one hundred sixty quadrillion). Using the same 200,000,000,000 a second figure, that password would fall in 9 days.

"Which password manager should I use?"
There are several, each serving very different purposes. For home/SME users, I recommend 1Password.

How does this compare to diceware?
Diceware is a list of 7,776 words, but they are truly random. A 7-word diceware password could be represented as:

7776^7 = 1719070799748422591028658176 permutations (one octillion, seven hundred nineteen septillion, seventy sextillion, seven hundred ninety-nine quintillion, seven hundred forty-eight quadrillion, four hundred twenty-two trillion, five hundred ninety-one billion, twenty-eight million, six hundred fifty-eight thousand, one hundred seventy-six)

At 200 billion a second, it'd literally take millions of years to break. Note the "base" is significantly lower than our "3 random word" examples, but a slightly higher exponent takes it from broken in seconds, to unbroken in millions of years.

[Edit]
@ramriot just made an important point on Twitter, worthy of an update here...

BTW mentions of diceware as strong should also include that many places that need PW also restrict length thus precluding diceware.

— 🤖 (@ramriot) October 23, 2017

If the site limits password input length, it may be impossible to use diceware.

I've followed the "3 random word" advice. Should I change my passwords?
Yes. Stop reading, do it now.

Summary

Don't use words in passwords. Ever.
Don't try coming up with secure passwords, apart from the one protecting your password manager.
After adopting a solid password manager, don't give passwords another thought... let it do the hard work for you.
If you insist on tweeting "3 random word" advice, provide evidence to substantiate its security.

That's it folks. Please RT.

While watching reruns of Dragon's Den last week, one particular pitch caught my attention.

After Googling the company, I arrived at a page containing SQL errors. Having read the error log, it became clear the site had a critical security vulnerability. After a few tweets, emails & a brief call, the company patched it within 24hrs. Result!

However, something else caught my eye...

... a SafeBuy trustmark.

Clicking the trustmark reveals the following popup...

Interest piqued, I decided to see just how trustworthy this SafeBuy scheme really is.

Registration

SafeBuy offer a 60 day free trial, after which, it's £180 a year.

That's it! That's the entire registration process. The observant amongst you will note the lack of a "I agree to abide by our code of conduct" checkbox and, if you're especially observant, you'll also note the price has gone up to £238.80 too.

The majority of sites ask for a password during registration, but surprisingly, SafeBuy do not.

24 hours later, I receive an email:

Hmm, the password is prefixed with "safe" and what looks to be a random number, 1709121. Remember that for later...

After logging in, you're greeted with your account profile page.

Wait, what?! Toronto, Canada, Freshbooks?! Where did that come from?

In actual fact, the URL I entered (urity.co.uk) redirects to our billing control panel; run by Freshbooks. SafeBuy have wrongly assumed I own Freshbooks... but surely they wouldn't issue a trustmark in their name?

Sigh. The independent vetting process can't be particularly thorough if this slipped through!

As if that wasn't bad enough, I've been automatically featured in their members' directory.

https://www.safebuy.org.uk/directory/computers.html

Hang on, that "accreditation number" looks familiar...

Oh for christ sake! The reputation of "my" business, or rather that of Freshbooks, is now in the hands of anyone blessed with the gift of sight. Thanks "Safe" Buy!

By this point, I've already written this off as insecure, ill-conceived snake oil. But, how deep does this rabbit hole go?

"Credible reviews"

Having all the hallmarks of a "one man band", I doubt SafeBuy has the resources to audit each & every review they receive. What they can do however, is implement the most basic of automated checks to verify a review is genuine. Unfortunately, that doesn't appear to be the case.

Here's my first review:

Trouble is, you get slightly less of a warm, fuzzy feeling when you review... yourself. Yes, I submitted that review... and I was logged in at the time! What's the point of a "trusted" reviews site which allows companies to review themselves?

Security, or lack thereof

Before we get into the shocking state of security at SafeBuy, here's my reviews page:
https://ratings.safebuy.org.uk/freshbooks.com/stats.html

If you're wondering why the images are going crazy and you're hearing some pretty awful music, that's the harlem shake.

You see, the site is so unspeakably insecure, it's possible to embed & execute arbitrary code as if I'm the developer. OK, the harlem shake is a bit of harmless fun... but I could just as easily embed malware or indeed alter anything you see; quantity of reviews, star ratings, each review, their responses... literally anything!

Talking of responses:

On this screen, we can see all our customer reviews and if necessary, respond to them. One of the best ways to judge a company is not from the quantity of reviews (especially as they're so easy to fake) but how they respond to reviews/complaints.

Hmm, there's an ID in the URL. What happens if we change it?

Sigh! It's the review screen for oakhillflooringltd.co.uk.

At first glance, you'd be forgiven for thinking this isn't a major security concern. After all, we can view their reviews publicly anyway. Trouble is, the "reply" button works!

Yes, we can reply to OakHill's customers as if we're logged in as OakHill. It's a good job I'm not in competition with them, or it'd be very easy to destroy their reputation.

Let's recap

In summary, we've visited an insecure website, been assured it's secure & private by a trustmark, registered and been accredited for a brand I neither own nor control, been given an insecure default password (also stored in plain text!), reviewed our own company, hijacked our own review page to deliver fake/inflated reviews and/or malware & had the opportunity to hijack any other SafeBuy member simply by changing a number in the address bar.

It's hard to believe this was designed in collaboration with the Office of Fair Trading!

It's worth mentioning at this point, the OFT closed in 2014... but it adds credibility, so why remove it? </sarcasm>

Responsible disclosure; redefined?

As regular readers will know, I always follow (what we call) responsible disclosure; typically by reporting these issues to the company in an attempt to have them addressed. However, there are those who will undoubtedly claim this isn't responsible disclosure, so let me explain my actions...

The industry is plagued by snake oil, meaningless trustmarks which continue to mislead users around the world. I've no doubt Troy Hunt would agree, given his comments in this excellent article from 2013. By reporting & effectively donating my time to companies which provide them, I am complicit in their questionable practices. On this occasion, the only way to "responsibly disclose" this... is to inform you, the general public, of just how pointless they really are.

Serving malware!

If you visit the site with a VPN and/or antivirus app running, you'll receive an error similar to this:

Why? The site has been infected with malware for months! Thankfully, the site which the malware redirects to has since been fixed... but quite how "SafeBuy" were hacked is still unknown. Keep in mind, their trustmark ensures "total security & privacy" yet their own site falls short.

Summary

I have thinly veiled contempt for companies which claim to be "secure" simply by displaying a misleading image; even more so for those who advocate & facilitate this type of behaviour.

To put it bluntly, SafeBuy is a complete & utter shambles. If you're considering entrusting your firm's reputation to them, I'd strongly urge you to think again.

Notice: This article is a work-in-progress and serves only to address questions from media outlets & Kerv customers.

On the morning of June 21st 2017, I received an email from an "anonymous" Kerv user... coincidentally the same day I received my Kerv ring.

Nothing unusual there, apart from the fact it contained my name, home address, phone number and memorable information. Oh dear...

As regular readers will know, I use 1Password to generate both passwords & memorable information; meaning a breach of such information doesn't adversely affect other accounts I hold elsewhere. As each entry is entirely unique, it's trivially easy to determine the author of this email really does have access to my Kerv account. It quickly became clear that this wasn't a breach in the typical sense... this "anonymous" person had inside information which wouldn't otherwise be available. In an act of either lunacy or clarity, he subsequently forwarded admin credentials to me from a Tor address; obviously unaware of my work deanonymizing Tor users. Not a smart move!

After logging in to my Kerv account, I was greeted with the usual user interface. This time however, I clearly had access to features which were only intended for Kerv employees. After a brief investigation, it became obvious I had full admin access to the site, shop & customer database.

Time to contact Kerv!

I initially tried the Kerv "lost & stolen" number from the site, but there was nobody immediately available for comment. Cue Twitter...

Hi @KervLife
I need to speak with your security team urgently. Please advise.
cc @FD_Phil

— Paul Moore (@Paul_Reviews) June 21, 2017

After a matter of minutes, Mr Phil Campbell (Director @ Kerv Wearables) emailed to request further information. After a lengthy telephone conversation, I advised Phil to immediately take the site offline until a review could be performed. Almost immediately, my access was revoked and at 2:15PM, the site was taken offline completely.

In the hours which followed, Phil and his team worked to identify the root cause and restore service to their customers.

More information to follow...

FAQ

Q) What can I do to protect myself?
A) Change your passwords and memorable information, immediately. Use a password manager to generate them both. Register with Noddle for free credit alerts/reports.

Q) How did Kerv handle the disclosure?
A) Phil/Kerv's response is a perfect example of how companies should handle data/security breaches.

Q) Do you have any other concerns, should I still use my Kerv?
A) I haven't spent much time with Kerv, having only received it yesterday and it being offline ever since. However, I have a number of concerns which I've raised with Phil. It wouldn't be appropriate to list them here, however I've every confidence that Kerv will resolve any outstanding issues. Nonetheless, I see no reason to abandon Kerv. Insider threats affect everyone; Kerv have taken (what I'd consider to be) reasonable & appropriate steps to mitigate the risks involved and have been open & honest in their responses.

Q) What information did you have access to?
A) I was added to the "customer services admin" group, allowing access to virtually every piece of customer data, excluding financial info.

Q) Do you have any further comments?
A) If & when I do, I'll update the article. If you're a news/media outlet looking for comment, please use the comments form below.

After months of tweets, emails & articles from eminent figures like Troy Hunt & the NCSC, it's about time I weighed in on the debate surrounding sites which disable a user's ability to paste passwords.

The general consensus amongst many experts, including those mentioned above, is that disabling paste on password fields reduces security; the NCSC went one step further, calling it "completely pointless" and "damaging".

So without further ado, allow me to explain why I believe disabling paste can actually increase security.

Premise

Disabling paste facilitates barrier-less 2FA.

Confused? OK, let me explain...

Traditional e-authentication systems monitor what you type (your password, for example). This, by definition, provides 1FA or single-factor authentication; you've demonstrated to the site (or verifier, for those of a NISTy disposition) that you "know" the password.

As we know, passwords can be and are frequently stolen, guessed, intercepted, cracked or bypassed... thus requiring a drive towards 2FA or multi-factor authentication.

For many years, companies have focused on introducing a "possession" factor, allowing you to present something you have (along with something you know) to further prove you are who you're purporting to be. That's great, in theory... but the adoption rate of this type of 2FA is pretty abysmal; with some firms (Google et al) seeing figures of < 5%.

Other firms have opted to use a little-known technique called behavioural biometrics/keystroke dynamics. These systems monitor how you type; the periodicity of your keystrokes, how long you dwell between each key, how often you make mistakes, how long each key is pressed and so on. These metrics can be used, with astonishing & near 100% accuracy, to determine who's typing. This is known as an inherence factor. Here's a more detailed explanation of behavioural profiling.

You could, in theory, give someone your password and they'll be unable to login... simply because their typing pattern differs enormously from your own. Think of it as a signature; something unique to you.

Just how reliable is it?

Back in 2015, myself & Per Thorsheim (@thorsheim) presented our research into behavioural biometrics (and how to defeat it) at Cambridge University.

During this research, we demonstrated the ability to shatter a user's anonymity, even when using proxy servers & Tor.

Just let that sink in for a moment...

Even when a user is actively trying to hide their identity using sophisticated & layered defences, the site is able to identify who they are by how they type. No passwords, no perma-cookies... just typing into a webpage.

Many financial institutions, including 2 UK banks actively use this technology in the fight against fraud. Also, HSBC recently announced the introduction of behavioural biometrics via telephone banking; using just your voice to identify you.

How does disabling paste break behavioural biometrics?

When you paste data into a form, the value reaches the DOM almost immediately (a caveat being the use of scripts which monitor for bubble events and delay/block them).

As you haven't typed anything, the script is unable to verify it's really you... leaving you with just single-factor authentication again. Depending on how the site is designed, it may prevent you from logging in, or increase a fraud indicator which prevents access to certain functions (transferring funds etc)

Myths

It's true, there are dozens of increasingly-comical reasons why some developers believe disabling paste increases security.

We'll lose our security certificate if we allow paste

Nonsense.

We'll be vulnerable to brute-force attacks

True, but attacks are rarely (if ever) carried out this way.

Bizarre eh! But equally bizarre, are the myths which circulate as to why you should be allowed to paste passwords.

It breaks password managers!

Not one for going with the status quo, I decided to test this widely agreed-upon theory.

Disabling paste doesn't break password managers...

1Password, LastPass, Roboform & Dashlane all work perfectly with paste disabled.

How's that possible if paste is disabled?

They don't use paste, at all.

If you're using a password manager which generates & populates password fields automatically, it won't be using the "paste" event to achieve the desired result, thus disabling it has no effect whatsoever. I admit, testing 4 password managers is hardly comprehensive... but they all face the same constraints (set by the browser) in terms of how they interact with DOM elements and nearly all adopt a similar, tried & tested method of populating the field.

Now it's true, some password managers don't auto-populate fields and have little/no integration with your browser; KeePass is a prime example. In that scenario, you would be unable to copy/paste from KeePass to the password field. You still haven't "broken" the password manager or measurably decreased security... only the user-experience (UX) is affected.

"That's a good enough reason to allow paste then, surely?"

Not really, no.

If we make conscious design decisions affecting only people who use password managers, we're already talking a tiny fraction of your potential user-base. To further limit those decisions to people who only use comparably-antiquated and potentially more risky solutions like KeePass, you're probably in the realms of < 0.1%.

Summary

Barrier-less 2FA is exactly that... a zero-barrier, frictionless method of increasing security for all your customers, including those who use password managers.

There are many "completely pointless" reasons to disable paste, but that doesn't mean disabling paste is completely pointless, nor damaging.

That's it folks.

Use a password manager.

Ever since publishing a "two factor authentication vs two step verification" article in 2014, I've been waiting for an opportunity to irrefutably demonstrate the difference.

Note:
This article is very much a "work in progress" as until both exploits are patched, I can't provide any technical information.

A quick recap...

If you haven't yet read the above article, let's quickly recap on the differences between two-factor authentication & two-step verification.

A "factor" falls into one of the following categories.

1. Knowledge
2. Possession
3. Inherence

The lines between them however, become blurry when companies refer to SMS one-time passwords (OTPs) or calls as "two-factor" authentication.

Although you technically "possess" the phone, the OTP isn't generated by, nor dependent on the phone itself... but rather the code sent to it via the mobile network. I've long argued that despite NIST's statement to the contrary, SMS OTPs do not constitute 2FA.

So, let's dive right in.

Who are FreedomPop?

FreedomPop are the UK's first completely free mobile network provider; launching in September 2015.

Unsurprisingly, FreedomPop has grown rapidly to in excess of a million users, many of whom opt for the free 200 minutes, 200 texts & 200MB data plan.

FreedomPop's security... or lack thereof

At this point, I'd usually explain the exploit in detail but, mindful of not wanting to exacerbate the problem, stop short of providing a step-by-step guide. On this occasion however, the risk is such that any further information is likely to immediately place 1+ million users at considerable risk.

It is currently possible to remotely hijack any FreedomPop account, allowing both calls & messages to be made/intercepted by an attacker. No usernames, no passwords and no SIM swapping... just unfettered access to a user's communications.

Monetizing the exploit...

OK. We now have access to every call & SMS message to a user's device... how can we convert that into actual money?

Well, the user's contact list is probably a good place to start; a few quick texts to friends & family is likely to yield a few quid. Keep in mind, the messages are coming from the victim's own number.

That's all well & good, but what if we're not interested in a few hundred quid?

Hitting the bank

At first glance, this seems like a particularly crazy idea.

To successfully gain access to a Halifax account, an attacker would need the username, password & security pass phrase. Even armed with all this, they're unable to add a new payee without triggering further anti-fraud checks... in the form of an automated call to your registered mobile number.

The UK banking sector isn't particularly hot on security either, but that's still a tall order without tripping sophisticated anti-fraud systems.

Can we bypass the username, password & security pass phrase entirely?

As of the date of this article, it's possible to do just that.

Halifax don't offer a "Premier +" account, but would you have spotted the fake/malicious section of the page?

No security warnings, no outward signs at all that we're looking at a page controlled entirely by an attacker.

A serious (yet remarkably simple) vulnerability in the Halifax site allows an attacker to execute arbitrary & external scripts. This gives the attacker complete control over the victim's environment; changing links, buttons, text and crucially... perform actions as if they're the genuine user.

Thankfully, Halifax/Lloyds Banking Group have since verified this exploit, even bringing in external consultants to re-test & confirm their results.

Whilst we agree there's an issue, Halifax/Lloyds have (unsurprisingly) played down the risk, suggesting that other safeguards prevent unauthorised access to a user's bank account. One of those safeguards, of course, is the requirement to verify a new payee by contacting the victim's mobile number.

I've demonstrated one method of payload delivery and although it works, it's by no means quick or easily scaled. There's at least one other route too, but proving this theory means breaching the Computer Misuse Act and, given their propensity for threatening legal action, it's a step too far for an exploit I've proven by other means.

Let's not forget though, even a single, well-executed attack can yield a sizeable return. Remember Vivian Gabb?

Killing two birds with one stone.

Let's recap...

We control the user's mobile number.
We control the user's banking environment.

But, we still need to deliver & execute the payload in a manner which doesn't alert the user.

How?!

The fix for this exploit is due in 3/4 weeks, so until then, I obviously can't give any further details.

However, their failure to adopt even the most basic of safeguards means it's possible to fire both exploits simultaneously and directly on Halifax's own site. To make matters worse, the exploit takes place on the user's device; effectively shielding the attacker from the vast majority of anti-fraud checks.

Wider issues...

Let's be clear. An attacker is unlikely to hit your bank account first... the risk is just too high.

There are other low/no risk targets which could yield an equally high return. Your email address, as an example, provides access to virtually every account you own.

If you're sensible, you've enabled 2FA or 2SV on your email account; effectively preventing unauthorized access to anyone armed with just your password. It's also sensible to add a fallback number, if you ever lose access to your second factor... or is it?

Every fallback/revocation option provides a wider threat surface, each attracting their own set of security concerns. An immensely strong password is rendered useless by anyone with access to my email account. A Yubikey/Google Authenticator is rendered useless by the ability to bypass it via SMS. Instead, the crypto seeds which form the basis of my OTPs are backed up locally; encrypted and isolated from the outside world.

Thankfully, I've never lost my keys... but it'll happen one day. If you must use backups/fallback options, just bear in mind they're another door into your digital life.

If the attacker now has knowledge of your OTP, he has access to your supposedly "2FA" protected accounts. Keep in mind, 2 knowledge factors does not constitute 2FA either... but 2SV or two-step verification.

The attacker hasn't stolen something you "possess", thus it couldn't possibly be 2FA. It's undoubtedly stronger than just a password, but it's by no means comparable to true 2FA.

Summary

These exploits really are the lowest of the low-hanging fruit; detected by even the most rudimentary of security scans... but overlooking even the simplest of exploits can lead to much bigger problems.

In isolation, the issues at the Halifax do not appear to be particularly serious... though I'd question how such a basic flaw went unnoticed. When combined with other, equally simple exploits elsewhere, an attacker has a much wider window of opportunity to gain access to your communications & bank account.

Timeline

Halifax/Lloyds Banking Group responded immediately, escalating the issue to the appropriate team for review. They later called to confirm the exploit, the steps they're taking to resolve it and their assessment of the risk. As our assessments differ, a partial publication seems appropriate.

FreedomPop however, are yet to reply.

24/03/16 - Tweeted FreedomPop. They replied asking for details to be emailed to feedback@freedompop.com - Email sent.
24/04/16 - Identical email to feedback@freedompop.com requesting a response.
25/04/16 - Email to CTO. No response.
27/04/16 - DM to FreedomPop asking for an update.
28/04/16 - Response to DM. "We've relayed your message, have a wonderful day"
01/05/16 - Publication. Further information to follow if they fail to respond.

A few weeks ago, I was asked to observe an installation of several wireless access points & VoIP phones, with a view to making recommendations on how best to improve security while maintaining ease of deployment.

It didn't take long for several trends to appear; chief amongst which was the use of

We'll just use defaults, for now. That password will do, for now.

Of course, as soon as the device burst into life, it's on to the next one. At which point, "now" becomes a distant memory, along with any thoughts of hardening the device for use in a commercial setting.

This was not a fly-by-night company either, nor do they install cheap & cheerful hardware; we're fitting enterprise-grade Cisco, Snom & Ubiquiti UniFi equipment. With a tight schedule & reputable brand names, I completely understand why many installers trust the default configurations so vehemently.

A default config is rarely a secure config.

A default configuration is only intended to restore a device to a "default" state, such that a competent installer can configure it to meet the client's needs.

Note: This is neither aimed at nor unique to Snom devices. I'm aware of similar exploits against current Cisco devices too.

In the following example, I've reset a Snom 320 VoIP phone (running 8.7.5.13 firmware) back to factory "default" settings.

Even before we begin, there's a serious problem... there's no authentication whatsoever!

To their credit, some manufacturers provide a default set of credentials... even if they're usually "admin/admin", thus equally insecure.

Snom however, opted to place a tiny "HTTP password not set" warning at the top of the configuration screen. That'd be fine if it forced you to set a password during the setup process, but it doesn't.

To make matters worse, it's only too happy to accept a single character/number password too.

They're sat behind a strong firewall, so what's the big deal?

A reasonable argument, you might think. So, let's put it to the test.

Hijacking the Snom 320

Step 1: Visit a site which contains the exploit payload.

That's it.

Simply by opening a malicious site (or a genuine site containing the malicious payload), the attacker has complete control over our VoIP phone.

To demonstrate this vulnerability, I enlisted the help of two colleagues... Per Thorsheim & Scott Helme. Per will play the part of our attacker, embedding the exploit on a site which he controls. Meanwhile, I'm reading Per's site while having a private conversation with Scott, via Skype.

Unbeknownst to me, Per has forced my VoIP phone to call his premium rate number and disabled the speaker, so unless I'm looking at the phone, I wouldn't know it's dialling.

Note: We've left the activity LED on during this demo, as it's difficult to read the screen. When the light illuminates, the phone is dialling out.

What can the attacker do?

Virtually anything.

Make calls, receive calls, transfer calls (even before it rings), play recordings, upload new firmware and crucially... use the device for covert surveillance.

Our self-defeating approach...

If we look beyond the IP telephony sector to the industry as a whole, many companies ship devices which have no "default" security... or permit the use of weak credentials which provide nothing more than a false sense of security.

It has to stop.

Vendors - If you must supply devices with "default" credentials, disable all other functionality until a suitably-secure password is set to replace it.

Summary

The term "covert surveillance" is usually only associated with nation states, certain 3-letter agencies and those closed-minded individuals pushing the Investigatory Powers Bill (IPBill / Snoopers Charter).

In this demonstration, the attacker has not only compromised your phone & privacy with just a browser, but you've paid him for the privilege!

If you install, use or just find yourself sat next to one of these devices, just remember... it's basically a PC, with all the security vulnerabilities associated with them. Don't assume it's safe because it's running as the manufacturer intended; seek professional advice.

1. Use strong passwords, derived from a password manager.
2. VLAN / network segregate your phones, if possible.
3. Restrict access to APIs, even if they're only visible internally.
4. Check & upgrade your firmware regularly, ensuring it doesn't revert to "defaults" afterwards.

Just today, Professor Alan Woodward of Surrey University published an article entitled "Are you the only one using your VOIP phone?" which discusses the various attack vectors & implications associated with VoIP devices. If you haven't yet subscribed to Alan's RSS feed, I'd strongly suggest doing so.

Thanks to Per Thorsheim & Scott Helme for their help with this demonstration.

That's it folks... for now.

Back in March 2014, I contacted ASDA to report several security vulnerabilities and despite a fix promised "in the next few weeks", little appears to have changed.

@Stuho1mez All of our sites are secure, I would advise using Chrome. Thanks, Beth

— Asda Service Team (@AsdaServiceTeam) January 14, 2016

After 677 days and several tweets along a similar vein, my patience has finally run out.

What's the problem?

Two of the simplest and most prevalent exploits allow an attacker to quickly & effectively collect personal information & full payment details.

Rather than outline the finer points of CSRF (Cross Site Request Forgery) & XSS (Cross Site Scripting) for the umpteenth time, it's probably easier to show you.

Have I been affected?

As of Q2 2014, ASDA processed upwards of 200,000 online orders each week. Given the length of time this has been exploitable, that equates to over 19 million transactions.

I'm not aware of any evidence suggesting these exploits are being used in the wild, but just a few months after my initial report, this tweet appeared.

@asda some one hacked my acc tomake fraud on line purchases the bank caught it tank god but warn ur customers and i need a number to ring

— cathy creighton (@Ruby6918) June 10, 2014

Unfortunately, it's difficult to know if your details have been stolen unless the attacker uses the information very shortly after the breach occurs, such that it's reasonable to assume a link between the two. However, ASDA may be able to shed further light on anyone affected by this, or any other exploit.

How can I protect myself?

The safest way is simply to shop elsewhere.

ASDA/Walmart have had ample opportunity to fix these issues and have failed to do so. If you must continue shopping with ASDA, open a "private" / "incognito" window and do not open any other tabs/windows until you've logged out.

Other issues...

Well, they don't enforce SSL/TLS during login and the entire session is maintained over an insecure protocol.

Another user spotted this too... and tweeted ASDA.

Hey @ASDA why do you serve your login form over plain (unencrypted) HTTP? pic.twitter.com/1LsuP8YuLF

— Chris (@cmrowles) February 9, 2015

Did they acknowledge the issue & deploy a fix? Not quite.

@cmrowles Morning! We've had it confirmed that the page is secure 😊 Thanks, Beth

— Asda Service Team (@AsdaServiceTeam) February 10, 2015

--

When Sarah tried to apply for a job, she was greeted with this error.

@asda get a new security certificate for your jobs site, risk of having personal data stolen. #asda #websecurity pic.twitter.com/mVpueZs5Qy

— Sarah Rose (@NyowcatS) May 26, 2015

Did they spot their mistake, generate and deploy a new certificate?

@NyowcatS Hi Sarah, I can confirm that all our Asda web pages are secure, Thanks Steph

— Asda Service Team (@AsdaServiceTeam) May 26, 2015

No. They go on to recommend Sarah delete her cookies!

Scott tried to apply for a job too.

@asda I'm trying to apply for a job on your site. But anytime I try to access the application part. It tells me the websites in danger

— scott paterson (@whosinthebox94) June 15, 2015

Surely now they'll fix it, right?

@whosinthebox94 Hi Scott, I can confirm to you that the http://t.co/I7R0i6VbzC website is a fully secure site, Thanks Steph

— Asda Service Team (@AsdaServiceTeam) June 15, 2015

Nope. Now, it's fully secure.

Summary

Despite a speedy response to my first email and a privacy policy which suggests otherwise, ASDA do not appear to be overly concerned about the security of their customers.

I invited ASDA to comment on the situation; requesting more detailed information on who customers should contact if they believe they're affected by any security flaws. I received an "out of office" from their "data protection" email address and haven't heard anything since.

Before we begin, let me preface this by saying... I actually quite like Steve Gibson. For all his faults, he often raises very salient points on a variety of topics, typically surrounding security products & services.

During the latest "Security Now / TWiT" episode on 20/10/2015, Steve & Leo Laporte featured a piece of 1Password news regarding Dale Myer's "1Password leaks your data" article.

It's a little over 10 minutes long...

It's no secret that Steve's a huge fan of LastPass and for that, I can't fault him. LastPass is a remarkable product; one which I've recommended to many people in the past. I on the other hand, prefer 1Password.

However, my personal preferences do not preclude me from criticising 1Password when it's necessary. Avid followers may have already spotted that Dale's news isn't new at all... it's something I mentioned during an article 2.5 years ago (and I wasn't the first!) (https://paul.reviews/1password-forgot-your-password-youre-doing-it-wrong/) and despite this, I've remained a supporter of 1Password and until recently, still relied heavily upon the agilekeychain format.

Before we dive in to the specifics, first... a minor correction. Dale Myers is not (nor does he claim to be) a security engineer, but a software engineer. I say this not to diminish the validity of his article at all, but to clarify that his viewpoint is that of a developer, not someone who understands the logistics of solid cryptography.

What's the problem with Agilekeychain?

The "location" (the actual URL) and "title" (the name of the site) fields (so-called metadata) are stored in plain text, such that anyone in possession of the keychain can identify any sites you use.

Although it's entertaining to listen to Steve wax lyrical about how this "represents a fundamental, crucial failure of judgement" while Leo sneers in the background, there is sound reasoning behind the decision.

The main focus of an application of this nature is not security, nor privacy... but usability. A naive & amateurish approach would be to encrypt everything, regardless of the consequences; an unfortunate result of which is a poor user experience which ultimately leads to the user reverting back to old ways.

Why isn't the metadata encrypted with your master password?

In reality, none of the data (including your username/passwords) is encrypted with your master password.

Your master password is used to derive a cryptographic key, which in turn is used to encrypt something else.

OK, why isn't the metadata encrypted with your master "key"?

It may come as a surprise, but this key isn't used to directly encrypt your data either. Instead, a unique, entry-specific key is generated by 1Password.

This unique key is encrypted with your master key, which itself is derived from your master password.

Consider the environment...

Now we understand a little about how 1Password is put together, we can begin to understand why "performance reasons" is not an argument in response to a bug, but a valid & reasonable design decision taken by experts who fundamentally understand the problem.

When Agilekeychain launched in 2008, Android was still in its infancy and Apple users were rocking the iPhone 3G. In terms of technology at that time, an HTC G1 had just a 528Mhz CPU and a measly 192MB RAM.

If 1Password was to be truly cross-platform compatible, it needed to provide a reasonable defense against attacks from modern PCs but accommodate the performance constraints of a mobile phone. As any developer will tell you, it's incredibly difficult to strike that balance and unfortunately, sacrifices have to be made.

Think for a moment about what 1Password needs to do in order to display a list of entries.

First, it must stretch your master password through the use of PBKDF2 (itself a considerable demand for a mobile device). With the master key, it must iterate through every single site (of which there could be hundreds), decrypt the entry-specific key and then decrypt the data.

In reality, it just wouldn't work on a mobile device at that time. It'd either hang completely, or slow the experience to the point where the user reverts back to "password1234" and writes 1Password off.

Remember, it's usable security we're after...

Could it be made to work?

Sure... dropping multiple derived keys would help with performance, but to the detriment of security. It's safer to assess the risks involved in storing metadata in plain text, than undermine the entire foundation in an effort to increase performance.

Take it slow...

When it comes to deriving keys from passwords, speed (or performance) is our enemy. If your environment can generated keys rapidly, such that plain-text storage wouldn't need to be considered, so can an attacker.

But not too slow...

It needs to be slow enough to trouble a would-be attacker, but not so slow as to interfere with the user experience. Again, this is a balancing act which every developer struggles with at some point.

The problem? The lack of consistency across platforms! A PBKDF2 library on iOS will respond differently to an Android equivalent; something which must also be taken into consideration at the design stage. If you expect a record to decrypt in 100 milliseconds, but it actually takes 200 milliseconds... you've doubled the time on one particular platform.

Of course, they could write their own library... but they're sensible enough not to go down that route too.

What's 100 milliseconds? Big deal!

If you have a couple of entries, sure... it seems like a nominal difference. If, like me, you have 200+ entries, instead of opening in 2 seconds, it takes a yawn-inducing 4 seconds. Would you be happy with a 4 second delay each time you searched/listed all entries?

What happens if the device is busy, or near its resource limit? Will it crash, fail gracefully, dump decrypted data to storage or take 8 seconds instead?

These are all considerations which require plenty of forethought.

Who was the information exposed to?

Anyone in possession of the keychain, or perhaps more accurately... nobody in the overwhelming majority of cases.

Agilebits have never recommended uploading your agilekeychain to a publicly-accessible location. In truth, they actively dissuade users from doing so... but I completely understand why someone would.

If your keychain is stored on your PC/mobile device, it's incredibly unlikely that anyone has seen it. Likewise with Dropbox; unless you've specifically shared the keychain with others or made it public, it's highly unlikely that your privacy or data has been leaked.

What's crucial here, is that it was not exposed to Agilebits. They don't want it, need it nor have the infrastructure necessary to store it.

Couldn't Agilebits move to OPVault sooner?

If this article has been pro-1Password thus far, it's about to take a turn for the worse.

The drawbacks of agilekeychain and added benefits of OPVault have not been communicated well at all; even a minimal risk is worth mentioning to allow users to make an informed decision. Although I discovered these issues during my investigation in 2013, I still opted for agilekeychain as the associated risks didn't affect me.

Each use case is different, so please don't consider that a recommendation either!

The inevitable comparison with LastPass

It was only a matter of time before Steve made a comparison with LastPass, so here it is.

Unfortunately, it's comments like these which place Steve in my "entertainment" bookmarks folder, not security.

You see, LastPass doesn't encrypt metadata either! It's stored, by LastPass, in plain text.

At first glance, the URL looks like an encrypted string. In fact, it's encoded in Hex!

Again, this isn't new information... it was first mentioned by a fellow researcher in 2012, coincidentally around the same time Agilebits moved away from such techniques.

Why do LastPass store metadata in plain text?

"to provide favicon support", LastPass Support.

You know, these things...

Of course, they couldn't possibly leak anything of importance could they?!

Frankly, I don't buy that. You can't build an application as good as LastPass without knowing there are other, more efficient ways to grab a favicon without leaking metadata and storing it on your own servers.

Oh dear, where do I start with that?

Firstly, his risk assessment is way, way off. If the suggestion is "I'll never give them my data, neither should you", I'm afraid Steve/TWiT no longer belongs in the entertainment/comedy folder either.

I suppose it'd be prudent to reiterate that it's impossible to give Agilebits your data. It's not cloud-based and has no requirement to be so.

I'll also take a moment to chuckle, Leo-style, at the fact he's unwittingly leaking his own metadata to LastPass during each and every login. The file "loglogin.php" should be all the indication necessary to question why (or more importantly, how) a company with no personal, private data can possibly create meaningful logs/reports unless their applications share such information.

Should Steve close his LastPass account?

Well, yes and no.

There are two options...

1. Admit that with hindsight, it's was a ridiculous overreaction to write off an application because of a measured, reasoned set of decisions based on technology constraints from 7 years ago
   or
2. Stand by his comments, admit LastPass leaks substantially more metadata, shares his activities in plain text with the server and close his account immediately.

I asked Steve to comment, but I'm yet to receive a reply.

Thoughts @SGgrc, given your stance on #1Password's "leak" ? https://t.co/qVr41oBikn URLs are sent to #LastPass in plain hex btw. #privacy

— Paul Moore (@Paul_Reviews) October 22, 2015

Summary

As I've said countless times before, 1Password is designed & written by experts who understand the subtle nuances of deploying a scalable, secure application; to whom the term "security" means more than wrapping AES around everything in sight.

Trust is everything.

We're all familiar with the 3 basic categories of authentication.

1. Knowledge factors (passwords, PINs)
2. Possession factors (a software/hardware token - Yubikey/Google Authenticator/SecureID)
3. Inherence factors (fingerprint, heartbeat, iris/retina scanning)

While the vast majority of sites use knowledge factors, a growing number are turning to multi-factor solutions in an effort to bolster security; to the detriment of the user experience.

Cue continuous authentication / behavioral biometrics... the process of identifying a user based on the subtle nuances in their voice, typing patterns, facial features and location.

How does it work?

As opposed to traditional authentication which is only interested in what you type, behavioral biometric systems collect & profile how you type too. By actively monitoring how you type, the system is able to build a profile on you.

In order to achieve this, the system monitors how long each key is depressed (dwell time), how long between each key press (gap time), how long to type a known string and hundreds of other metrics.

Source: behaviosec.com

With enough supporting data, it's entirely possible to identify you based purely on how you type.

Think about that for a moment.

How accurate is it?

Back in 2011, professor Christophe Rosenberger at ENSICAEN announced it was possible to determine the user's gender after just a few keystrokes.

Over the last 4 years, many companies have researched & invested heavily in leveraging this technology.

Meet BehavioSec, a swedish company which shot to fame after recent publications on BBC News, the Wall Street Journal, CNBC, Wired, Forbes to name a few.

After a brief training period, their technology is able to identify a user with astonishing accuracy.

Here's the demo login page.

Looks remarkably similar to every other login page, doesn't it?

After entering your username & password, you're asked to simulate a bank transfer. After just 44 characters, look at the result.

A session score of 99% with a confidence rating of 80%! Remember, we've typed 44 characters so far.

Balancing security with privacy

In terms of security, this is a huge leap forwards... but does it tip the security/privacy scale too far?

You can forget Tor, a VPN and your favorite proxy site... if you have javascript enabled and you've been profiled, there's a very good chance they'll identify you.

The problem is... do you know when you're being profiled?

It's been rumored that UK banks are actively trialing this technology in an effort to detect & minimize the risk of fraud. How many other sites use it? Would they tell you if they were?

Shared secrets

Although we all love to hate passwords, they're shared secrets which can be changed with just a few clicks.

If your biometric behavioral profile is shared/stolen, the consequences are far-reaching and considerably more difficult to mitigate. You can't change the way you type and even if you did, they'll simply profile you again until the confidence level reaches acceptable limits.

How do I protect my privacy?

On Wednesday, 22nd July 2015, Per Thorsheim (Founder of PasswordsCon, CISA, CISM, CISSP ISSAP) Skype'd me with an interesting challenge.

Defeat the underlying technology and protect the user's privacy.

Challenge accepted.

Over the next few days, I researched the underlying technology and explored ways to nullify such profiling. You can read Per's analysis of this technology here.

Although many implementations claim to use hundreds of metrics, it became clear that only a few were weighted heavily enough to really matter.

1. Dwell time - How long each key is depressed.
2. Gap time - How long between each key press.

If we can skew these statistics enough, it'd be almost impossible to profile and/or identify a user.

Meet KeyboardPrivacy, a proof-of-concept Google Chrome extension which interferes with the periodicity of everything you enter into a website.

Once installed, you can continue to use the web exactly as you do now. When you enter anything on your keyboard, KeyboardPrivacy will artificially alter the rate at which your entry reaches the document object model (DOM).

As you can see, we have a 50 millisecond dwell & gap time (the default configuration) here. It's enabled everywhere by default, but you can disable it on a per-site basis if you wish.

Let's see what happens when we try to login now.

That's better!

Our session score has plummeted to just 0.07%! Crucially, they're 78% confident in the assumption that the person in front of the keyboard is not me, despite having my username & password.

What about MousePrivacy?

Most (if not all) behavioral profiling systems check your mouse movements too. However in my experience, mouse movements do not provide sufficient metadata to accurately identify a user.

As such, the plugin makes no attempt to mask/obfuscate your mouse movements.

Doesn't that reduce security?

Absolutely, but that's not necessarily a bad thing.

As I mentioned earlier, it's more important to strike a good balance between security & privacy; it's rarely possible to increase one without measurably degrading the other (password managers being an exception). If you're happy to leak this information to every site, or if you're forced to do so by a financial institution, you can disable the plugin on a per-site basis.

Even if your behavioral profile is leaked to a 3rd-party, it's of no use unless you happen to disable it on their site too.

The single biggest problem with passwords is not length or strength, but re-use. Your behavioral biometrics (knowingly or not) are essentially secrets which you unwittingly share with every site.

Granularity is key

Although the technology is often described as "continuous authentication", it rarely is. With 400+ unique metrics for every field, the amount of metadata would be astronomical.

However, that's not to say it's not possible.

If you're a large corporation or a certain 3-letter government agency, behavioral biometric data is priceless. If the site happens to profile every single word (ignoring the fact they'll be swamped with data), imagine this scenario...

The user types and the site profiles the word "behavioral". OK, no big deal... but look deeper.

What happens when the user types "behave" or "oral"? We already have partial data for those terms, even though they haven't type the word exactly. Although the system works on loose tolerances, it's granular and smart enough to make an educated guess.

Delivering the proof of concept...

Since laying down the gauntlet, I've been in daily contact with Per Thorsheim to test each version of KeyboardPrivacy.

The current version appears to be working quite nicely; even protecting a profile created through Tor.

Defeating the technology, not the implementation

As you've seen, Per and I have conducted our tests against BehavioSec... but defeating individual implementations is not the goal here.

Let's try KeyTrac; a similar product intended to add biometric profiling to current knowledge-based authentication.

First, we'll try with the plugin disabled (note the red dot on the plugin icon)

82% is a reasonable score to allow a session to continue. Let's enable the plugin and try again...

Ah, the sweet smell of success.

Summary

This was an interesting challenge and ultimately, it wasn't as difficult as I expected. If you strip away the fundamentals required to make a chrome extension, the code is just 13 lines long and has proven to be quite robust so far.

The Chrome extension is now available here. Sit tight for a Firefox version too.

"We have detect some unauthorized active on your account. Please update your detail as soon as possible"

We've all had them; the notorious and grammatically inept phishing emails designed to strip us of our hard-earned money.

The vast majority are destined for immediate deletion, but a growing number of sophisticated attacks are starting to emerge. Nobody understands this better than Vivian Gabb, a tennis coach from London who recently lost nearly £50,000 to fraudsters.

Before you cast aspersions, this was not your average phishing attack. Far from it.

Vivian's email account was breached by the fraudster. Rather than spam her contact list with a desperate plea for financial help, the fraudster opted to sit and wait. Unfortunately for Vivian, her conversations with her solicitor were being monitored. When the time came to transfer a deposit to purchase a house, the fraudster took a high-risk approach and assumed the identity of the solicitor.

Apart from the "sit & wait" strategy, this phishing attack stands out for the sheer level of sophistication demonstrated by the fraudster. Rather than sending an email which Vivian would likely spot, the fraudster first registered a new domain name which closely resembled her solicitor's and even opened a new business bank account!

So when the carefully-crafted email arrived, Vivian didn't give it a second thought. They addressed her by name, referred to their correspondence on the previous day and even mirrored the tone used by her solicitor. A quick bank transfer later... and Vivian lost her life savings.

To make matters worse, neither her bank (Halifax) nor the receiving bank (TSB) were able to recover any money until it was too late.

Should the bank cover her losses?

Morally, I believe they should. Technically, perhaps not.

You see, the bank has to prove that Vivian acted negligently. Can you, hand on heart, say you'd never fall for this well-executed scam? In reality, £50,000 is peanuts and discretion really should apply.

BBC Coverage

I first became aware of Vivian's plight via a BBC article. Unfortunately, the advice from Tony Neate @ GetSafeOnline will only exacerbate the problem... so I'll say this as succinctly as I can.

Do NOT change passwords regularly.

A password, regardless of length & strength, has a finite value; it’s only useful until the user changes it. Of infinite value however, is knowing how a user chooses a password. Each time you choose a password (which is subsequently leaked/cracked etc), you're inadvertently leaking information about how you choose a password. Does it start with an uppercase letter and end in a 4 digit date? Does it contain special characters but only at the end of the password? Does it resemble another password associated with you and if so, are there any common denominators (numbers, dates, words, layout etc)?

With this information, an attacker doesn’t need to know your current password… they can predict (with great accuracy) what your next password will be. I’m yet to meet anyone who enjoys choosing another password, so choices are made purely from a usability point of view, not security.

Using Tony’s flawed logic, a site which forces a password change every 3 months is much safer. Likewise, forcing a password change every day would be even stronger. Sadly, that’s just not true. Instead of choosing an entirely new, unique, long & strong password… the user is far more likely to add a “1” to the end of the password (MyPasswordForThisSite20151). We’ve all done it, but it’s a problem made significantly worse when you’re forced to make frequent and unnecessary changes.

Ultimately, passwords should only be changed when there’s suspicion or proof that it’s no longer a secret (assuming it’s reasonably strong in the first place).

The only caveat to that being the use of a password manager. Many password managers choose & subsequently store random passwords for the user, removing the burden of choosing & remembering something comparably weaker. In this instance, repeated password changes (necessary or not) would not leak any significant information to an attacker.

Who's responsible?

The more I think about it, the more it doesn't quite add up.

It's almost certainly a targeted attack; someone who knew Vivian was in the process of buying a property. Why? Attackers rarely sit on breached accounts for a significant length of time... as each passing day increases the likelihood of being discovered. I'm struggling to believe a sophisticated attacker just happened upon her account at such a convenient time.

Personally, I'd start by looking closer to home. Friends, family... even the solicitors aren't exempt from suspicion. Although it's highly unlikely Vivian will ever see a penny of her money, it's only right to put those responsible before a court. As far as I can gather, she's approached an "IT expert" with a view to investigating exactly what happened; with quotes of roughly £1000 being mentioned.

In truth, £1000 wouldn't even scrape the surface and would likely be more money down the drain.

You could argue that consistently bad & misleading advice from "experts" is also to blame, to a certain extent.

I've invited GetSafeOnline and the BBC to comment and issue a retraction, but I'm yet to hear from either party. I will update the article if necessary.

Just 22hrs after charging my Galaxy Gear, it's already minutes away from switching off and needing a recharge.

I've read dozens of guides on how to extract as much life as possible from the tiny 312mAh battery, but few go into sufficient detail to help make informed decisions.

So, here's a list (in order of effectiveness, highest to lowest) of steps you can take to increase your battery life.

1) Upgrade to Tizen

Google's Android is great, but it was never designed for use on a smart watch.

If you haven't already done so, install Samsung Kies and connect your Gear. If there's an update available in your region, it'll prompt you to upgrade. Make sure your battery is 50% or greater before starting the upgrade.

2) Perform a factory reset

Even if you've just upgraded to Tizen, go through the recovery/reset process. This will completely wipe your device.

With the Gear switched on, press and hold the power button until it says "rebooting". Press the power button 5 times. You'll arrive at a menu with 3 options which you can scroll through by pressing the power button. Go to "recovery" and press & hold the power button for 3 seconds to select it. Follow the instructions and wait for it to reset.

3) Disable "Motion Wake"

With "Motion Wake" enabled, the Gear uses the gyroscope and accelerometer to detect and calculate your movements. Although only specific movements will cause the Gear to wake up, you may not realise that it's constantly "listening" to your movements which ultimately affects your battery life. I leave it enabled because I'm happy to lose some battery life for the benefit of not pressing the power button each time, but if you really want to optimize your battery life, disable this too.

4) Update Gear Manager and all dependencies

As a companion device, the Gear needs to be paired with a smartphone to work effectively. Each time it sends notifications or indeed any data at all, it devours the battery of both devices. The latest versions are much more efficient.

5) Disable "Auto Unlock"

Auto-unlock works by continually transmitting a signal to paired devices, letting them know that it's within range. Although useful, it's very power-hungry.

6) Use a black wallpaper

The Galaxy Gear uses an AMOLED screen. As opposed to LCD screens, each AMOLED pixel is illuminated individually. When your device needs to show a black pixel, it simply disables that pixel. With a black wallpaper, the vast majority of your screen is switched off. Tests have shown this can increase your battery life by as much as 20%.

7) Reduce your screen timeout time

It goes without saying, but the longer your screen is on, the less time your battery will last. The minimum time in Tizen is 10 seconds, with Android allowing just 7 seconds. If you have "Motion Wake" enabled, keep in mind that each time it wakes (intentionally or otherwise), this timeout value starts again.

8) Reduce your screen brightness & sound volume

If you must use "outdoor mode", use it sparingly. At full brightness, the Gear gobbles battery life. Use the absolute minimum you need to use it without straining your eyes. Also, keep the volume as low as possible.

The Results

With Tizen, a factory reset, motion wake enabled, the latest Gear Manager, auto unlock disabled, a black wallpaper, a 10 second screen timeout, a screen brightness of "3" and roughly 40 notifications per day, I managed just over 3 days of usable life. If you're a particularly heavy user, you should achieve 2 days quite easily.

Update: 2:50PM 03/02/2015

Just minutes after this article went live, SagePay have once again removed the 56bit cipher. It is being actively monitored, so if it creeps back in, I'll update the article again.

As one of the largest payment service providers in the world, SagePay has over 50,000 customers and processes over 4 billion payments each year.

The website is festooned with security claims:

Payment security and fraud prevention are two of our top priorities

Thousands of businesses already entrust us with their security because we keep our customer's data secure

Our services are completely secure
SagePay - http://www.sagepay.co.uk/support/online-shoppers/about-sage-pay

There's even a certificate to prove it:

While investigating another serious security breach at "Office", a shoe retailer in London, I decided to run their PSP through the simplest of tests.

At first glance, it appears the POODLE/SSLv3 exploit is the most dangerous flaw... but that's not necessarily the case here.

A 56bit export cipher?! That's not PCI compliant... it's not even close!

I tweeted SagePay on January 19th 2015 and within hours, I had the (interim) Head of Security on the phone to discuss it.

By the 22nd of January, the 56bit cipher had been removed and SagePay were (notwithstanding POODLE) PCI compliant.

If they've fixed it, what's the problem?

Well, just a few days later... the 56bit cipher returned!

On the 25th, I sent another message to the Head of Security asking why it had returned. Although I can't share the exact reason why, I can say that it was entirely intentional.

I must be honest, I was disgusted to discover their lack of compliance, but the speedy response did help alleviate my concerns. However, the fact they've knowingly reverted back demonstrates that quite apart from being a "top priority", security doesn't appear to be particularly important to them.

It's now February 3rd and it's still not compliant...
https://www.ssllabs.com/ssltest/analyze.html?d=live.sagepay.com

What about POODLE?

Responsible firms patched out POODLE months ago. SagePay are still lagging behind, so I raised the issue again on Twitter DM.

Drum roll...

Summary

As a result of these issues, I'm working to move several companies & local government accounts away from SagePay. If you value the security of your customer payment data, I'd advise you do the same.

Don't forget to +1, retweet and share folks.

You may recall, I recently published an article entitled "How secure is Roboform: The 5 Minute Challenge".

Well, 6 months have passed and although there's been no official public response from Siber Systems, they have made a number of comments to journalists and customers by email/Facebook and support tickets; during which I've been labelled as "misinformed", "unpleasant" and "sarcastic".

There were no bugs in the first place.
Roboform on Facebook

Hmm. They edited the post.

Stick to factual articles.
Roboform on Facebook

In both replies, you'll note a link to the HackerNews article which tried to debunk my claims. Fortunately, The HackerNews pulled the article and replaced it with this; something which Scott Helme pointed out.

Security is our number one priority and we are working to ensure that no vulnerability exists, as it has still yet to be confirmed
Roboform on Facebook

So they couldn't replicate it, assumed it was inaccurate and publicly berated the researcher that reported it! Charmin'!

A week later, Chris Gomez raised the issue again.

Although they still couldn't replicate it, they did at least release a patch.

Since then, it's been radio silence. The "Roboform Everywhere" portal was still insecure, but that clearly wasn't going to change any time soon.

Poking the bear

A couple of days ago, a concerned Roboform user sent this:

Sigh. Let's start over.

RoboForm does not pass Master Password over any network

RoboForm does not transmit any decrypted contents of the user data files (passcards/identities/safenotes) over any network.
Olivia @ Roboform Support

I agree. If you use the Roboform desktop application, the master password & passcard data do not travel across the network. That said, I never claimed they were. The article clearly states "Roboform Everywhere Portal" as opposed to the Roboform desktop application.

These services are using SSL connection (https) for communication between the client (browser) and the server.

When the user submits the Master Password to decrypt a file, the Master Password is submitted to RoboForm Everywhere server, the server performs the decryption, and the decryped data is transmitted back to the client.
Even if the user selects to cache the Master Password, the Master Password still is not stored on server.
Olivia @ Roboform Support

That's somewhat true.

SSL

Yes, they use SSL. Unfortunately, it's SSLv3 and susceptable to the POODLE exploit, which is insecure. They also use RC4, which is considered weak. There's no forward secrecy, HSTS, pinning, elliptic curve crypto or indeed anything considered "military grade", to use their phrase.

You'd have to be insane to willingly send your master password over a "secure" channel such as this... but what if it's not encrypted at all?

@Rambling_Rant Paul, we believe we addressed this with you a while ago. Can you DM me with some details and we'll look into it again pls?

— RoboForm (@roboform) August 15, 2014

For at least a week in August 2014, Roboform's Everywhere Portal sent data to/from their servers over HTTP!

No encryption, no hashing... nothing! Just a few minutes before their reply though, the server miraculously started enforcing SSL (albeit insecure/weak).

Did they own up, admit their mistake and allow users to change their passwords? Nope... they quietly patched it and presumably hoped nobody had noticed.

Sending vs Storing the Master Password

Assuming you've read the first article, you'll note I said

Your master password is sent to Siber Systems
Me - here

I specifically used the word "sent" because it was completely at odds with Vadim's (CEO) statement.

As I've previously shown, it's not only sent to Siber Systems (which they now admit), but there's no hashing involved whatsoever. On both counts, that's a lie.

Their paraphrased rebuttal of "ok, but we don't store it" is pretty weak, not to mention inaccurate.

What's the difference?

Trust.

If you're sending the master password over any network, you have to trust it's being handled with care, every step of the way. We already know the transport layer is horrendous... and that's what we can see; who knows what's going on behind the scenes.

Even with the best of intentions though, it's never as safe as simply not sending it in the first place.

Even if the user selects to cache the Master Password, the Master Password still is not stored on server.
Instead, two strings are derived from it; the first string is stored on the server, the other in a browser cookie.
Olivia @ Roboform Support

To derive two keys from the master password, the server must have the master password to begin with. At the very least, this is stored in server memory until the key derivation process is complete.

Let's assume they discard the key immediately after key derivation. The only way to recover it is to combine the 1st derived key (already on the server) with the 2nd key (stored in the user's browser as a cookie).

As each requests comes in, those keys are once again combined to encrypt/decrypt your passwords.

Why do they claim they don't store it, if they do?

I can only assume they mean it's not stored after your session ends.

That doesn't alter the fact that at some point, your master password and/or the keys derived from it reside on the server.

Discarding them at the end of the session doesn't negate the fact they're accessible to the server, during the session.

You see, Paul Moore "discovered" the #2 (which has never been a secret), and somehow wants to apply it to #1
Olivia @ Roboform Support

That's disingenuous too.

I have never confused the two variants... but when they say "Roboform never sends your master password", users are likely to see "Roboform" as an umbrella term describing any product which bears the name. Even if they spot the difference and research it further (as I did), they're likely to find Vadim's quote and assume "the master password is NEVER sent to the server".

It may not be a secret, but it's far from clear either.

Another message in the article is that #2 is not secure enough because of decryption on the server.
I would say it is still secure because of SSL connection
Olivia @ Roboform Support

HTTP, SSLv3 and RC4. Need I go on?

"Multi-Factor Authentication"

In September 2014, Siber Systems announced what they call "Multi-Factor Authentication".

As we know, 2FA in a PW manager is not possible, but they've given it a shot...

An OTP by email?! THAT'S NOT 2FA!

There are 3 factors.

1. Knowledge (something you know - passwords, PINs etc)
2. Possession (something you have - a smart card, yubikey etc)
3. Inherence (something you inherently are - fingerprint, iris/retina etc)

Your password combined with a PIN number sent by email are multiple steps of a single factor, or 2SV. Don't take my word for it... even NIST agrees (section 6.1.4).

I emailed Natalie Pinto @ Siber Systems to ask for their comment.

Anyway, let me provide a few more details that may help.

The OTP is only used once to register the device. We don't require that the user enter the OTP each time they access their Everywhere account. We drop a software token on the device based on the successful recognition of the OTP. So, the software token is "something you have.
We plan to add SMS as a delivery method for user's OTPs.
I looked at Wikipedia and saw that Soft tokens can be used as a multifactor option.
Natalie Pinto @ Roboform Support

An OTP via SMS isn't 2FA either.

Summary

Don't get me wrong, I wasn't expecting to be on Siber's Christmas card list, but I think the way they've handled these issues is disgraceful.

When it comes to choosing a password manager, trust is everything. Although Roboform (the desktop/mobile app) is undoubtedly more secure now, I wouldn't trust it with any personal information, let alone the keys to my digital life.

That's it folks.

05/01/2015:
Recipero, the company behind Immobilise, NMPR and CheckMEND have now mitigated this risk by limiting access to the "/verify" & pdf generation pages to only authorized users. You're no longer able to view records which you do not own, so although it's undoubtedly more secure, the inability to verify the authenticity of a certificate appears to render this process pointless.

This exploit is known as a direct object reference, though I colloquially refer to it as the "open DOR" attack to signify the ease at which it can be detected & exploited. Immobilise isn't the first site to be vulnerable to such an attack, but it's first I've seen which appears to be built around this flawed principle. If this technique meets "secured by design" criteria, you have to question how reliable this (or indeed any) trustmark really is.

The POODLE/SSLv3 exploit at both NMPR and CheckMEND has also been resolved, with both scoring a healthy "A" at Qualys. Perhaps ironically, some forces are now unable to access the site because Internet Explorer (as shipped with Windows XP) is only able to use insecure protocols (SSLv3). It's now the responsibility of the affected forces to ensure their software meets current standards.

"Immobilise can be used by members of the public and businesses to register their valued possessions or company assets, and exclusive to Immobilise all account holders registered items and ownership details are viewable on the Police national property database the NMPR. https://www.immobilise.com"

With an estimated 4.2 million users and 28 million records, the UK's National Property Register is the largest site of its kind; supported by central government, the mobile phone industry and every police force in the UK.

Unfortunately, it's also a veritable goldmine for burglars.

Quite apart from being "secured by design", Immobilise is quite happy to hand over its information to anyone, if you ask nicely.

How does it work?

Christmas is over and you're stuffed to the gills with turkey. What better way to relax than sit in front of your new 50" 3D TV and watch Moonraker, again.

But, you're back to work next week and your precious TV will be left unattended at home. If it's stolen, reporting the theft to Immobilise can increase the likelihood of its safe return. Once you've registered your device, you're given a certificate of ownership.

To download your certificate, you're given a link which looks something like this.
https://www.immobilise.com/pdf.php?stage=account&certificate=7161519&user=3714932

How is it vulnerable?

To understand what's going on, let's take a closer look at the certificate.

An attacker wouldn't know the "User ID" or "Certificate ID", so it's safe, right?

Far from it! The numbers aren't random, they're sequential, thus deterministic. If the last certificate number is 7161519, the next is 7161520 and so on. However, if someone happens to add another item to their account before you, your next number is 7161521.

By simply looping through every combination, it's possible to collect all 28+ million entries.

That's quite a nice shopping list for a would-be burglar! They'll know your name, home address, telephone number(s), email address, the make/model of your item, any identifying factors (serial numbers, IMEIs, unique marks etc) and even how much it's worth! Sure, it'll take some time and you're bound to hit a rate limiter along the way, but even if it takes a day/week/month, it's worth the wait.

Like you, I presumed this was a vulnerability and followed the usual responsible disclosure procedures. I sent this issue, along with several others to Les Gray (COO @ Recipero) in 2013. The most critical issues were patched very quickly; Les couldn't have been more helpful.

However, this particular issue still remains. In the last 48hrs, I realised this was actually intentional!

If you hand over a certificate to the police or your insurance company, they can use this page to confirm its authenticity.

What should I do?

Report it to the Information Commissioner's Office and delete your account immediately.

Had this been a simple vulnerability, that'd probably be overkill (though justified). As it's "by design" and mindful of the other issues which I can't disclose... the benefits just don't outweigh the risks.

I recently joined Immobilise and I've been burgled, is this to blame?

It's possible, but very doubtful.

Is the data secure once it reaches the Police?

Immobilise is the public-facing area of the system, so it's quite easy to carry out some basic checks.

The NMPR (National Mobile Property Register) is the Police National database for stolen property, directly fed by Immobilise data.

Unfortunately, they haven't bothered patching out POODLE/SSLv3...

Mindful of the government's propensity for using Windows XP and other archaic technology, it's entirely possible their credentials are travelling over the transport layer using insecure encryption. This system (and the sister site, CheckMEND) contain over 150 billion records. No, that's not a typo.

In case you're wondering, CheckMEND is also vulnerable to POODLE/SSLv3.

Summary

This is sadly one of those occasions when there's very little you can do to protect yourself. It uses HTTPS, it's backed by every UK police force and sports a plethora of padlocks & security trustmarks; there's no outward sign whatsoever that you're about to put your home at risk.

The moral of this story is two-fold.

1. Always be careful of what information you share on the web.
   and
2. Take trustmarks, padlocks and privacy policies with a pinch of salt. Even something which looks secure can be wide open to abuse.