UK Banking, Fineco is not enough

You may remember that the last time I blogged about UK banking I had just dismissed Barclays in favour of Fineco, the Italian investment bank, branch of UniCredit, This seemed a good move, both because people spoke very good of Fineco in my circles, at least in Italy, and because the sign up flow seemed so good that it sounded like a good idea.

I found out almost right away that something was not quite perfect for the UK market, in particular because there was (and is) no way to set up a standing order, which is the standard way to pay for your rent in the UK (and Ireland, for what it’s worth). But it seemed a minor thing to worry about, as the rest of the features of the bank (ability to spend up to £10k in a single transaction by requesting an explicit lift on the card limits with SMS authentication, just to say one).

Unfortunately, a couple of months later I know for sure it is not possible to use Fineco as a primary account in the UK at all. There are two problems, the first being very much a problem to anyone, and the second being a problem for my situation. I’ll start with the first one: direct debit support.

The direct debit system, for those not used to it in Europe, is one where you give a “debtor” (usually, an utility service, such as your ISP or power company) your account details (Sort Code and Account Number in the case of the UK), and they will tell the bank to give them money at certain time of the month. And it is the way Jeremy Clarkson lost £200, ten years ago. There is a nearly identical system in the rest of the EU, called SEPA Direct Debit (with SDD Core being the more commonly known about, as it deals with B2C, business-to-consumer) debits.

After I opened the Fineco account, I checked on Payments UK’s Sort Code Checker which features were enabled for it (30-02-48) and then, as well as the time of writing, it says «Bacs Direct Debits can be set up on this sort code.» So I had no refrain in closing my Barclays account and moving all the money into the newly created account. All of my utilities were more than happy to do so, except for ThamesWater that refused to let me set up the debit online. Turns out they were the only ones with a clue.

Indeed, when in January the first debit was supposed to land, instead of seeing the debit on the statement, I saw a BACS credit of the same amount. I contacted my ISP (Hyperoptic, with the awesome customer support) to verify if something failed on their side, but they didn’t see anything amiss for them. When even Netflix showed up the same way, and both of the transaction showed up an “entry reversal” of the same amount, I knew something was off with the bank and contacted them, originally to no avail.

Indeed, a few more debits showed up the same way, so I have been waiting for the shoe to drop, which it did at the end of January, when Fineco sent me an email (or actually, a ticket, it even has a ticket number!) telling me that they processed the debits as a one-off, but to cancel them because they won’t do this again. This was professional of them, particularly as this way it does not hit my credit score at all, but it still is a major pain in the neck.

My first hope was to be able to just use Revolut to pay the direct debits, since they are all relatively low amounts, which fit my usual auto top-up strategy. When you look at the Revolut information page with your account details for GBP, the text says explicitly «Use this personal UK current account to get salary and to pay bills», which brought me hope, and indeed the Payment UK’s checker also confirmed that it supposedly accepts Bacs Direct Debit. But when I checked with the in-app chat support, I was told that, no Revolut does not support direct debits, which makes that phrase extremely misleading. At least TransferWise explicitly denies supporting Direct Debit in the sort code checker, kudos to them.

The next problem with Fineco is not actually their fault, but is still due to them not having the “full features” of a UK high street bank. I got contacted by Dexters, the real estate company that among other things manages my apartment and collects my rent. While they told me the money arrived all good when I moved to Fineco (I asked them explicitly), they sent me a scary and threatening email (after failing to reach me on the phone, I was going to be charged excessively high roaming charges to answer an unknown number)… because £12 were missing from my payment. The email exchange wasn’t particularly productive (I sent them a photo of the payment confirmation, they told me «[they] received a large sum of money[sic] however it is £12.00 that is outstanding on the account.» So I called them on Monday, and they managed to confirm that it was actually £6 missing in December, and another £6 missing in January.

Throwing this around with colleague, and then discussing with a more reasonable person from Dexters on the phone, we came to figure out that Barclays (as the bank used by Dexters to receive the rent) is charging them £6 to receive these transfers because they are “international” — despite the fact that they are indeed local, it appears Barclays apply that fee for any transfer received over the SWIFT network rather than through the Faster Payments system used by most of the other UK banks. I didn’t want to keep arguing with Dexters over the fact that it’s their bank charging them the fee, I paid the extra £12, and decided to switch the rent payment over to the new account as well. I really dislike Barclays.

I’ll post later this month on the following attempts with other bank accounts. For now I decided that I’ll keep getting my salary into Fineco, and keep a running balance on the “high street” account for the direct debits, and the rent. Right now for my only GBP credit card (American Express) I still pay the balance off Fineco via debit card payment anyway, because the credit limit they gave me is quite limited for my usual spending, particularly now that I can actually charge that card when booking flights on BA without having to spend extra money in fees.

Designing My Password Manager

So while at the (in my opinion excellent) Enigma, Tavis decided to nerd snipe me into thinking of how would I design a password manager. This because he knows (and disagree with) my present choice of using LastPass as my password manager of choice, despite the existence of a range of opensource password managers.

The main reason why I have discarded the choice of the available password managers is that, in my opinion, they all miss the main point of what a password manager should be: convenient. Password reuse is a problem because it’s more convenient than using dozens, maybe hundreds of different passwords for all the different services. An easy to use password manager is even more convenient than reusing password.

The first problem I found with effectively all of the opensource password managers I know of just use a single file-blob, and leave to you the problem of syncing it. The best I have seen was one software providing integration with Dropbox, Google Drive and ownCloud to sync the blob around, just as long as you don’t make conflicting changes on different devices. To me, the ability to make independent changes to services is actually a big requirement. This means that I would be using a file format that allows encrypting “per row”, both the keys and the values (because you don’t want to leak which accounts the user registered on, if the file is leaked). I would probably gravitate around something like the Bigtable format.

Another problem, which is present in Chrome SmartLock too, is the lack of support for what LastPass call “equivalent domains”. Due to many silly reasons, particularly if you travel a lot or if you live in different countries, you end up collecting a long list of websites using either separate domain names, or at least different TLDs. An example of this is Amazon, that use a constellation of different domains, but all share the same account management (except for Amazon Japan). A sillier example for this are Yelp and TripAdvisor, that decide to change your TLDs depending on the IP address you’re coming from, despite being the kind of services you would use particularly outside your usual country.

Admittedly, as Tavis suggested, these should be solved by the services themselves, using a single host for login/identity management. I do not expect this to happen any time soon. My previous proposal for this was defining equivalence as part as a well known configuration file (together with other improvements to password management). I now have some personal introspection questions about this, because I wonder if there is a privacy risk in sending requests to other domain to validate the reciprocal equivalence configurations. So I think I’ll leave this up for debate for later.

The next design bit is figuring out how should the password generator behave. We already have a number of good password generators of different types, including software implementations of diceware passwords (despite the site repeatedly telling you not to use computer random generators — to add to the inconvenience), and xkcdpass, that generate passwords that are easier to remember or at least to type. I think that a good password manager should allow for more than just the random-bunch-of-characters passwords that LastPass uses.

In particular, for me, I have a few websites for which I use passwords generated by xkcdpass, because I need to actually type in the password, rather than use the password manager autofill capabilities. This is the case of Sony and Nintendo accounts, that need to be typed from consoles, and of Telegram, as I need to type the password on my watch to receive messages there. Unfortunately implementing this is probably going to be an UX nightmare — one of the reason being the ability to select different wordlists. Non-English speakers are likely interested in using their own language for it. Or even the English speakers that are not afraid of other languages, and may decide to throw off a possible attacker anyway.

Ideally, the password generation settings would be stored on a domain-by-domain basis, so that if a certain website only allows numbers in its passcode, or it has a specific character limit, the same setting is used to generated a password if it’s ever breached. This may sound minor, but to me it would be so much more of a time (and frustration) saver, that it would easily become a killer feature.

But all of these idea fall to nothing without good, convenient, and trustworthy client implementations. Right now one of the many weak spots of LastPass is its Chrome extension (and Firefox too). A convenient password manager, though, ought to be able to integrate with the browser and, since it’s 2018 after all, with your phone. Unfortunately, here is where any opensource offering can’t really help as much as we would all like: it still relies (hugely) on trust. As far as I can tell, there is no way to make absolutely certain that the code of a Chrome extension on the Web Store, or of an Android app on either Play Store or F-Droid, corresponds exactly with a certain source distribution.

Don’t get me wrong, this is a real problem right now, with closed source extensions too. You need to trust the extension is not injecting malicious content in your webpage, or exfiltrating data out of your browser session. Earlier this year a widely used Chrome extension was reported as malicious, but it wasn’t until that was identified that it was removed from Chrome’s repository. At least I can have a (maybe underserved) trust in LogMeIn not to intentionally ruin their reputation by pushing actively malicious code to the Store. Would I say the same for a random single developer maintaining their widely used extension?

What this means to me is that building a good replacement for LastPass is not just a technical problem that needs to be solved by actively syncing with cloud storage services… it’s a problem of social trust, and that requires quite a bit of thought from many actors of the market: browser vendors, device manufacturers, and developers, which I’m not sure is currently happening. So I don’t hold my breath, and keep at compromises. I made mine with my threats in mind, you should make yours with what concerns you the most.

Diabetes Software: the importance of documented protocols

You may remember that just last week I was excited to announce that I had more work planned and lined up for my glucometer utilities, one of which was supporting OneTouch Verio IQ which is a slightly older meter that is still sold and in use in many countries, but for which no protocol is released.

In the issue I linked above you can find an interesting problem: LifeScan discontinued their Diabetes Management Software, and removed it from their website. Indeed instead they suggest you get one of their Bluetooth meters and to use that with their software. While in general the idea of upgrading a meter is sane, the fact that they decided to discontinue the old software without providing protocols is at the very least annoying.

This shows the importance of having open source tools that can be kept alive as long as needed, because there will be people out there that still rely on their OneTouch Verio IQ, or even on the OneTouch Ultra Easy, which was served by the same software, and is still being sold in the US. Luckily at least they at least used to publish the Ultra Easy protocol specs and they are still available on the Internet at large if you search for them (and I do have a copy, and I can rephrase that into a protocol specification if I find that’s needed).

On the bright side, the Tidepool project (of which I wrote before) has a driver for the Verio IQ. It’s not a particularly good driver, as I found out (I’ll get to that later), but it’s a starting point. It made me notice that the protocol was almost an in-between of the Ultra Easy and the Verio 2015, which I already reverse engineered before.

Of course I also managed to find a copy of the LifeScan software on a mostly shady website and a copy of the “cable drivers” package from the Middle East and Africa website of LifeScan, which still has the website design from five years ago. This is good because the latter package is the one that installs kernel drivers on Windows, while the former only contains userland software, which I can trust a little more.

Comparing the USB trace I got from the software with the commands implemented in the TidePool driver showed me a few interesting bits of information. The first being the first byte of commands on the Verio devices is not actually fixed, but can be chosen between a few, as the Windows software and the TidePool driver used different bytes (and with this I managed to simplify one corner case in the Verio 2015!). The second is that the TidePool driver does not extract all the information it should! In particular the device allows before/after meal marking, but they discard the byte before getting to it. Of course they don’t seem to expose that data even from the Ultra 2 driver so it may be intentional.

A bit more concerning is that they don’t verify that the command returned a success status, but rather discard the first two bytes every time. Thankfully it’s very easy for me to check that.

On the other hand, reading through the TidePool driver (which I have to assume was developed with access to the LifeScan specifications, under NDA) I could identify two flaws in my own code. The first was not realizing the packet format between the UltraEasy and the Verio 2015 was not subtly different as I thought, but it was almost identical, except the link-control byte in both Verio models is not used, and is kept to 0. The second was that I’m not currently correctly dropping out control solutions from the readings of the Verio 2015! I should find a way to get a hold of the control solution for my models in the pharmacy and make sure I get this tested out.

Oh yeah, and the TidePool driver does not do anything to get or set date and time; thankfully the commands were literally the same as in the Verio 2015, so that part was an actual copy-paste of code. I should probably tidy up a bit, but now I would have a two-tier protocol system: the base packet structure is shared between the UltraEasy, Verio IQ and Verio 2015. Some of the commands are shared between UltraEasy and Verio IQ, more of them are shared between the Verio IQ and the Verio 2015.

You can see now why I’ve been disheartened to hear that the development of drivers, even for open source software, is done through closed protocol specifications that cannot be published (or the drivers thoroughly commented). Since TidePool is not actually using all of the information, there is no way to tell what certain bytes of the responses represent. And unless I get access to all the possible variants of the information, I can’t tell how some bytes that to me look like constant should represent. Indeed since the Verio 2015 does not have meal information, I assumed that the values were 32-bit until I got a report of invalid data on another model which shares the same protocol and driver. This is why I am tempted to build “virtual” fakes of these devices with Facedencer to feed variants of the data to the original software and see how it’s represented there.

On the bright side I feel proud of myself (maybe a little too much) for having spent the time to rewrite those two drivers with Construct while at 34C3 and afterwards. If I hadn’t refactored the code before looking at the Verio IQ, I wouldn’t have noticed the similarities so clearly and likely wouldn’t have come to the conclusion it’s a shared similar protocol. And no way I could have copy-pasted between the drivers so easily as I did.

Glucometerutils News: Continuous Integration, Dependencies, and Better Code

You may remember glucometerutils, my project of an open source Python tool to download glucometer data from meters that do not provide Linux support (as in, any of them).

While the tool started a few years ago, out of my personal need, this year there has been a bigger push than before, with more contributors trying the tool out, finding problem, fixing bugs. From my part, I managed to have a few fits of productivity on the tool, particularly this past week at 34C3, when I decided it was due time to start making the package shine a bit more.

So let’s see what are the more recent developments for the tool.

First of all, I decided to bring up the Python version requirement to Python 3.4 (previously, it was Python 3.2). The reason for this is that it gives access to the mock module for testing, and the enum module to write actual semantically-defined constants. While both of these could be provided as dependencies to support the older versions, I can’t think of any good reason not to upgrade from 3.2 to 3.4, and thus no need to support those versions. I mean, even Debian Stable has Python 3.5.

And while talking about Python versions, Hector pointed me at construct, which looked right away like an awesome library for dealing with binary data structures. It turned out to be a bit more rough around the edges than I’ve expected from the docs, particularly because the docs do not contain enough information to actually use it with proper dynamic objects, but it does make a huge difference compared to dealing with bytestring manually. I have started already while in Leipzig to use it to parse the basic frames of the FreeStyle protocol, and then proceeded to rewrite the other binary-based protocols, between the airports and home.

This may sound like a minor detail, but I actually found this made a huge difference, as the library already provides proper support for validating expected constants, as well as dealing with checksums — although in some cases it’s a bit heavier-handed than I expected. Also, the library supports defining bit structures too, which simplified considerably the OneTouch Ultra Easy driver, that was building its own poor developer version of the same idea. After rewriting the two binary LifeScan drivers I have (for the OneTouch Verio 2015 and Select Plus, and the Ultra Easy/Ultra Mini), the similarities between the two protocols are much easier to spot. Indeed, after porting the second driver, I also decided to refactor a bit on the first, to make the two look more alike.

This is going to be useful soon again, because two people have asked for supporting the OneTouch Verio IQ (which, despite the name, shares nothing with the normal Verio — this one uses an on-board cp210x USB-to-serial adapter), and I somehow expect that while not compatible, the protocol is likely to be similar to the other two. I ended up finding one for cheap on Amazon Germany, and I ended up ordering it — it would be the easier one to reverse engineer from my backlog, because it uses a driver I already known is easy to sniff (unlike other serial adapters that use strange framing, I’m looking at you FT232RL!), and the protocol is likely to not stray too far from the other LifeScan protocols, even though it’s not directly compatible.

I have also spent some time on the tests that are currently present. Unfortunately they don’t currently cover much of anything beside for some common internal libraries. I have though decided to improve the situation, if a bit slowly. First of all, I picked up a few of the recommendations I give my peers at work during Python reviews, and started using the parameterized module that comes from Abseil, which was recently released opensource by Google. This reduces tedious repetition when building similar tests to exercise different paths in the code. Then, I’m very thankful to Muhammad for setting up Travis for me, as that now allows the tests to show breakage, if there is any coverage at all. I’ll try to write more tests this month to make sure to exercise more drivers.

I’ve also managed to make the setup.py in the project more useful. Indeed it now correctly lists dependencies for most of the drivers as extras, and I may even be ready to make a first release on PyPI, now that I tested most of the devices I have at home and they all work. Unfortunately this is currently partly blocked on Python SCSI not having a release on PyPI itself. I’ll get back to that possibly next month at this point. For now you can install it from GitHub and it should all work fine.

As for the future, there are two in-progress pull requests/branches from contributors to add support for graphing the results, one using rrdtool and one using gnuplot. These are particularly interesting for users of FreeStyle Libre (which is the only CGM I have a driver for), and someone expressed interest in adding a Prometheus export, because why not — this is not as silly as it may sound, the output graphs of the Libre’s own software look more like my work monitoring graphs than the usual glucometer graphs. Myself, I am now toying with the idea of mimicking the HTML output that the Accu-Check Mobile generate on its own. This would be the easiest to just send by email to a doctor, and probably can be used as a basis to extend things further, integrating the other graphs output.

So onwards and upwards, the tooling will continue being built on. And I’ll do my best to make sure that Linux users who have a need to download their meters’ readings have at least some tooling that they can use, and that does not require setting up unsafe MongoDB instances on cloud providers.

SMS for two-factors authentication

Having spent now a few days at the 34C3 (I’ll leave comments over that to discussion to happen in front of a very warm coffee with a nice croissant to the side), I have heard a few times already presenters referencing the SS7 hack as an everyday security threat. You probably are not surprised I don’t agree with that being an everyday security issue, while still thinking this is a real security issue.

Indeed, while some websites refer to the SS7 hack as the reason not to use SMS for auth, at least you can find more reasonable articles talking about the updated NIST recommendation. Myself, the preference for TOTP (as it’s used in authenticator apps), is because I don’t need to be registered on a mobile network and I can use it to login while in flights.

I want to share some more thoughts that add up to the list of reasons to not use SMS as the second factor authentication. Because while I do not believe SS7 attack is something that all users should be accounting for in their day-to-day life, it is an addition to the list of reasons why SMS auth is not a good idea at all, and I don’t want people to think that, since they are unlikely to be attacked by someone leveraging SS7, they are okay with using SMS authentication instead.

The obvious first problem is reliability: as I said in the post linked above, SMS-based authentication requires you to have access to the phone with the SIM, and that it’s connected to the network and allowed to receive the SMS. This is fine if you never travel and you have good reception where you need to use this. But myself, I have had multiple situations in which I was unable to receive SMS (in flights as I said already, or while visiting China the first time, with 3 Ireland not giving access to any roaming partners to pay-as-you-go customers, or even at my own desk at my office with 3 UK after I moved to London).

This lack of reliability is unfortunate, but not by itself a security issue: it prevents you from accessing the account that the 2FA is set on, and that would sound like it’s doing what it’s designed to do, failing close. At the same time, this increases the friction of using 2FA, reducing usability, and pushing users, bit by bit, to stop using 2FA altogether. Which is a security problem.

The other problem is the ability to intercept or hijack those messages. As you can guess by what I wrote above, I’m not referring to SS7 hacks or equivalent. It’s all significantly more simple.

The first way to intercept the SMS auth messages is having access to the phone itself. Most phones, iOS and Android alike, are configured to show new text messages in the standby page. In some cases, only a part of the message is visible, and to have access to the rest of the message you’d have to unlock the phone – assuming the phone is locked at all – but 2FA authentication messages tend to be very short and to the point, showing the number in the preview, for ease of access. On Android, such a message can also be swiped away without unlocking the phone. An user that would be victim to this type of interception might have a very hard time noticing this, as nowadays it’s likely the SMS app is not opened very often, and a swiped-off notification would take time to be noticed¹.

The hijacking I have in mind is a bit more complicated and (probably) noticeable. Instead of using the SS7 hack, you can just take over a phone number by leveraging the phone providers. And this can be done in (at least) two ways: you can convince the victim’s phone provider to reprovision the number to a new SIM card within the same operator, or you can port the number to a new operator. The complexity or easiness of these two processes change a lot between countries, some countries are safer than others.

For instance, the UK system for number portability is what I expect to be the more secure (if not the most userfriendly) I have seen. The first step is to get a Portability Authorization Code (PAC) for the number you want to port. You do that by calling the current provider. None of the three providers I had up to now in the UK had any way to get this code online, which is a tad safer, as a misplaced password cannot bring full access to the account line. And while the code could be “intercepted” the same way as I pointed out above for authentication codes, the (new) operator does get in touch with you reminding you when the portability will take place, and giving you a chance to contact them if it doesn’t sound right. In the case of Vodafone, they also send you an email when you request the PAC, meaning just swiping away the notification is not enough to hide the fact that it was requested in the first place.

In Ireland, a portability request completes in the span of less than an hour, and only requires you to have (brief) access to the line you want to take over, as the new operator will send you a code to confirm the request. Which means the process, while being significantly easier for the customers, is also extremely insecure. In Italy, I actually went to the store with the line that I wanted to port, and I don’t remember if they asked anything but my IDs to open the new line. No authentication code is involved at all, so if you can fake enough documents, you likely can take over any lines. I do not remember if they notified my old SIM card before the move. I have not tried number portability in France, but it appears you can get the RIO (the equivalent transfer code) from the online system of Free at the very least.

The good thing about all the portability processes I’ve seen up to now is that at least they do not drop a new number on the old SIM card. I was told that this is (or was at least) actually common for US providers, where porting a number out just assign a new number to the old SIM. In that case, it would probably take a while for a victim to notice they had their account taken over. And that would not be a surprise.

If you’re curious, you can probably try that by yourself. Call your phone provider from another number than your own, see how many and which security questions they ask you to identify that it is actually their customer calling, instead of a random stranger. I think the funniest I’ve had was Three Ireland, that asked me for the number I “recently” sent a text message to, or a recent call made or received — you can imagine that it’s extremely easy to force you to get someone to send you a text message, or have them call you, if you’re close enough to them, or even just have them pick up the phone and reporting to the provider that you were last called by the number you used.

And then there is the other interesting point of SMS-based authentication: the codes last longer in time. A TOTP has a short lifetime by design, as it’s time based. Add some fuzzing, most of the implementations I’ve seen allow a single code to be valid for 2× the time the code is displayed on the authenticator, by accepting a code from the past, or from the future, generally at half the expected duration. Since the normal case has the code lasting for 60 seconds, they would accept a code 30 seconds before it’s supposed to be used, and 30 seconds after. But text messages can (and do) take much longer than that.

And this is particularly useful for attackers of systems that do not implement 2FA correctly. Entering the wrong OTP most of the time does not invalidate a login attempt, at least not on the first mistake, because users can mistype, or they can miss the window to send an OTP over. But sometimes there are egregious errors, such as that made by N26, where they neither ratelimited, nor invalidated the OTP requests, allowing a simple bruteforcing of a valid OTP. Since TOTP change without requesting a new code, bruteforcing those give you a particularly short time span of viability… SMS on the other hand, open for a much larger window of opportunity.

Oh and remember the Barclays single-factor-authentication? How long do you think it would take to spoof the outgoing number of the SMS that needs to be sent (with the text “Y”) to authorize the transaction, even without having access to the text message that was sent?

This is an argument for using another of your messaging apps to receive text messages, whether it is Facebook Messenger, Hangouts or Signal. Assuming you use any of those on a day-to-day basis, you would then have an easy way to notice if you received messages you have not seen before.
^[return]

Barclays and the single factor authentication

In my previous post on the topic I have barely touched on one of the important reasons why I did not like Barclays at all. The reason for that was that I still had money into my account with them, and I wanted to make sure that was taken care of before lamenting further on the state of their security. As I managed to close my account now, I should go on and discuss this further, even though I have touched upon the major topics of this.

Barclays online banking system relies heavily on what I would define as “single factor authentication”.

Usually, you define authentication factors as things you have or things you know. In the case of Barclays, the only thing they effectively rely upon is “access to the debit card”. Okay, technically you could say that by itself it’s a two-factor system, as it requires access to the debit card and to its PIN. And since the EMV-CAP protocol they use for this factor executes directly on the chipcard, it is not susceptible to the usual PIN-stripping attacks as most card fraud with chip-and-pin cards uses.

But this does not count for much when the PIN of the card they issued me was 7766 — and to lament of that is why I waited to close the account and give them back the card. It seems like there’s a pattern of banks issuing “easy to remember” 4-digit PINs: XYYX, XXYY, etc. One of my previous (again, cancelled) cards had a PIN terribly easy to remember for a computerist, at least not for the average person though: 0016.

Side note: I have read someone suggesting to badly scribbled a wrong PIN on the back of a card as a theft prevention. Though I like that idea, I’m just afraid the banks won’t like it anyway. Also it would take some work to make the scribble being easily misunderstood for different digits so that they can try the three times needed to block it.

You access Barclays online banking account through the use of the Identify method provided by CAP, which means you put the card into the reader, provide the PIN, and you get an 8-digits identifier that can be used to login on the website. Since I’m no expert of how CAP works internally, I will only venture a guess that this is similar to a counter-based OTP, as the card has no access to a real-time clock, and there is no challenge provided for this information.

This account access sounds secure, but it’s really not any more secure than an username and password, at least when it comes to dealing with phishing. You may think that producing a façade that shows the full Barclays login, and proxies the responses in real time is a lot of work, but the phishing tools are known for being flexible, and they don’t really need to reproduce the whole website, just the parts they care about getting data from. The rest can easily be proxied as it is without any further change, of course.

So what can we do once you can fool someone into logging in to the bank? Well, you can’t really do much, as most of the actions require further CAP confirmation: wires, new standing orders, and so on so forth. You can, though, get a lot of information about the victim, including enough proofs of address or identity that you can really mess with their life. It also makes it possible to cancel things like standing orders to pay for rent, which would be quite messy to deal with for most people — although most of the phishing is not done for the purpose of messing with people, and more to get their money.

As I said, for sending money you need to have access to the CAP codes. That includes having access not only to the device itself, but also the card and the PIN. To execute those transactions, Barclays will ask you to sign a transaction by providing the CAP device with the account number and the amount to wire. This is good and it’s pretty hard to tamper with, hopefully (I do not make any guarantee on the implementation of CAP), so even if you’re acting through a proxy-phishing site, your wires are probably safe.

I say probably, because the way the challenge-response is implemented, only the 8-digits account number is used during the signature. If the phishers are attacking a victim that they studied for long enough, which may be the case when attacking businesses, you could know which account they pay every month manually, and set up an account with the same number at a different bank (different sort code). The signature would be valid for both.

To be fair to Barclays, implementing the CAP fully, the way they did here, is actually more secure than what Ulster Bank (and I assume the rest of RBS Group) does, with an opaque “challenge” token. While this may encode more information, the fact that it’s opaque means there is no way for the user to know whether what they are signing is indeed what they meant to.

Now, these mitigations are actually good. They require continuous access to the card on request, and that makes it very hard for phishing to just keep using the site in the background after the user logged in. But they still rely on effectively a single factor. If someone gets a hold of the card and the PIN (and we know at least some people will write the real one on the back of the card), then it’s game over: it’s like the locks on my flat’s door: two independent locks… except they use the same key. Sure, it’s a waste of time to pick both, so it increases the chances a neighbour would walk in on wannabe burglars trying to open the apartment door. But there’s a single key, I can’t just use two separate keychains to make sure a thief would only grab one of the two, and if anyone gets it from me, well, it’s game over.

Of course Barclays knows that this is not enough, so they include a risk engine. If something in the transactions don’t comply with their profile of your activity, it’s considered risky and they require an additional verification. This verification happens to be in form of text messages. I will not suggest that the problem with these is with GSM-layer attacks, as that is still not (yet) in the hands of the type of criminals aiming at personal bank accounts, but there is at the very least the risk that a thieve would get a handle of my bag with both my card and my phone, so the only “factors” that are still in my head, rather than tied to the physical objects, are the (provided) PIN of the card, and the PIN of the phone.

This profile fitting is actually the main reason why I got frustrated with Barclays: since I had just opened the account, most of the transactions were all “exceptional”, and that is extremely annoying. This was compounded by the fact that my phone provider didn’t even let me receive SMS from the office, due to lack of coverage (now fixed), and the fact that at least for wires, the Barclays UI does not warn you to check your phone!

There is also the problem with the way Barclays handle these “exceptional transactions”: debit card transactions are out-and-out rejected. The Verified by Visa screen tells you to check your phone, but the phone will only ask you if it was your transaction or not, and after you confirm it is, it’ll ask you to “retry in a couple of minutes” — retrying too quickly will lead to the transactions being blocked by the processor directly, with a temporary card lock. The wire transfer one will unblock the execution of the wire, which is good, but it can also push the wire to after the cut-off time for non-“Faster Payments” wires.

Update (2017-12-30): since I did not make this very clear, I have added a note about this at the bottom of my new post, about the fact hat confirming these transactions only need you to spoof the sender, since the content and destination of the text message to send are known (it only has to say “Y”, and it’s always to the same service number). So this validation should not really count as a second factor authentication for a skilled attacker.

These are all the reasons for which I abandoned Barclays as fast as I could. Some of those are actually decent mitigation strategies, but the fact that they do not really increase security, while increasing inconvenience, makes me doubt the validity of their concerns and threat models.

New, new gamestation

Full disclosure: the following posts has a significantly higher amount of Amazon Affiliates links than usual. That’s because I am talking about the hardware I just bought, and this post counts just as much as an update on my hardware as a recommendation on the stuff I bought, I have not gotten hacked or bought out by anyone.

As I noted in my previous quick update, my gamestation went missing in the move. I would even go as far as to say that it was stolen, but I have no way to prove whether it was stolen by the movers or during the move. This meant that I needed to get a new computer for my photo editing hobby, which meant more money spent, and still no news from the insurance. But oh well.

As for two years ago, I wanted to post here the current hardware setup I have. You’ll notice a number of similarities with the previous configuration, because I decided to stick as much as possible to what I had before, that worked.

CPU: Intel Core i7 7820X, which still has a nice 3.6GHz base clock, and has more cores than I had before.
Motherboard: MSI X299 SLI PLUS. You may remember that I had problems with the ASUS motherboard.
Memory: 8×Crucial 16GB DDR4.
Case: Fractal Design Define S, as I really like the designs of Fractal Design (pun not intended), and I do not need the full cage or the optical disk bays for sure this time around.
CPU cooler: NZXT Kraken X52, because the 280mm version appears to be more aimed towards extreme overclockers than my normal usage; this way I had more leeway on how to mount the radiator in.
SSD: 2×Crucial MX300 M.2 SATA. While I liked the Samsung 850 EVO, the performance of the MX300 appear to be effectively the same, and this allowed me to get the M2 version, leaving more space if I need to extend this further.
HDD: Toshiba X300 5TB because there is still need for spinning rust to archive data that is “at rest”.
GPU: Zotac GeForce GTX 1080Ti 11GB, because since I’m spending money I may just as well buy a top of the line card and be done with it.
PSU: Corsair RM850i, for the first time in years betraying beQuiet! as they didn’t have anything in stock at the time I ordered this.

This is the configuration in the chassis, but that ended up not being enough. In particular, because of my own stupidity, I ended up having to replace my beloved Dell U2711 monitor. I really like my UltraSharp, but earlier this year I ended up damaging the DisplayPort input on it — friends don’t let friends use DisplayPort with hooks on them! Get those without for extra safety, particularly if you have monitor arms or standing desks! Because of this I have been using a DVI-D DualLink cable instead. Unfortunately my new videocard (and most new videocard I could see) do not have DVI ports anymore, preferring instead multiple DisplayPort and (not even always) HDMI output. The UltraSharp, unfortunately, does not support 2560×1440 output over HDMI, and the DisplayPort-to-DVI adapter in the box is only for SingleLink DVI, which is not fast enough for that resolution either. DualLink DVI adapters exist, but for the most part they are “active” converters that require a power supply and more cables, and are not cheap (I have seen a “cheap” one for £150!)

I ended up buying a new monitor too, and I settled for the BenQ BL2711U, a 27 inches, 4k, 10-bit monitor “for designers” that boasts a 100% sRGB coverage. This is not my first BenQ monitor; a few months ago I bought a BenQ BL2420PT, a 24 inches monitor “for designers” that I use for both my XPS and for my work laptop, switching one and the other as needed over USB-C, and I have been pretty happy with it altogether.

Unfortunately the monitor came with DisplayPort cables with hooks, once again, so at first I decided to connect it over HDMI instead. And that was a big mistake, for multiple reasons. The first is that calibrating it with the ColorMunki was showing a huge gap between the colours uncalibrated and calibrated. The second was that, when I went to look into it, I could not enable 10-bit (10 bpc) mode in the NVIDIA display settings.

Repeat after me: if you want to use a BL-series BenQ monitor for photography you should connect it using DisplayPort.

The two problems were solved after switching to DisplayPort (temporarily with hooks, and ordered a proper cable already): 10bpc mode is not available over HDMI when using 4k resolution and 60Hz. HDMI 2 can do 4k and 10-bit (HDR) but only at lower framerate, which makes it fine for watching HDR movies and streaming, but not good for photo editing. The problem with the calibration was the same problem I noticed, but couldn’t be bothered figuring out how to fix, on my laptops: some of the gray highlighting of text would not actually be visible. For whatever reason, BenQ’s “designer” monitors ship with the HDMI colour range set to limited (16-235) rather than full (0-255). Why did they do that? I have no idea. Indeed switching the monitor to sRGB mode, full range, made the calibration effectively unnecessary (I still calibrated it out of nitpickery), and switching to DisplayPort removes the whole question on whether it should use limited or full range.

While the BenQ monitors have fairly decent integrated speakers, which make it unnecessary to have a soundbar for hearing system notifications or chatting with my mother, that is not the greatest option to play games on. So I ended up getting a pair of Bose Companion 2 speakers which are more than enough for what I need to use them for.

Now I have an overly powerful computer, and a very nice looking monitor. How do I connect them to the Internet? Well, here’s the problem: the Hyperoptic socket is in the living room, way too far from my computer to be useful. I could have just put a random WiFi adapter on it, but I also needed a new router anyway, since the box with my fairly new Linksys also got lost in the moving process.

So upon suggestion from a friend, and a recommendation from Troy Hunt I ended up getting a UAP-AC-PRO for the living room, and a UAP-AC-LITE for the home office, topped it with an EdgeRouter X (the recommendation of which was rescinded afterwards, but it seems to do its job for now), and set them as a bridge between the two locations. I think I should write down networking notes later, but Troy did that already so why bother?

So at the end of this whole thing I spent way more money on hardware than I planned to, I got myself a very new nice computer, and I have way too many extra cables than I need, plus the whole set of odds and ends of the old computer, router and scanner that are no longer useful (I still have the antennas for the router, and the power supply for the scanner). And I’m still short of the document scanner, which is a bit of a pain because I now have a collection of documents that need scanning. I could use the office’s scanners, but those don’t run OCR for the documents, and I have not seen anything decent to apply OCR to PDFs after the fact, I’m open to suggestions as I’m not sure I’m keen on ending up buying something like the EPSON DS-310 just for the duplex scanning and the OCR software.

UK Banking, Attempt 2: Fineco Bank

So after a fairly negative experience with Barclays I have been quickly looking for alternatives. Two acquaintances who don’t know each other both suggested me to look into Fineco, which is an Italian bank also operating in the United Kingdom. As you can tell from their website, their focus is on trading and traders, but turns out they also make a fairly decent bank in and by themselves.

Indeed, opening the account with Fineco has been fairly straightforward: a few online forms, uploading documents to their identity verification system (very similar to what Revolut does, except using an Italian company that I already knew and was a customer of), and then sending £1 from a bank account that is already opened in your name. I found the forms also technically well-designed, particularly the fact that all the “I agree to” checkboxes automatically trigger JavaScript downloads of PDFs with the terms agreed, whether you clicked to read the agreement or not — I guess it’s a «No excuse, you have a copy of this» protection on their side, but it also made it very easy to archive all the needed information together with everything else I keep.

I should note here that it looks like Fineco’s target audience is Italian expats in the UK explicitly. It is common for most services to “special case” their local country as the first entry in the country drop-down, and then add the rest in alphabetical order. In the case of Fineco, the drop-down started with United Kingdom and Italy for all the options.

One of the good thing about this bank being focused so much on trading is that the account is by default a multicurrency one, similar to TransferWise Borderless Account. Indeed, in addition to the primary Sterling account, Fineco sets you up right away with accounts in Euro, Swiss Francs, and US Dollars, all connected to the same login. And in addition to this, they offer you the choice between a Sterling debit card, an Euro credit card, or both (for a reasonable fee of £10/yr). The two debit cards that are connected to the respective currency accounts (and no card is available for Francs or Dollars), and there are no foreign transaction fees for the two. While Revolut mostly took care of my foreign transaction fees, it’s always good to have a local debit card with a much higher availability, particularly as ATM access for Revolut has a relatively low monthly limit.

One of the interesting details of these currency accounts is that they all have Italian IBAN and BIC (with a separate SWIFT routing number, of its parent group UniCredit). For the main Sterling account, UK-style Sort Code and Account Number are available, which make it a proper local account.

This is actually very useful for me: for the past four years I have been keeping my old Italian account open, despite it costing me a fair bit of money just in service, because I have been paying the utilities for my mother’s house. And despite SEPA Direct Debit having been introduced over two years ago, the utilities I contacted failed to let me debit a foreign (Irish) account. Since I left Ireland, and the UK is not a Euro country, I was afraid I would have to keep my Italian account open even longer, but this actually solved the problem: for Italian utilities, the account is a perfectly valid Italian account, as for the most part they don’t even validate the billing address.

An aside: Vodafone Italy and Wind 3 Italy are still attached to my Tesco credit card, which Tesco Bank assures me I can keep using as long as I direct debit it into an Euro account anywhere. They even changed my mailing address to my new apartment in London. Those two companies insist that they only ever accept Italian credit cards, but they accepted my Irish credit card just fine before; in the case of Vodafone, they have an explicit whitelist of the BIN (for whatever reason), while Wind couldn’t get a hold of the concept that the card is Irish at all. Oh well.

Speaking of direct debits and odd combinations, while I should have now managed to switch all the utilities, including the council tax, to direct debit on this new account, I had some trouble doing the setup with Thameswater, the water provider in my area. If I tried setting up the direct debit online, it would report Fineco’s sort code (30-02-48) as invalid. The Sort Code Checker provided by the category association says it’s valid and it works for everything beside the cheque and credit clearing (which is unneeded). I ended up having to call them and ask them to override the warning, but they have not sent me confirmation that they managed. This appears to be a common “feature” of Thameswater — oh and by the way their paper form to request the direct debit was a 404 response on their website. Sigh.

The UI of the bank (and of their app) is much more information-dense than any other bank I’ve ever used. It’s not a surprise when you consider that they their target audience is investors and traders. It does work well for me, but I can see how this would not be the most pleasing interface for most home users. The only feature I have been unable to find yet in the interface is how to set up standing orders – I contacted them this weekend and will see what they say – so for the moment I just set up a few months worth of rent as scheduled payments, which work just as fine for the moment.

The Android app supports fingerprint authentication (unlike Barclay’s) and does not come with its own NFC payment system. Unfortunately the debit cards also appear not to be enabled for Android Pay, which is a bit of a shame. They also don’t leverage the app to send notifications, but they do send free SMS for new offline¹ transactions happening on the debit card, which is great.

All in all, I may have found the bank I was looking for. It’s not a “cuddly” bank, but it appears to have what I need and it appears to work for my needs. With a bit of luck it will mean by Q1 I’ll be done with all the other bank accounts in both Ireland and Italy, and finally it’ll be simpler to keep an eye onto how much money I have and how much of it is spent around the place (although GnuCash does help a bit there). I’ll keep you all posted if this changes.

Confusingly enough, a transaction happening over the Internet is an “offline” transaction. The online/offline is referred to the chip for chip’n’pin cards. If the chip is connected to a terminal that is in turn connected to the bank, that’s an online transaction. Otherwise it’s offline. If you read or type the number manually, it’s also offline.
^[return]

UK Banking, Attempt 1: Barclays

You may remember that back in August, I tried opening a NatWest account while not living in the UK yet, and hit a stonewall of an impossible declaration being required by the NatWest employees. I gave up on setting up a remote account, and waited to open one once I got in the country. Since the Northern Irish account seemed to be good for all I needed to do (spoiler: it wasn’t), I decided to wait for the Barclays representative to show up on my official starting date, and set up a “Premier” account with them.

The procedure, that sounded very “special” beforehand, turned out to just be a “Here is how you fill in the forms on the website”. Then, instead of sending you to a local branch to get your documents copied and stamped (something that appears to be very common in the British Isles), they had three people doing the stamping on a pre-made copy of the passport. Not particularly special, but at least practical, right?

Except they also said it would take a few day for the card, but over a week to have access the online banking as they need to “send me more stuff”. The forms were filled in on Monday, set up by Tuesday, and the card arrived on Wednesday, with the PIN following on Thursday. At that point I guessed that what else they told me to wait for was a simple EMV CAP device (I did not realise that the Wikipedia page had a Barclays device as an example, until I looked to link it over here), and decided to not wait, instead signing up for the online banking using my Ulster Bank CAP device, which worked perfectly fine.

On the Friday I also tried installing the Barclays app on my phone. As you probably all noticed by now, looking for a new app from the Play Store is risky, particularly when banking is involved, so I wanted to get a link to it from their website. Turns out that the Barclays website includes a link to the Apple App Store page for their app, but not for the Google Play one. Instead, the Play Store badge image is not clickable. Instead the option they give you is to provide your phone number and they will send you a link to the app as a text message. When I tried doing so, I got an error message suggesting to check my connection.

The reason for the error became apparent with developer tools open: the request to send the SMS is sent to a separate app running on a different hostname. And that host has a different certificate than their main website, which at that point was expired for at least four days! Indeed, since then, the certificate has been replaced with a new one, an EV certificate signed by Entrust, rather than Symantec as they had before. I do find it slightly disconcerting that they have no monitoring on the validity of the certificates for all of their websites, as a bank. But let’s move on.

The online banking relies heavily on “PINSentry” (that is, CAP) but doing so it makes it fairly easy to set up most things, from standing orders to transfers and changes of address. Changing address to my new apartment was quite straightforward, and it all seemed good. The mobile app on the other hand was less useful at first. The main problem is that the app will refuse to do much for the first ten days, because they “set it up” for you. I assume this is a security feature to avoid someone to get access to your account and have the app execute the transactions instead of the website. Unfortunately it also means that the app is useless if your phone dies and you need to get a new one.

Speaking of the mobile app, Barclays supports Apple Pay, but they don’t support Android Pay, probably because they don’t have to. On Android, you can have a replacement app to provide NFC payment support, and so they decided to use their banking app for the payments as well. Unfortunately the one time I tried using it, it kept throwing errors, and asked me to login, with network connection. I don’t think I’ll use this again and will rather look for a bank that supports Android Pay in the future.

Up to here everything sounds peachy, right? The card arrived, it worked, although I only used it a handful times, to buy stuff at IKEA and to buy plane tickets where Revolut would push an extra £5 due to it running on the credit card circuit¹, rather than the debit card one.

Then the time came for me to buy a new computer, because of the one ““lost”” by the movers. Since Black Friday was around the corner, and with it my trip to Italy, I decided to wait for that and see if anything at all would come discounted. And indeed Crucial (Micron) had a discount on their SSDs, which is what I ended up ordering. Unfortunately, my first try to order ended up facing a Verified by Visa screen that, instead of trying to get more authentication factors for myself, just went on to tell me the transaction failed, and to check my phone for messages.

Indeed, my phone received two text messages: one telling me that a text message would be sent to confirm a transaction, and one asking me whether the transaction was intentional or not. After confirming it was me doing the transaction, I was responded to try the transaction again in a few minutes. Which I did, but even if this went through the Verified by Visa screen, PayPal refused the payment altogether. Trying to order directly through Crucial without using PayPal managed to get my order through… except it was cancelled half an hour later because Crucial could not confirm the details of the card.

At this point I tried topping up my Revolut account with the same card, and… it didn’t go well either. I tried calling them then, and they could only tell me that the problem was not theirs, and that they couldn’t even see the requests from Revolut, and they didn’t stop any other transactions, giving the fault to the vendor. The vendor of course blamed the bank, and so I got stuck in between.

Upon suggestion from Revolut on Twitter, I tried topping up by UK bank transfer. At first I got some silly “security questions” about the transfer (“Are you making this transfer to buy some goods? Is someone on the phone instructing you to make this payment?” and so on), but when it supposedly completed, I couldn’t see it in the list of transactions, and trying again would lead to a “technical problem” message. Calling the bank again has been even more frustrating because the call dropped once, and as usual the IVR asked me three times for my date of birth and never managed to recognize it. It wasn’t until I left the office, angry and disappointed, that the SMS arrived telling me to confirm if it was really me requesting the transfer…

The end result looked like Barclays put a stricter risk engine in place for Black Friday which has been causing my payments to not go through, particularly not from the office. Trying later in the evening from my apartment (which has a much more clear UK-based geolocation) allowed the orders to go through. You could say that this is for my own protection but I do find this particularly bothersome for one reason in particular: they have an app!

They could have just as easily sent a push notification to my phone to confirm or refuse the transaction, instead of requiring me to be able to receive text messages (which is not a given, as coverage is not perfect particularly in a city like London), in addition to me knowing my access code, having my bank card with me, and knowing its PIN.

At the end of the day I decided that Barclays is not the bank for me, and applied to open an account with Fineco which is Italian and appears to have Italian expats in the UK as their target market. Will keep you posted about it.

But I found out just the other day that the new virtual cards from Revolut are actually VISA Electron, rather than MasterCard. This makes a difference for many airlines as VISA Electron are often considered debit cards, due to the “Electronic Use Only” limitation. I got myself a second virtual card for that and will see how that goes next time I book a flight.
^[return]

Flameeyes's Weblog