Nothing is insurmountable but the cost of provisioning for a system that could handle so many transactions at the same time just does not make sense economically. I'd rather see my bank put its funds elsewhere than have it wasted on resources for crazy "what-if" scenarios.
Of course there is room for improvement on QoS and reusing SSL connections is a technique that can speed things up. This could compromise security somewhat which means it's use in banking web services is limited. Higher security obviously has to take preference over higher quality of service in the banking world.
I don't think that the likes of ticketmaster or amazon have yet encountered a situation where up to 1.5 million customers were all trying to log in and perform transactional operations at the exact same time, and over such an extended period. I would imagine they would experience a lower QoS too given the circumstances.
In normal circumstances only a small percentage of its customers will require to use its services simultaneously. Your demands are not realistic and I doubt you will be able to find any bank out there to guarantee the service you expect.I am not convinced that it is capable of handling even a small percentage of customers simultaneously.
Reusing an SSL connection for the same person does not constitute a weakness in security. Reusing it in other ways does.I have written in previous posts in this thread of the inherent security weakness in how the authentication phase of NR's service is behaving. They have clearly, and demonstrably, not given preference to higher security over higher quality of service.
Apples and oranges.I haven't checked for any statistics on the number of Amazon customers, and particularly the number of simultatneous customers, but I would not rule out the possibility that it does handle 1.5 million customers well. At the very least, I would be shocked if the system effectively fell apart in such circumstances, as NR's online service has.
I have already stated that I am not a fan of Ticketmaster's site, but it does handle tens of thousands of credit card transactions, typically in a short few hours. Admittedly, it can be an painful experience, but it works because they are aware that if their online system was unusable for days at a time then they are likely to be out of business.
Whatever about the others, Google's service does handle a ridiculously high load, and if you ever use their service when was the last time that you ever experienced anything worse than a slight delay in search results being returned? I am risking turning this into an ad for Google though, which is not my intention, as I am sure that Yahoo's search engine, and those of others, are more than capable of handling far far greater load than that which has NR's service falling flat on its face.
Again, the key to this difference in service quality is that some companies treat their online service as core to their business, and others don't. When a bank is selling an online account, you would expect them to treat their online service as core to that aspect of their business, but NR clearly did not.
In normal circumstances only a small percentage of its customers will require to use its services simultaneously. Your demands are not realistic and I doubt you will be able to find any bank out there to guarantee the service you expect.
Reusing an SSL connection for the same person does not constitute a weakness in security. Reusing it in other ways does.
Apples and oranges.
I never made any definition on what an acceptable SLA should be. Your expectation of an SLA that is able to satisfy all NR's customers simultaneously is absurd though.You are defining an acceptable level of service based on little or no quantifiable data, but simply on the hope that NR have done everything reasonable within their power to provide a robust service. Your choice, but certainly not mine.
I don't know the ins and outs of the security process that NR have implemented but I'm presuming that after a certain number of attempts it blocks the account completely. If it does this then it would still be in agreement with current best practises in security. If not, then you have a point as accounts could be easily bruteforced.The weakness I was referring to is the behaviour of the authentication step which prompts you to enter a "random" pair of characters from your password. If you fail to login because of a problem with the service (and perhaps under other circumstances too), the next time you attempt a login you are asked to supply the very same supposedly random characters. As the particular characters being asked for are the same (i.e. not random) each time (until you have successfully logged in), then you effectively have a 2-character password for as long as the service won't successfully log you in. That pretty much makes a nonsense of the otherwise very sensible approach of having you provide some randomised portion of your password every time you attempt to login, leading to weaker security.
To compare the technical capacity of an entity that has a side business in selling compute power (i.e. Amazons Elastic Compute Cloud) with another entity that is only in the business of banking is neither here nor there. If you can find an example of a bank that is able to deal with all it's customers logging in to make transactions at the same time then you might be on to something.Somehow I find that unconvincing as an argument. Maybe if you could elaborate you might convince me.
I never made any definition on what an acceptable SLA should be. Your expectation of an SLA that is able to satisfy all NR's customers simultaneously is absurd though.
I don't know the ins and outs of the security process that NR have implemented but I'm presuming that after a certain number of attempts it blocks the account completely. If it does this then it would still be in agreement with current best practises in security. If not, then you have a point as accounts could be easily bruteforced.
The reason that this technique you refer to as "nonsense" is considered a best practise is that it's possible that a customer may have been observed entering their account on one occasion. An attacker could keep reloading the login page until the questions that they observed randomly appear. You might need to look into upskilling your security knowledge as it doesn't sound too hot right now.
To compare the technical capacity of an entity that has a side business in selling compute power (i.e. Amazons Elastic Compute Cloud) with another entity that is only in the business of banking is neither here nor there. If you can find an example of a bank that is able to deal with all it's customers logging in to make transactions at the same time then you might be on to something.
Maybe you should actually read what I wrote properly instead of mincing your words.Hmm, you say that you don't know the ins and outs of the authentication process in use by NR (which is a well defined approach and has been in use for years, by the way), yet you describe it as "best practice" and suggest that I "upskill" my security knowledge as I seem not to understand it. You should probably have thought that through before you wrote it - telling someone that they are talking crap tends to lose it's effectiveness when you yourself admit that you don't know what you are talking about.
Maybe you should actually read what I wrote properly instead of mincing your words.
If you are constantly only getting asked for the same 2 passwords, even with a new clean session, and on different terminals, than that would be insecure. Frankly though, your writing is so bad I'm not actually sure if that describes the situation you were encountering or whether your browser is simply badly set up. Why don't you go and take it to Northern Rock as maybe they can understand your ramblings and conjecture better than I?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?