There is an old British saying “you can take that to the bank”; it means that the speaker believes something to be so truthful that the bank would accept it. It is believed to go back to when a cheque could be written on anything (it was simply a statement of intent) and it could be counterfeited with ease, but if it was definitely truthful then it could be “taken to the bank”.

Password security is critically important especially in the world of finance, and you can take that to the bank!

I went to my bank today (National Westminster Bank, or Natwest to us in the UK) to exchange some leftover Norwegian Krone, the most shocking thing I witnessed was not the exchange rate (I ended up with less than I started with after just a week). You guessed it; the most shocking thing I witnessed related to password security. At first look the security of my bank is rather impressive:

• There are big bars on the doors, and the walls are about four foot thick!
• The big thick glass between the public and the teller’s money drawer (a teller is a person who works at the counter).
• You must verify your identity with your card and pin before you start a transaction/conversation with the teller.
• My online account has two levels of a password, a random username, and a third factor for creating new events (paying a new person, changing settings, etc).

Unfortunately, this all falls apart in a way that the customer doesn’t normally get to see. If it had not been for a problem on the teller’s screen I would never have known about this failing and gone away happy with my “proper English money”.

Part way through my transaction the gentleman behind the counter informed me that he “had been logged out and will have to start again”; how odd I thought. He then informed that it “happens all the time” because they all use the same password.

I presume from the sentence “we all use the same password” that they also share the same username, else it is a hell of a coincidence. When someone else in the branch (I really hope it is one username per branch and not one for the entire firm) logged into the system the teller was kicked out and had to start again.

It seems that the system in question was a “separate application” and not part of the core banking applications. From the replies on twitter to my shocked tweet (thanks to Troy Hunt’s retweet) I have been informed that it would be a major breach of banking regulations if they shared accounts for the main systems; that being said encouraging password sharing for any system is just wrong and even more so in an industry such as the financial sector.

I'm sure it isn't, and I get the impression (obviously can't see the tellers screen from my side of the glass) that it was for "another system" due to the sort of transaction I was performing. I seriously hope the core systems are different!

— melodiouscode (@melodiouscode) May 1, 2018

I would not be surprised if the account is shared simply because there is a licence fee for the third party system they are using; sadly this is something we see all too often (I have worked at firms which do this on a regular basis).

I flagged this problem up with Natwest and they quickly came back to me for details, so hopefully they will sort out the problem and password sharing will become a thing of the past. Either that or the teller in question will get told off for letting me find out (I have told them that better not happen)!

Oh banks have a lot to learn about #passwords. I was just in @NatWest_Help and the teller had to start a process again as he was logged out of the system because "we all use the same password". I feel so secure..... No not secure worried, worried is the word I meant cc @troyhunt

— melodiouscode (@melodiouscode) May 1, 2018

The header image for this post was provided by @visuals_by_fred via unsplash.com. The screaming lady image was from @gmat07 also on unsplash.com. Thank you both Gabriel and Freddie.

Read more

I spent today in a session with our external SQL Advisor; we have been working on provisioning a set of SQL Servers in Microsoft Azure. These servers will be using SQL Server TDE, which is a total database encryption system. I will not go into details of how this works, or what the setup is; however I will explain a problem we had in the hope that someone else will read this article and not spend an entire day trying to work out the cause!

Key with name ‘SOME_KEY_NAME’ does not exist in the provider or access is denied. Provider error code: 2058. (Provider Error - No explanation is available, consult EKM Provider for details)

The above error message was presented to us when we tried to create the asymmetric key for the server. According to the official set of error codes, error 2058 does not exist! What really confused us is that we had three other servers connect without a problem; those servers were created last year. The fourth problem server was only created this month; can you see where I am going with this?

It turns out that there is a bug in the February 2018 release of the SQL Server Connector for Microsoft Azure Key Vault that was released that month (version 15.0.300.96). We had used a previous release of the installed on the first three servers.

How to fix Error 2058

The Feb release contains a requirement for a new registrary key; nothing has the rights to create that key (SQL Engine, connector, or the DLLs). The, unfortunately, the workaround is to create the following registry key:

In the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft node create a key “SQL Server Cryptographic Provider”

Once you have created the key grant full permissions on the key to the account which runs the SQL Engine Service. You should now be able to access the key vaults and create your keys.

Or of course, you could do what we did, and use the old version of the installer (patching is a problem for future me).

The header image for this post was provided on unsplash.com by Thomas Kvistholt, thank you Thomas!

Read more

As most .NET developers will know there is a Path.Combine() method in System.IO which can be used to (you guessed it) combine two file paths. Unfortunately, it sucks; it sucks bad.

As you can see it functions just as you would expect in the first three lines; but it sucks on the last three. Why would Microsoft not implement a path separator check; adding or removing the separator where applicable? A very good question in my opinion; so I have my own implementation.

using System;
using System.IO;
using System.Linq;

public static class Pathy {
	public static string Combine(string path1, params string[] paths) {
		return paths.Aggregate(path1, Combine);
	}
	
	private static string Combine(string path, string path2) {
		char spliter = Path.DirectorySeparatorChar;
		
		if (path == null) {
			throw new ArgumentException("Base path can not be null", nameof(path));
		}
		
		if (path2 == null) {
			throw new ArgumentException("Sub path can not be null", nameof(path2));
		}
		
		path = path.Trim().TrimEnd(spliter);
		path += spliter;
		path += path2.Trim().TrimStart(spliter);
		
		return path;
	}
}

Pathy.Combine() takes two or more paths in the same way that Path.Combine() does and correctly merges them based on the default Path.DirecotrySeperatorChar as used by the current environment.

Feel free to use and abuse this bit of code; it is provided with no warranty or guarantees. You can also find it on  GitHub.

The header image used on this page was provided for free by Mike Enerio via unsplash.com thanks Mike!

Read more

The domain you have tried to access is currently held by me; this is a holding page. You have either seen this because the site is not currently active, or is undergoing maintanance.

Only the following sites should direct here, if you are seeing this for another site please let me know!

• https://awesome-books.co.uk
• https://chorlton.xyz

Thank you for your visit!

Read more