COFFEE AND DANISH HELL: National ID system cockup forces insecure Java on Danes A bungled IT upgrade has downed Denmark's universal NemID login system, forcing people to stay on an insecure version of Java if they want to carry out online banking, check their insurance, or retrieve tax return information. Problems with NemID were first reported on Tuesday, and on Thursday the NATS IT consultancy behind …
On the contrary, other governments and their suppliers will use this as value add to, say the UK, who has a more proficient and robust IT sector and who would never allow something like this to happen to them. The biggest problem is that the Denmark Govt went the cheap route. We can prevent this from ever happening to you, but it will cost more than the bottom dollar they paid.
It'll all be rubbish of course, but I can already smell the thousands of 4-color charts being printed to 'prove' it.
I thought all the real crooks were in the secret services, the tax offices and other government bodies who can already read your e-mails anyway !
[Yes the life of a civil servant can get THAT boring that they find entertainment in reading our daily electronic drivel :-)]
It always baffles me to see code written that will break from security updates of the underlying platform, especially one that has been touted as 'Write Once, Run Anywhere'. Either the developers were improperly using certain functionality or Oracle coded the patch and broke the function making the documentation/specification invalid.
Deprecated API methods are never removed from Java, so that's not the issue. The only time I've seen this is in the following scenarios:
1. The application checks for specific version strings, and refuses to run if the installed runtime is different.
2. Calls are made to a non-public API that's then removed or modified.
My money's on scenario one, as changes to the non-public API are rare between major releases. The usual explanation for the version check is that the software is certified for a specific runtime version. Great for the contractor, since they can charge again and again for certification as a new release of Java is released. Completely pointless though, as Sun (and now Oracle) go to great lengths to ensure compatibility between releases, to the point that in some cases unintended behaviour in the class library can't be fixed for backwards compatibility reasons.
I can tell you exactly what the problem is: Oracle have changed the fucking applet security model AGAIN. Exactly 18 hours after I fixed our code for the changes they made in their previous model.
They're not just moving the goalposts, they've picked them up and are legging it down the field. I and my customers are spectacularly fucked off, and my day will be spent trying to divine information from the various cagily-worded press releases, the half-complete and sometimes working bug database and the one line summaries in the changelog to figure out what the hell is going on, and stuffing largely random lines into the Jar Manifest, signing, resigning, testing, and starting again and again and again. Again.
Bastards.
I've been hit by this as well.
The original change was in JDK 7u25 was to add Permissions and Codebase Attributes to the JAR file manifest to defend agains unauthorized code repurposing. I would guess that something has changed in JDK 7u45. More information: http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/no_redeploy.html and http://www.java.com/en/download/help/trusted_expired_variations.xml.
Here in Australia, you need Java for any online transactions with the Tax Office.
How many more IT departments are there that still believe that Java is the right way to secure a transaction?
The irony is that using Java requires some technical know-how on the part of the user, either keeping it up to date, or, in this case to work around it. Those with the know-how already know that Java is a flawed solution.
I could be wrong, but I could see one plausible reason for the Java: the One-Time Password. Trust cannot be secured if it's generated server-side (black box, possible black helicopters, also potential network interception). So it has to be done client-side. Since there's no telling what OS the client's running, you need something that can run on as many as possible. That pretty much narrows it down to Java.
Unless you can propose an alternate solution for a client-side, multi-platform OTP generator capable of being run on systems with low privileges.
> Unless you can propose an alternate solution for a client-side, multi-platform OTP generator capable of being run on systems with low privileges.
Eh? A 15 second Google for NemID shows that the OTPs are actually generated in advance and sent out to you on paper. You use one each time you log into a government/banking service, then never use again. You run out, you request more.
http://multimedia.pol.dk/archive/00545/n_glekort_nemid_545025a.jpg
And anyway, there are a quite a number of ways of generating OTPs offline, without having to do anything on the client's PC. My bank has sent me an electronic OTP generator. When I log in, I use my username and password (which the bank knows) to log in, then I'm asked to generate the OTP. I enter a PIN into my Secure ID device (the bank has no record of this) to unlock, then it generates an OTP presumably based on the current time and the device's serial ID. The bank generates the same code its end and if they match, I'm in. I would presume the algorithm has been designed to reduce the chances of two secure IDs producing the same number at the same time.
But the paper's a weak link. It can be STOLEN, much as a text can be intercepted. In fact, just about ANY situation where there's at least one step between the client and the password can have the trust broken. Even if handed directly to you, what's to say someone else doesn't have a copy?
This post has been deleted by its author
Well the alternative would be every bank has different ways of you logging on, each with various security issues, each done differently, and each done by people of varying degrees of skill.
The NemID system is set up so users make an account (mostly just their social security number) and a password. Then when they log into NemID they are prompted to deliver a code matching a set of numbers. So 4452 = 452234 - which then gives you access.
If you are logging in using the correct bank page, then even if your account and password is stolen, the baddies still have to find a way to get the correct number, or they wont be able to log in.
It's not a perfect system, but it's easy enough for people to use, and secure enough that it would take quite an effort to gain access to an account. Unless you can get in the know about which numbers correspond to which for what users.
or "Broken by Design"
Who in their right mind though it a good idea to have multiple systems like this secured with a single login? As should be blatantly obvious to anyone with a functioning brain, a single flaw such as this brings the whole house of cards crashing down.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
