Good-bye NatWest, thanks for the lousy security

For many years I've banked with NatWest, since I was in my teens in-fact, and during that time I've had various different "products" with them - including business accounts.

Now, with the recent trend in issues with their security as well as a rather disappointing incident today with their fraud team, I've decided it's time to move on.  But I figured it was worth highlighting WHY I feel the need to move on from this rather old institution ... just to make the point about their lax security.

These days, everyone needs to be super vigilent to ensure their money is safe - and its not enough to trust your bank to do the job on your behalf. We are constantly told to never share your internet banking credentials, to check all cashpoints when using them with your card and even more so to never give any potentially sensitive information to anyone over the phone in fear of it being used to socially engineer. Which is why today my sense were pricked ...

Last night, around 6pm, I placed an order on Zeek - something I do pretty regularly in the everlasting bargain hunt that is life. And, as typical with NatWest and Zeek (and me ??), they blocked it ... I shrugged, and put it through with Paypal and didn't think anything more about it.

This morning, at 9:33 I received a text - purporting to be from NatWest. There's no number associated with the sent message, just a name. And in the message it gives two numbers.

Hmm - I searched the NatWest website, and didn't find this number anywhere.  In fact, on their contact us page, there is a completely different number down for this situation. 

You may receive a call or voicemail from us about your bank account or debit card, to help protect you against fraud, you can call us back on: 

UK: 0800 011 3312

What the hell, I thought, I'll give it a call. It was answered by a an AVR requesting my card number ... after duely punching it in (I personally don't figure a card number as that personal information), I was greeted by a chap who immediately challenged by to go through security. I politely declined, indicating I had no idea what this was about and suggested he called me back on my registered number on the account - he said, 'what, the one you have called on'. Interested. I called in on a withheld work number, which isn't linked to my account. Another red flag. I said no, the mobile number on the account. He agreed, and we hung up.

No call arrived.

So I messaged NatWest through the app...

Yes, you are reading that right. They hide this number intentionally. And this forms part of their security. WTF.

I challenged this, and was basically told that they felt there was nothing wrong, nor potentially dangerous, with the way they handle contact with people about potential fraud on their account - completely missing the point we are always told to NOT call unpublished numbers for our bank, nor the fact that the bank usually automates this process via text message anyway.

If the bank is willing to lead people into potentially malicious and scammy situations by using this sort of method, I want absolutely nothing to do with them - and as such, will be voting with my feet. I'd suggest anyone who is remotely concerned with their money's safety to follow too. As an aside, Barclays really do all this security lark better ...

Importing SQL Azure database to SQL Express

This one frustrated me, but I have to say, it's pretty common to get issues it seems bringing a database down from SQL Azure to the on premise version. 

If you follow the normal route of exporting the database, downloading the bacpac, then importing it you might hit this error:

TITLE: Microsoft SQL Server Management Studio
Could not import package. Warning SQL72012: The object [data] exists in the
target, but it will not be dropped even though you selected the 'Generate drop statements
for objects that are in the target database but that are not in the source' check box.
Warning SQL72012: The object [log] exists in the target, but it will not be
dropped even though you selected the 'Generate drop statements for objects that are in the
target database but that are not in the source' check box. Error SQL72014: .Net SqlClient
Data Provider: Msg 33161, Level 15, State 1, Line 1 Database master keys without password
are not supported in this version of SQL Server. Error SQL72045: Script execution error.
The executed script: CREATE MASTER KEY; (Microsoft.SqlServer.Dac)

The cause? Well in this case it's not because you are not running a current version of SQL Server (in my case, 2016 SP1), but because SQL Azure supports a Master Key with no encryption specified - to resolve this you need to run a piece of T-SQL against your SQL Azure database to set the master key password BEFORE you export the database: 


After that, export as normal and you should be able to import your database.

Office 365 - UK Data Residency deadline

Microsoft recently announced the deadline for current Office 365 user's to request relocation of their data to their UK Azure data centres.

To do this, a service administrator should login to the Office 365 portal, select Settings then Organization Profile.  Scroll down and you will find the Data Residency option box where you can now elect to have the data residing in the UK.

The deadline for requesting the move is 15th September 2017, and the move itself will apparently be completed within 24 months of the above deadline. That's a fair wait!

It should also be noted that this only applies to "Core" data that will be moved - although finding clarity on that particular topic is challenging.  More details can be found here.

Introduction to Credential Federation

There are many misconceptions and misunderstandings around how credential federation works. This section should outline the (general) practice of federation, as well as detail the transaction flows in an attempt to clarify the technical piece.

For a web application, in a traditional authentication approach you go to the webpage and are prompted by the given application to login. Your details are then checked against details they hold (hopefully securely!). However, this means that you are likely to have a different set of credentials to remember for every service that you use online. For an enterprise, this can pose a challenge not only for the users, but also the administrators when it comes to removing user access when people move on to new pastures.

Federation adds solutions to this by integrating online services with the on premise active directory (or other) identity platform.

The moving parts

Federation Identity Server: This is the server that you, as the enterprise, will deploy on your network and validate the credentials with. This server will also serve up the login prompt to your users so you can usually brand this as needed. Usually only accessible over HTTPS (for obvious reasons I’m sure).

Relying Party: This is the third party that is going to consume the claims that your Federation Identity Server generates. Upon registering, this party will give you a key to use to sign your claims with allowing it to be 100% sure that you sent the claims. You need to take great care of this key, otherwise you might as well hand over your authentication database to whomever has it (they can pretend to be anyone on this party you see).

Claims: A set of attributes that denote things like name, email address, role, etc. – pretty flexible and normally configured as needed by the relying party and generally are attributes from your authentication system. These are cryptographically signed to verify the originator. You’ll probably hear the term SAML around this particular area.

So how does all this work?

The easiest way to explain it is to describe a user’s journey logging on via a federated approach.

1. User visits the federated identity login page for the given cloud application
Sometimes this is the same login they would normally go to, and the application will “detect” they are federated when they enter their username.
2. Web app redirects them to your federated identity server’s login page
3. User logs in
4. Federated identity server validates the identity, and generates claims.
These are often embedded in a response page after login, as a hidden form which is then submitted back to the relying party application
5. User is redirected back to the relying party application where the claims are processed
6. User receives a relying party authentication token as if they had logged in locally

Common myths

Myth: Credentials are transferred to the relying party.
Truth: In most federation claims are sent to the relying party cryptographically signed by a key that is validated by the relying party. This allows it to be confident that only the federated identity server generated the claims it has received and therefore that it can trust them.

Myth: The federation identity server is safe from attack and is not exposed.
Truth: In order to be useful – i.e. contactable – the federation identity server has to be internet accessible – unless you restrict your users to login with federation from specific locations which pretty much renders it useless.

Surface Pro 4 - Impressions

For the past few weeks I've been using a Surface Pro 4 -- something I picked up just before I headed to San Francisco for Microsoft Build 2016.

Why did I opt for the Surface Pro 4 over the Surface Book? I already have a very functional laptop (an Macbook Pro actually), and I wanted a tablet that was actually a functional device (and I could handwrite on!). The Surface Pro gave me more bang for buck in this regard.

It's even powerful enough to let me play Prison Architect ;) (And, of course, run a small dev lab in HyperV)