One of the rather annoying and weird bits of copyright legislation is that it does not just protect against copying but also making available. The second part is the tricky one, and a CJEU ruling recently muddied the waters only to be made worse by a case in Germany!
The upshot is that if a commercial web site simply links to a web site/page that contains infringing material then the linking site becomes infringing as it is making available.
What is worse is that the link itself (according the Germans) does not have to be for some profitable purpose, simply a link on an otherwise commercial site. Also, the web site operator that created the link does not even have to know the linked-to site is infringing. Indeed, they could have done all due diligence when making the link and the content of the target site has since changed, or worse, not changed but the infringement status of what is there has (a time limited licence on use of an image, maybe). The German case was a link to something covered by a creative commons licence but it turns out the linked to site did not meet all of the requirements making it an infringing site. How the hell does someone making a link check that shit, and how can web sites continue to exist if every external link on every web page needs a small team of lawyers to check it, and recheck regularly?
This is, of course, crazy, and make no sense to anyone looking at it in any technical way. It makes little sense to those looking at it from a legal viewpoint either, as far as I know.
One of the problems is that the linking site being infringing means that anyone linking to the linking site is also infringing, and so on until the whole world wide web is infringing! If it was not like that, then you do not tackle the original problem - people actually linking to where one can download dodgy copies of stuff can simply link instead to a site that then links to where you can download dodgy copies of stuff, ideally with that intermediate site being outside of EU (and this crazy legislation).
Of course, you could make a non profit site that links on to other sites, like a URL shorter, but could be simpler and just strip its domain off end of link so very noddy. Then make all external links on your site go to that non profit site that links on to the target page. That way all your links are now laundered and not infringing?
I am not sure how either of these play points out legally.
When making any sort of login system you typically used a username and password. One of the key things you should do, if at all possible, is hash the password.
This means that we do not know the password people have used! We can check a password attempt against the hash (and then forget the password), but we never store the actual password.
If the user database was to be compromised in any way the attackers would not get real passwords, and so could not use them. More importantly, given so many people re-use passwords, it does not give then the passwords people are using on other systems.
So far, so good.
In additional to passwords we are now using two factor authentication using an authenticator app that provides a new 6 digit code every 30 seconds (Timed One Time Passwords). This uses a seed that is a long random number which is stored in the app and which we have to know as well - that way we can generate the same code and check it matches. We actually generate the codes for the last few minutes and check it matches any of them.
This creates two factors - one is something you know, being the username and password, and the other is something you have being the smartphone app or authenticator device. There are, of course, issues of ensuring the two have the same seed, but using a QR code on an https page seems a good compromise.
The problem is that we have to be able to see the seed to check the code, so it is not hidden. If that seed gets out then the authenticator is compromised as someone else can always generate the same codes. So in an ideal world we do not want to be storing this seed in the clear.
The small revelation I had this morning was that we could simply encrypt the seed with the plain text password. This means that when you provide the passwords and authenticator code, we can check the password, and knowing it is right we can use it to decrypt the seed and check the code, all in one go.
This is great, and I nearly rushed off an implemented it before realising a significant number of shortcomings with this.
One big problem is lost passwords. When changing password you always have to know old and new passwords so as to decrypt the seed with the old one and re-encrypt with the new one. This is fine for a change password form, but not for any sort of lost password reset process.
Indeed, at present, we use the authenticator code to validate the reset password request that is sent by email (so working email as well as using the authenticator code as two factors). However, if the authenticator code cannot be validated without the password, you cannot do that. You either have to trust just the email working, which is not ideal, or you have to find some other validation process as well. Also, when resetting a password you have no choice but to also issue a new authenticator seed and reset up the app with that new seed.
You also cannot use the code as a validator when talking to staff as they could only check the code unless they also have the password, and we would never want to ask a customer for their password.
So this creates a trade off - transparent storage of the seed on our systems and added convenience and some extra security on password reset, or encrypted seed on our system and some much more constrained processes and less convenience.
I can see we may end up with the underlying libraries allowing both options and using for different systems as appropriate.
Isn't security fun some times :-)
P.S. Read the comments - at least one important point I had not realised.
I have to say I am slightly impressed and pleased with my son's abilities in coding today.
He has been working on tools to have transaction details from Monzo, specifically to handle money loaned and repaid. I have written a load of C code behind the scenes for him to get the transaction data and run a script of his.
The fact Monzo have an API is great for this, and the real-time nature of the web hooks is even better. They lack an "update" web hook, but all in all it is pretty impressive.
Now, what struck me as insightful is a couple of questions James asked, and importantly he asked before he hit the problem caused by them!!!
1. He realised that if he happens to be set up to track Monzo accounts for both sides (him and his girlfriend), he will see the same transaction twice, and hence record the transaction twice, once from each side. But there are scenarios where he is not tracking both sides and so only sees it once. He needs to de-dup the transactions. I am impressed he realised this, and he has managed to find a reference in the transaction which is the same on both sides (a p2p transaction id). So he can de-dup that. He even worked out that matching by amount and parties and time is a really bad idea to de-dup this stuff.
2. He also realised that he might get the two sides of a transaction concurrently and so code that checks for it existing, and if it does not, goes on to add the transaction, could happen concurrently and add both. This can be solved in many ways from locking around the transaction handling script, to table locks in SQL, to unique keys on tables. But the fact he worked out it was a risk is excellent. So many people do not understand "real time" coding and race conditions, and he spotted this as an issue, and once again did so before it happened.
I think we have 2FA sorted nicely on our accounts pages for A&A.
We have taken on board some constructive comments, and done things like "you can't set paranoid mode until you have confirmed that the app has been installed and used a code", and also not showing the QR code or seed again, once installed.
The trick to both of these was to use a different seed for codes sent by SMS than codes from the authenticator - that way we can tell if the authenticator has in fact been used and not just an SMS'd code. Obviously we did have to allow for the remote chance of code matching both seeds and ask for a new code in such cases.
I event made a video showing how to set it up!
The next step is 2FA on our control pages. But first it is worth explaining - yes, I know that really what you should do is identify a specific living individual in some way, and separately have associations of accounts or logins that they are allowed to access in various ways. The system we have does not do that, I know - we have the accounts logins and the control pages logins. The system we have also has a complex set of linkages such as dealer logins on control pages, and, of course, staff logins. Changing to a "single sign on" is a good idea, but a big step we'll tackle another day.
The plan is to use the same library and tools, and almost identical set up processes, as the accounts 2FA system. Indeed, some of the pages/scripts will simply be copied and amended for the different database structures in use on the control pages.
There is, however, one extra trick we can do, and it will be an extra button. As we have the "seed" for the 2FA on the accounts, we can simply have an option to "Copy 2FA from account" for an associated control pages login - why not? Obviously we will ask for password and a new code at the time to confirm you have the authenticator, and there is no reason to show a QR code when doing this. But this would reduce the number of authenticator entries you need installed and will be ideal for cases where it is one person handling accounts and technical issues - like most of our home customers.
This would just be an option though - customers can have separate control for accounts and technical, and have separate people and hence separate authenticators for the control pages if they want.
I hope that sounds sensible. However, I do plan to "let the dust settle" a bit, and see how the accounts 2FA works out before working on the 2FA on the control pages. Feedback welcome, as always.
As an ISP, A&A are obviously quite concerned with security. Many ISPs have had leaks, and we hope never to be among them.
But "security" is far from being an absolute. It is a battleground, and whilst some part of that is the general battle for privacy and the stupidity of UK law, the main battles we face fall in to two areas...
1. The bad guys
2. The users
New hashing algorithm
The battle with the bad guys is hard and never ending. Every step you take is a mitigating factor. We have a dedicated ops team and part of their remit is security so they are constantly finding things we should improve to be best practice, or more often beyond best practice, if we can.
Some time ago we instigated a password hashing improvement programme. At the time, the password hash competition was not complete so we went for a heavily salted SHA256 hash. However, the main change at the time was not choice of hash but choice of a system of automatic upgrade. All of the systems we use, where possible, not only use the latest preferred hash but update the hash we have when someone next successfully logs in.
This meant that at the time our accounts and control pages and several internal systems moved to that SHA256 hash very quickly. However, we know that SHA256 was not the best approach as it is a cryptographic hash and not a password hash. There are different types of hash that have different objectives, and a password hash is designed to be time and memory consuming where as a cryptographic hash is designed to be quick but impossible (for some values of impossible) to reverse.
So, having put this all in place some time ago, we recently moved the the competition winner, Argon2. This is a specifically designed password hash, so any successful login will move your hash to this.
Why is this important? Well, it relates to the risk that our database is ever compromised. Obviously we work hard to avoid that, but if it happens then the hashes will not easily be crackable to find passwords. That is the plan. Not all systems allow passwords to be held as a hash, but our various web site logons do.
But tackling the bad guys is not all technology - it is also the social engineering. The call we get at 10 past 5 from someone that is as nice as pie and visiting his parents house for his fathers funeral and does not have the details and just needs this minor change done over the phone. The bad guys are good at this shit, and we have to be vigilant but somehow also allow for the customer that in genuinely in that situation!
But that leads me on to the other battle - that with the users (aka customers).
Bear in mind some ISPs store such passwords in plain text and show to support staff!
Battling customers?
OK that sounds unfair, we should never be battling our customers, but the real battle is human behaviour. People will re-use passwords or use dumb passwords. This is why our password setting system is hard to not accept the pre-set random one we offer. We don't quite make it impossible to pick your own password, because we know of people that do run password apps that provide individual and very secure passwords to use on our system. Sadly, ultimately, we cannot tell such people from those that want to re-use a password or set to "PA55W0RD".
But even then the battle is more subtle - people will store passwords in their browser and then get hacked and passwords collected. People are inherently lazy, and we all know it. We are all the same.
So, our latest initiative is allowing two factor authentication on our accounts system web login. This is an extra step that is not possible (in theory) to store in the browser - a code that changes every 30 seconds from an app or device you have, usually a mobile phone app.
But as part of that we need to also allow people to have trusted browsers that stay logged in, or trusted browsers that do not ask for the code (usually). If we ask for the code every time people will turn off the feature. Remember, people are lazy. Security is always a compromise with convenience.
So we ended up allowing a paranoia setting. Customers can, if they wish, set so the code is needed every time, and even staff will not talk about the account unless you can quote the code over the phone (or irc, or web chat or whatever). But people can set less severe modes where the code is needed on login only if not your usual machine or a recent bad password entry.
We have decided that if you have set up 2FA then we do insist on the code on all orders, even if over the phone. But ordering is rare enough that people can cope with that, we think. The whole 2FA remains optional.
We think we have the right balance of convenience and security now on the accounts web site. Next step is our to our "control" pages. But behind the scenes we are working on more more systems to improve security all of the time.
It is published (here). It is an interesting read, so here are some initial observations...
I have been trying to focus on the bits that could impact us (A&A and FireBrick) mainly, and I am very happy to have had help from a friendly lawyer on this matter. I am the first to accept that I am not an expert on reading legislation, but getting better as the years go on.
So, some observations, in no particular order...
Can a retention order be placed on BT Wholesale to monitor A&A traffic?
We think no - surprisingly. This is because of 87(4): "A retention notice must not require an operator who controls or provides a telecommunication system (“the system operator”) to retain data which relates to the use of a telecommunications service provided by another telecommunications operator in relation to that system".
So that should mean, we think, that BT Wholesale or Openreach or BT plc as "the system operator" cannot be ordered to retain data which relates to the use of the telecommunications service provided by A&A in relation to that system. We see that as meaning BT provide PPP and we provide IP, and so BT cannot be ordered to log IP (or above), only PPP which is basically their RADIUS logs, because IP is related to what we provide via that system.
Good and bad - good is it means, in theory, if we say we have no monitoring (we don't) and we can assume BT do not, then there is no monitoring (same logic to LINX and transit providers). Bad news is that they may be more inclined to ask us to do retention as a niche ISP.
But it gets more fun - given that this now covers private as well as public telecommunications services, it is easy to say that every single one of our customers is a telecommunications operator even if only running one router to provide service to one person. So we can argue that we cannot be expected to retain data relating to our customer's use of the IP - you have to ask each and every one of them to retain data and not us.
We'll see how that plays out if ever we are asked to do retention (which we, A&A, have not been).
Can FireBrick be forced to add a back door?
We think no, thankfully. The definition of a telecommunications operator, which we thought could cover FireBrick would require that FireBrick is providing a "service", which we are not, we are providing a product, and that the FireBrick itself is a "system", which it is not, it is apparatus.
Even so, we still have standing order that if asked to back-door FireBricks then the UK company FireBrick Ltd would be dissolved.
In short, you can trust FireBrick!
Is FaceBook a telecommunications operator?
Well, this is tricky. Home office think so, apparently. An operator offers "services", and services means a service consisting of access to or facilitating making use of, a "system". A system is something allowing transmission of communications by electrical or electromagnetic energy.
So a system is wires and fibres and radio; A services provides access to that or making use of that; An operator offers a service to do that.
I think the wires, and fibres, and radio, facilitate the use of FaceBook, not the other way around. The "make use of" may be the sticking point.
I think it is badly drafted! FaceBook may want to argue on that definition. What are Internet Connection Records?
Something much hyped in the process of this becoming law, but relegated to a small part of the Act.
It is a narrow and specific definition, "In this Act “internet connection record” means communications data which may be used to identify, or assist in identifying, a telecommunications service to which a communication is transmitted by means of a telecommunication system for the purpose of obtaining access to, or running, a computer file or computer program, and comprises data generated or processed by a telecommunications operator in the process of supplying the telecommunications service to the sender of the communication (whether or not a person)."
So it is just stuff to identify the service used by the sender, nothing more. But why does this narrow definition matter?
Well, retention can cover all sorts of data, anything that is not "content", which is "meaning of the communication". And that can be way more than ICRs. It is clear that ICRs are a subset of that data.
However, requests for this data to be acquired (e.g. from retained data) can cover anything.
There are restrictions on "local authorities" getting ICRs, but as that is a subset of the data ISPs may be forced to collect. So that is a less than useful constraint. Local authorities could ask for all sorts of non ICR data an ISP was required to "retain"!
How serious is "serious crime"?
Some aspects of the acquisition of data have restrictions for "serious crime", and that covers stuff with long prison sentences. Good. But, oddly the section also covers "relevant crime" which is rather fun as it covers offences that are "by a person who is not an individual, or which involves, as an integral part of it, the sending of a communication or a breach of a person’s privacy." This means things like failing to put your company number on your letterhead (a crime by a company) is lumped in with "serious crime"!
And the irony that you can get all this data which is a huge invasion of privacy to investigate a breach of a person's privacy is not lost on me.
Can the food standards agency get browsing history?
Well there are caveats, but yes, they are in the list and not even covered by the "local authority" exception to getting ICRs.
Does this mean back-doors can be mandated?
Well, yes, to any "service" which can be ordered to maintain a capability to decrypt stuff and even notify if new services are planned to ensure they have the back-door.
But not if you do the encryption yourself, using PGP or your own apps or pen and paper! Criminals can do this and do so legally with no interference by this Act. Well done!
I am working on some new two factor authentication for our systems.
Before I even started this, I actually updated the systems we have in place for managing password hashes to move to the password competition winner Argon2. It updates the hash on next login to our various systems.
However, a big step forward would be two factor authentication where in addition to a username and a password we ask for an extra bit of information.
From various research the way to do this is using TOTP (which is a timed OTP using OATH hashing system). Basically you have an app or device that provides a code every so often, and when you log in you have to enter the current code. We are using the default of 6 digit codes created ever 30 seconds.
There are quite a few issues with this, and a scarily large number of OTP and OATH and TOTP applications available. It is a well published standard.
The challenge is getting the "seed" or "key" in to the device, or if it is a hardware device, then from the device to us. The latter is something to tackle later as most people use a mobile app these days, so we make the seed/key and it has to get in to the app.
The answer is a QR coded URI and there is a "standard" for this. It encodes the settings in a standard format with the seed/key in BASE32 which can be read by various apps including Google Authenticator. Once read, it provides a code every 30 seconds.
At our end we need to store the seed, which ultimately has to be readable. But we have hash for password and a readable OTP seed, so two factors, which is a good start. There is no real way around storing the seed in a readable format, sadly.
But it does get quite complex, and this is what I am working through now.
1. How do you make sure setting up or resetting the TOTP is safe / authenticated. Current plan is texting a code as an alternative two factor authentication before we can disclose the seed/key as a QR code. Some actions need to be properly two factor authenticated.
2. Do we allow changes of password if not already TFA, and what of lost password - is that independent?
3. What access do staff have to reset or clear the TFA system? How do we defend against social engineering whilst not locking out genuine customers? How much staff training on social engineering can we do? Ho much staff time will this take?
4. What levels of control do we offer to customers, what degrees of paranoia do we support?
5. What of ancillary systems such as ordering or the CHAOS2 API? Current plan is ordering will require the TOTP code if that is set up at all, even if normal logins not requiring as "trusted browser".
It is never as simple as it sounds when looking purely at the technical side. Systems like this extend in to social engineering!
Anyway, we are starting with staff logins, and then moving to end user logins on our various systems offering, and even recommending, two factor authentication.
P.S. Yes I waited more than 5 minutes after taking that picture so that even if you know my username and password you cannot use the code. And yes, we also protect against replay attacks on the code. P.P.S. After some feedback we now only show the QR code until the installation has been confirmed, then it is no longer shown. That means the SMS codes and the authenticator codes use different seeds so we can tell which was used (and check for a clash just in case). Thanks for the feedback, this helps security.
