Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

2010 Bug Plagues Germany

CmdrTaco posted more than 4 years ago | from the well-that-was-ten-years-late dept.

Bug 233

krou writes "According the Guardian, some 30 million chip and pin cards in Germany have been affected by a programming failure, which saw the microchips in cards unable to recognize the year change. The bug has left millions of credit and debit card users unable to withdraw money or make purchases, and has stranded many on holiday. French card manufacturer Gemalto accepted responsibility for the fault, 'which it is estimated will cost €300m (£270m) to rectify.' They claim cards in other countries made by Gemalto are unaffected."

cancel ×

233 comments

Sorry! There are no comments related to the filter you selected.

FIRST NIGGEr (0)

Anonymous Coward | more than 4 years ago | (#30681636)

OOk Ook eek eek oo-oo Ah AA!

Re:FIRST NIGGEr (0, Offtopic)

amazingxkcd (1682296) | more than 4 years ago | (#30681674)

stop trolling, you insensitive clod!

Re:FIRST NIGGEr (-1, Troll)

Anonymous Coward | more than 4 years ago | (#30682140)

I'm a troll, you insensitive clod!

Re:FIRST NIGGEr (1, Funny)

Ja'Achan (827610) | more than 4 years ago | (#30682508)

I'm a clod, you insensitive troll!

I wonder how that is compared to the loss from Y2K (4, Insightful)

mapkinase (958129) | more than 4 years ago | (#30681700)

from TOA

A French card manufacturer, Gemalto, admitted today it was to blame for the failure, which it is estimated will cost 300m (£270m) to rectify.

I wonder how does it compare to the losses from Y2K bug... I know it is hard to compare, because there was an unspecified money loss as part of unnecessary checks, difference in scale, anticipation and efforts to fix before manifestation.

I guess it hits you when you are least expecting.

Re:I wonder how that is compared to the loss from (4, Insightful)

zaydana (729943) | more than 4 years ago | (#30681876)

Moreover, it makes you wonder who much of a problem Y2K may have actually been if we hadn't of looked for all the problems and fixed them.

Chances are things like this would have only been the beginning if Y2K hadn't have been anticipated and planned for, even if we over-reacted. Maybe we should be giving some people more credit than we do...

Re:I wonder how that is compared to the loss from (4, Insightful)

Nadaka (224565) | more than 4 years ago | (#30682362)

The response for y2k was not planned for, and it was not an over reaction.

Y2k issues were known in the 80's. Had IT been allowed to respond in a timely manner, it would have cost much less, been checked more thoroughly and finished earlier. Instead they waited until the last possible moment and poured much more money into it, hiring as many developers as possible to put in a rushed hackjob and then firing them when the hack worked instead of retaining them to vet, verify and implement permanent solutions where needed. This issue is a result of the failure to react apropriately to y2k. The rushed temporary get-it-done-yesterday hacks are starting to fail.

Re:I wonder how that is compared to the loss from (1)

shentino (1139071) | more than 4 years ago | (#30683208)

I suspect it's also aggravated by a bunch of sleazy contractors taking advantage of desperate clients who know that they're about to get bit in the behind, and deciding to cheap out and do a half-assed job in the first place.

Seriously, after what caused Y2K, only a complete moron or a crook would add 2000 to a single digit in a barcode.

Re:I wonder how that is compared to the loss from (0)

Anonymous Coward | more than 4 years ago | (#30682650)

Moreover, it makes you wonder who much of a problem Y2K may have actually been if we hadn't of looked for all the problems and fixed them.

I think you mean "if we hadn't have looked", or more simply, "if we hadn't looked". The "of" you used sounds like the contraction of "have" ("'ve").

Re:I wonder how that is compared to the loss from (4, Interesting)

WinterSolstice (223271) | more than 4 years ago | (#30683078)

I was running a Y2K lab at my company from 1999 to 2000, and we found a TON of serious problems. Nearly all of our internal stuff had major issues, as well as email, phone systems, backup systems, and several operating systems.

The tests I ran went from 1998->2012 in one year increments (with full tests by all teams at each year step) and most of those problems were nailed down.

I'm guessing not all shops tested much further out than 2001 or 2002 - probably due to poor planning and lack of funds. As it was we had to cut ours back to 2012 because of budget constraints, so I can only imagine other shops did likewise.

Re:I wonder how that is compared to the loss from (-1, Flamebait)

Talderas (1212466) | more than 4 years ago | (#30682854)

May this serve as a reminder for why French goods suck.

I fart in your general direction. (1)

Duositex (620105) | more than 4 years ago | (#30681716)

It may have taken more than 50 years, but the French finally have their revenge over WWII.

Re:I fart in your general direction. (-1, Offtopic)

Anonymous Coward | more than 4 years ago | (#30681874)

Wow, the same joke gets moded down into oblivion here, and +4 funny later... Way to go, mods. Or is it the Monty Python reference ?

2010 (4, Interesting)

s31523 (926314) | more than 4 years ago | (#30681720)

Who would have thought 2010 was going to be a big deal. We just had a 2010 programming problem at work. Everything worked great in December then in January our software simulation stopped sending the correct time to our hardware. Turns out the simulation handles 2010 incorrectly. We now have to set our PC clocks to 2009 until the team gets a fix out. I bet we see more of this.

Re:2010 (2, Funny)

corbettw (214229) | more than 4 years ago | (#30682058)

Damn Mayans and their inability to correctly predict the end of the world! It came two years early!

Re:2010 (4, Interesting)

edmicman (830206) | more than 4 years ago | (#30682076)

2 weeks before the new year I found in our legacy code multiple "Y2K10" bugs. We're a health insurance company, and this is for a major national client who is sending us data with a 2-digit year format. There is code all over the place that is making assumptions about how to treat those dates, but it's faulty logic. We've fixed what we've found, but have no way of doing a complete audit so we're just going to have to fix them as issues arise. I love the clusterf*ck that is my job.

Re:2010 (1)

u8i9o0 (1057154) | more than 4 years ago | (#30682596)

Wait, 2-digit year format? If you're having problems with the transition from "09" to "10", then you'd also have problems with the transition from "2009" to "2010". A Y2K-like bug would mean that the INPUT value is incomplete, or essentially pre-truncated. What you describe is code that intentionally truncates the value itself. The client had better not get any blame for this.

Re:2010 (1)

Mr. DOS (1276020) | more than 4 years ago | (#30682924)

It sounds like the software assumes incorrect start and end dates for double-digit years; i.e., it interprets 09 as 2009 and 10 as 1910.

      --- Mr. DOS

Re:2010 (1, Interesting)

Anonymous Coward | more than 4 years ago | (#30682996)

"If you're having problems with the transition from "09" to "10", then you'd also have problems with the transition from "2009" to "2010""

Not so. Some hacks to "fix" the problem have a "pivot year". Years before that are interpreted one way, and years after are interpreted another. The full year representation does not require any of that, and would not be liable to the same error.

"The client had better not get any blame for this"

According to his/her/it's post, the client is sending the year over as two digits. That is on them, unless the company the parent poster works for required them to send it that way.

I would like to go on record predicting the year 10k problem set, by the way. When 4 digit years are no longer sufficient. I have patents on fixing this issue, so start the bank deposits now.

Re:2010 (2, Funny)

Megane (129182) | more than 4 years ago | (#30683132)

The bad news is that your patents will have expired by then. The good news is that the Y10K bug means that your patents will un-expire. So get your head jar ready, because you're gonna be RICH!

Re:2010 (4, Interesting)

guruevi (827432) | more than 4 years ago | (#30682090)

My question is, why the f*** so many systems have issues with their clocks. In just about any language (C, Java, .NET, Perl, PHP, SQL...) there are (built-in) libraries available that do time correctly. If you're unsure on how to store time, Unix epoch is just about the simplest way to store it (it's a freakin' integer), it's universally recognizable and accepted and very easy to calculate with and if you need more precision just make it a floating point number and add numbers after the comma.

I see way too many implementations where people build their own libraries to convert a string into a date format, calculate with it and back. On embedded systems it's even worse. Some hope to save some storage space and speed by building custom functions to store a time format (eg. 2010-01-07 10:50:59 pm) into an integer (201001071050591) and back simply by stripping some characters and implementing the storage part in assembler. When they decide to export to other states/countries however they now have to implement a conversion for timezones and daylight savings time and the code becomes hopelessly buggy and bloated - usually too late to fix it since they already have it out in the field. While they could've just saved time (and storage space) by just storing it as 1278024659 using an (initially) somewhat larger library.

Greetings from 2038! (4, Insightful)

fotoguzzi (230256) | more than 4 years ago | (#30682178)

Hah, hah, hah!

Re:2010 (0)

Anonymous Coward | more than 4 years ago | (#30682304)

Better make sure you use 'double', not 'float' then, or only use (shorter) time differences, otherwise you won't have more precision, just non-integers...

Re:2010 (4, Interesting)

digitig (1056110) | more than 4 years ago | (#30682388)

My question is, why the f*** so many systems have issues with their clocks. In just about any language (C, Java, .NET, Perl, PHP, SQL...) there are (built-in) libraries available that do time correctly. If you're unsure on how to store time, Unix epoch is just about the simplest way to store it (it's a freakin' integer), it's universally recognizable and accepted and very easy to calculate with and if you need more precision just make it a floating point number and add numbers after the comma.

Partly because of ignorance of the libraries, but partly because the built-in libraries simply don't do time correctly. Unix epoch? Rolls over in 2038, so it's no use for dealing with 49 or 99 year land-leases (or the 999 year lease I held on one property). I know somebody who worked on software dealing with mineral exploration rights who had just this problem: Unix epoch simply got it wrong for the timescales involved (and he wasn't allowed to use 3rd party libraries because management perceived that as a support issue). What was he to do but roll his own? And it's very much because people think it's simple, without looking at the actual issues.

Re:2010 (1)

Jah-Wren Ryel (80510) | more than 4 years ago | (#30682550)

And it's very much because people think it's simple, without looking at the actual issues.

Indeed. Time is one of the most problematic issues I've ever had to deal with in my career. There are just so many different special cases like leap years/seconds and corner cases like converting from one timezone to another in the middle of daylight savings time change in or both of those timezones. Somebody ought to write a paper, or even a book, on all the stuff you have to watch out for.

Re:2010 (1)

Hurricane78 (562437) | more than 4 years ago | (#30682800)

That is exactly where open source shines: Clone just the date/time/calendar part of the (GNU) standard library, and patch it so it works with your needs. Then either offer this back to GNU, and continue to clone every release. Or just use updates of the library, to carefully apply applicable patches to your fork of that part.

You avoid rolling your own custom solution (with all the huge traps inside date/time calculations), and you avoid having to depend on someone else (since you forked it, and can choose to ignore the original and its updates).

Sounds like a great deal to me. :)

Re:2010 (2, Insightful)

digitig (1056110) | more than 4 years ago | (#30682950)

continue to clone every release. Or just use updates of the library, to carefully apply applicable patches to your fork of that part.

Sounds like exactly the sort of maintenance issue management wanted to avoid in the case I mentioned.

Unix epoch does not have to end in 2038 (3, Insightful)

Chemisor (97276) | more than 4 years ago | (#30682892)

2038 is only the limit on 32bit platforms. On a 64bit platform time_t is 64bits, which will last "forever". We are already significantly on the way to switching to 64bit-only CPU operation, and I'm going to bet that by 2038 we'll switch completely, if only to avoid the end of time. Heck, if you could only have a working 64bit flash plugin on Linux, all Linux users would go 64bit already.

Re:2010 (2, Funny)

l0b0 (803611) | more than 4 years ago | (#30682988)

Planck units since the Big Bang is the only way! Let's see: ~5.4E-44 seconds per unit, ~1.37E10 years since the Big Bang ~= 2.53E53 decimal = 2A4359FEF2C78D94A50F53B75B35AA648000000000000 hex, which should take about 180 bits to store.

Re:2010 (2, Insightful)

Rockoon (1252108) | more than 4 years ago | (#30682460)

I think most of the time they are building their own conversions to date formats because they have to. Those standard libraries are great when the date is in a standard format, but multinationals deal with nearly every variation of date encoding known to man.

1-digit years, 2-digit years, 4-digits years, month-before-day, month-after-day, year-first, year-last, decimal-seperators, slash-seperators, dhash-seperators, space-seperators, a-mix-of-seperators, without-day-of-week, with-day-of-week, with-day-of-week-abbreviated, without-english-month, with-english-month, with-month-abbreviation, and all words in many languages.. and different variations on abbreviations..

Even if these guys leverage the standard libraries as much as they can, its still non-trivial to do it correctly. Multinationals arent dealing with data in a single format.

Re:2010 (2, Insightful)

Rufty (37223) | more than 4 years ago | (#30682856)

Premature optimization is the root of (most) evil.

Re:2010 (1)

bickerdyke (670000) | more than 4 years ago | (#30683192)

it's a freakin' integer

How would you know?

All you have is a blob of bytes. It's about how you interpret them. Even if you store Unix epoch in your Datastore: Who prevents 3rd party software to mis-interpret it as windows-timestamp? Or Bitmap?And thats what happened here. A byte wasn't interpreted as integer, but as BCD number. (or other way round) And no one noticed, as it worked well as long as 0x03 = 00000011 = (BCD)03 = 0000 0011

Re:2010 (1)

edesio (93726) | more than 4 years ago | (#30682536)

A major bank (Banco Real of Santander Group) in Brazil had a problem on New Years Day: its ATMs would not accept 2010-01-04 (Monday) as a working day. But accept current day (on 2010-01-01) as valid and then send a message stating the transaction would be schedule for 2010-01-04!

They had to Queue? (3, Funny)

HiChris! (999553) | more than 4 years ago | (#30681724)

"Although some cash machines were quickly reconfigured to override the 2010 problem, many bank customers were forced to queue to withdraw cash over the counter. Germany's economics minister, Rainer Brüderle, urged banks to 'ensure that credit and bank cards function without problem as soon as possible, or to replace them immediately'." My gosh standing in line to get money is so 1980

Re:They had to Queue? (1)

smooth wombat (796938) | more than 4 years ago | (#30681782)

My gosh standing in line to get money is so 1980

Yes, how horrible it is that for a brief moment in time, people had to revert to an older way which just works (albeit slightly more slowly).

Re:They had to Queue? (1)

Chaos Incarnate (772793) | more than 4 years ago | (#30681808)

Increasing the wait by an order of magnitude is hardly "slightly more slowly". And that ignores the additional paperwork that's required, too.

Re:They had to Queue? (0)

Anonymous Coward | more than 4 years ago | (#30681900)

It worked in the past because there were several times more bank tellers. Now it just stalls everything. This really should be obvious to anyone...

Re:They had to Queue? (-1, Troll)

Anonymous Coward | more than 4 years ago | (#30681784)

Yes, as in "wait in line" if you're British.

Re:They had to Queue? (1)

samjam (256347) | more than 4 years ago | (#30682220)

As a britisher*, I thought "wait in line" was American.

The term I'm familiar with is "queue" as in "get to the back of the queue" and "form a queue please"

While in America I heard the phrase "wait in line"

Sam

*german for british

Re:They had to Queue? (1)

Sique (173459) | more than 4 years ago | (#30682370)

Just some nitpicking: German für "as a british" is "Als Brite".

Re:They had to Queue? (1)

samjam (256347) | more than 4 years ago | (#30682472)

Thanks for that.

I was actually quoting from Commando comics (http://www.commandomag.com/) in which the Germans refer to the british as britishers; but of course that is probably the author trying to put german accent on the germans speaking english.

And thanks to your comment I learn even more:
http://en.wiktionary.org/wiki/Britisher [wiktionary.org]

Britisher is currently rumoured to originate in India!

Re:They had to Queue? (1)

judugrovee (1360599) | more than 4 years ago | (#30682602)

I think, you are right, supposing him to add a German sound to it. Maybe some related information. a british -> ein Brite british -> britisch a british man -> ein britischer Mann There you could have your "britischer"; it's the indefinite, male adjective of "britisch". Maybe in spoken language, it could appear alone. In a sentence comparable to this: "A German guy would never queue up; a british (guy) would." Ommitting the noun to avoid redundancy, the stand-alone adjective would be "britischer" in the German sentence. But it's not proper Grammar, of course.

Re:They had to Queue? (1)

samjam (256347) | more than 4 years ago | (#30682840)

Thanks for that, it is very interesting.

On a similar topic (as the word guy reminds me), in Tigger the Movie, Tigger is made to sound english (as he is) by saying something like "hey, you blokes" which is quite wrong.

A bloke is almost always somewhere else and "bloke" signifies that the identity is not of interest; "I met a bloke" "See those blokes".

Tigger should have said "Hey, you chaps" which is more intimate, or maybe "Hey, you guys"

So he used an english word and immediately identified himself (or the script-writer) as a foreign johnny.

-hmmm, maybe this puts it better:
http://www.urbandictionary.com/define.php?term=bloke [urbandictionary.com]
http://en.wikipedia.org/wiki/Bloke [wikipedia.org]

Sam

Re:They had to Queue? (1)

fotoguzzi (230256) | more than 4 years ago | (#30682646)

New Yorkers say, "wait on line." For instance, if anyone ever heard Curtis Sliwa on his national radio show, he occasionally used this phrasing. Not sure of the social/regional extent, but I have noticed it all my life from anyone with an obvious New Yawk/Fran Drescher accent.

Re:They had to Queue? (2, Insightful)

fuzzyfuzzyfungus (1223518) | more than 4 years ago | (#30681884)

The trouble is less in having to do it the old way than in having to do it the old way without notice and in an environment that has shifted toward the new way.

Back when ATMs and POS electronics were uncommon, everyone knew well in advance that they would have to go get cash in order to make purchases, and do so during banking hours. Inconvenient; but everybody knows the score and the system is set up to work that way. If things suddenly shift back, you get a whole bunch of people, many whose first warning is probably some sort of cryptic error at a payment terminal, either stuck outside of banking hours, or swarming the few bank clerks that haven't been replaced by ATMs. Substantially more inconvenient now than it was then.

Re:There are fees for using tellers at some banks (0)

Anonymous Coward | more than 4 years ago | (#30681916)

Even worse, some banks charge you a fee if you wait in line for a teller rather than use an ATM for withdraws. Hopefully they waived the fee in this case.

Re:They had to Queue? (0)

Anonymous Coward | more than 4 years ago | (#30681956)

Queue the stack jokes.

Re:They had to Queue? (0, Troll)

Rogerborg (306625) | more than 4 years ago | (#30682040)

Indeed. However, the number of actual humans available to hand out cash - and the amount of cash that they have available to hand out - are at reduced 2010 levels.

I suspect that you wouldn't be so sanguine if mommy sent you out from the basement to get cash, and you were stuck at the back of the queue and wondering if you were going to be able to withdraw enough for your next bag of weed.

Re:They had to Queue? (1)

nospam007 (722110) | more than 4 years ago | (#30683196)

many bank customers were forced to queue to withdraw cash over the counter.

Local news reported that since only the chip on the cards were wrong, you'd simple had to cover the pins with some adhesive tape to force the machine to read the magnetic strip instead.

OTOH another point of attack is now widely known to the planet.

Revenge at last (5, Funny)

egandalf (1051424) | more than 4 years ago | (#30681726)

It only took 65 years, but they finally got their revenge for those invasions. Subtle, the french are, very subtle and patient. Like mice.

Re:Revenge at last (1)

FooAtWFU (699187) | more than 4 years ago | (#30681826)

Man, they wish those invasions only cost them 300 million, inflation or no inflation.

... I'll </whoosh> myself, thank you.

Re:Revenge at last (-1, Flamebait)

elrous0 (869638) | more than 4 years ago | (#30681924)

Unfair. Mice bathe way more often.

Re:Revenge at last (0, Flamebait)

judugrovee (1360599) | more than 4 years ago | (#30682070)

65 years - you know, that's pretty fast... considering that they are french.
And regarding the subtleness, the plan is almost heroic... for a french.

Actually, I would like to have another nationality, cause right know, telling you that I'm German looks like as if I'm racist...
Understand me, people! I couldn't get money since January 1st! We are eating our shoes over here!!! It's all desperation which brings me so far! Waargh!!!

You had your revenge, please upload the Patch [wsj.com] !!!
Délivrez-nous!

"'a'a'aaa, Jaques, zey are crawling on zeir knees. 'ave you 'eard zem lamenting?"
"Bien sûr, zey are sherman."

Re:Revenge at last (1)

LSD-OBS (183415) | more than 4 years ago | (#30682156)

Taco has fixed it. We can get back on topic now. As you were.

Effected? (3, Informative)

LSD-OBS (183415) | more than 4 years ago | (#30681744)

Come on, editors.

Re:Effected? (2, Informative)

show me altoids (1183399) | more than 4 years ago | (#30681812)

This is what I came here to say. Should be "affected."

Re:Effected? (0)

Anonymous Coward | more than 4 years ago | (#30681982)

Are you sure?

http://xkcd.com/326/

Re:Effected? (2, Informative)

Jojoba86 (1496883) | more than 4 years ago | (#30681816)

All editors please consult this handy guide [theoatmeal.com] .

Re:Effected? (5, Funny)

hicks107 (1286642) | more than 4 years ago | (#30681856)

Eye was going two say the same thing. They knead to insure they are spelling things the write weigh.

Re:Effected? (0)

LSD-OBS (183415) | more than 4 years ago | (#30681906)

I no, it happen's alot around hear!

Re:Effected? (1)

Kiralan (765796) | more than 4 years ago | (#30682828)

Eye was going two say the same thing. They knead two insure they our spelling things the write weigh.

Fixed it for you :->

Re:Effected? (1)

nyctopterus (717502) | more than 4 years ago | (#30682968)

Curious, but where are you from that "are" and "our" are homophones?

Re:Effected? (1)

kazade84 (1078337) | more than 4 years ago | (#30681880)

Wait. Slashdot has editors now?

Re:Effected? (1)

LSD-OBS (183415) | more than 4 years ago | (#30681894)

I must be new here

Re:Effected? (0)

Anonymous Coward | more than 4 years ago | (#30682194)

Yes, they have "moderators" that their software calls editors. Unfortunately, the job is actually that of selecting inflammatory, wrong, or half-baked submissions and often adding some biased comments to make Microsoft look bad. It isn't actually an "editor" job where they correct spelling, grammar, clarify meaning, etc. It's more of a "if I say MS sucks I can drive more page views" type of job.

Re:Effected? (0)

Anonymous Coward | more than 4 years ago | (#30681908)

"Effected" - as in the cards work as expected. See this [slashdot.org] comment.

Re:Effected? (1)

LSD-OBS (183415) | more than 4 years ago | (#30681930)

Still completely the wrong use, sorry!

Re:Effected? (0)

Anonymous Coward | more than 4 years ago | (#30681912)

If 30 million cards were affected by the bug and have to be replaced, the production of 30 million new cards will be effected by it.

Re:Effected? (1)

jspenguin1 (883588) | more than 4 years ago | (#30681972)

The card users' rage was effected [wiktionary.org] by the bug, not the cards themselves.

Re:Effected? (1)

DoofusOfDeath (636671) | more than 4 years ago | (#30681998)

Come on, editors.

I guess it would be insensitive to mention Grammar Nazis right now...

Re:Effected? (1)

LSD-OBS (183415) | more than 4 years ago | (#30682026)

I was counting on it :)

Re:Effected? (1)

DoofusOfDeath (636671) | more than 4 years ago | (#30682080)

I was counting on it :)

So you're what... some kind of Grammar Nazi Hunter?

Re:Effected? (1)

LSD-OBS (183415) | more than 4 years ago | (#30682168)

Taco has fixed it. We can get back on topic now. As you were...

Untested software (4, Interesting)

nodan (1172027) | more than 4 years ago | (#30681800)

Again, it's surprising that such an obvious software bug makes it into the real world. You really can never trust untested software at all. What disturbs me most are the proposed "solutions": the companies issuing the cards try to avoid the exchange of the cards by all means due to the costs involved. However, that comes at the cost of sacrificing the security gained by the introduction of the now ill-functioning chip. What has been mentioned as well was updating the software on the card at the banking terminal - I'm surprised that this is possible at all. Essentially, that opens another huge security gap (which might have been there for a long time but went unnoticed so far).

Remind me of another story... (5, Interesting)

langelgjm (860756) | more than 4 years ago | (#30681984)

Reminds me of a story I mention every so often. When I was an undergrad, I along with a few other enterprising students discovered that our university ID cards stored our social security numbers in the clear on the magnetic stripe. We eventually brought this to the attention of the school, who rushed to find a solution. They needed a unique identifier that was also not important information. They quickly settled on using our "university ID numbers" - arbitrary numbers whose value had no importance to the individual, and they reissued cards to the entire university.

A few weeks after they finished reissuing cards, one of us discovered that the "university ID number" was a primary key in the school's LDAP database. By using a directory browser, you could look up any student, staff, or faculty member by name, and obtain their university ID number. Since this was the number on their ID card, and their ID card controlled access to buildings, labs, etc., it was trivial to obtain access privileges to pretty much anywhere on campus. Want to make it look like the president of the university broke into the nuclear reactor? Look him up, write his ID number to a magnetic stripe card (we had built the hardware to do this, as well as to "fake" cards, which allowed us to simple type in numbers and generate signals, without actually making a card), and have at it.

Again, it was brought to the attention of the university. After a failed attempt to begin disciplinary action against one of us, they recalled everyone's cards and wrote new, presumably pseudo-random identifiers to them that were not publicly accessible.

Moral of the story? In your rush to fix one problem, make sure you don't create an even bigger one.

Re:Remind me of another story... (1)

sznupi (719324) | more than 4 years ago | (#30682580)

You had a nuclear reactor at your university?

Re:Remind me of another story... (1)

Xiterion (809456) | more than 4 years ago | (#30682648)

How else would you study nuclear reactor physics ;) But really, they are a bit more common than you might think. One particularly fun design is the TRIGA [wikipedia.org] design.

Re:Remind me of another story... (0)

Anonymous Coward | more than 4 years ago | (#30682928)

I'm not the other poster, but my school did. I stood in the old reactor room, where the core once was.
http://en.wikipedia.org/wiki/Iowa_State_University
"1959 10-KW, 150-ton nuclear teaching reactor is built. Reactor decommissioned and removed in 2000.[30]"
http://www.encyclopedia.com/doc/1P1-24533197.html

Re:Remind me of another story... (2, Insightful)

noidentity (188756) | more than 4 years ago | (#30682700)

Moral of the story? In your rush to fix one problem, make sure you don't create an even bigger one.

Indeed. When you find a problem and develop a fix, you are faced with a choice: continue using the old system with mostly known problems and possibly known workarounds, or use the patched system that has one of the known problems fixed, but might have new unknown problems, possibly more severe than the old known problem, and possibly without any workarounds.

Re:Remind me of another story... (1)

NevarMore (248971) | more than 4 years ago | (#30682970)

No the moral is if you're a university you have access to a large number of people who are clever, smart, bored, and willing to do normally expensive work for free.

Kudos for pointing out the bug. It just always baffles me why universities don't do things like using their students as cheap labor while giving them real-world examples of work in their chosen fields or using professors as consultants and advisors from time to time.

Re:Untested software (1)

corbettw (214229) | more than 4 years ago | (#30682100)

What has been mentioned as well was updating the software on the card at the banking terminal - I'm surprised that this is possible at all. Essentially, that opens another huge security gap (which might have been there for a long time but went unnoticed so far).

Since you need the card itself and the PIN with that card to update it, it's not really insecure. And having the ability to change software and/or PINs without mailing things all over the place is a pretty reasonable (and handy) ability. The alternative would be for customers to mail in their cards and wait for them to be sent back weeks later; or have two cards that can access your account at the same time, and then depend on the customer to dispose of the old card properly. Those scenarios are much more prone to error than what they're doing in this case.

Re:Untested software (3, Informative)

owlstead (636356) | more than 4 years ago | (#30682114)

Essentially, that opens another huge security gap (which might have been there for a long time but went unnoticed so far).

It does not necessarily open up a "huge security gap", that's sensationalism. It does add significant "surface" to attack.

GlobalPlatform cards (used by Visa/Mastercard) have always contained methods to update the Java Card (or other OS) applications on the card. Of course, this requires either signed code or a master key set. One expects this interface to be well tested and certified - and normally they are.

Normally bank cards (and ID cards/passports) don't get updated in the field. I would not be surprised when upgrading the cards would meet serious problems.

Re:Untested software (2, Insightful)

rickb928 (945187) | more than 4 years ago | (#30682432)

Believe me, they they are tested. I know. But they are not always tested well.

- The EMV (Euro MasterCard & Visa, also called chip & pin) specs are complex to say the least. It took 6 months for one team I know of to get to the point that the spec writerd admitted they did not know how it actually worked, and to admit that the actual data did not match the specs. They rewrote the spec based on actual data. Later, the 'controlling authorities' updated their specs to match our results. As if anyone ever really know how it worked. Kinda like taking your new car to a mechanic, having him change the oil, and he says 'gee, this doesn't look like the oil drain to me, but the manual says so. Just let me check'. And sure enough, the manual is illustrating the radiator draincock. Nice. And the car manufacturer is arguing with you that you're wrong, even when you send them a video of coolant coming out of the so-called 'oil drain plug'. Next year, they send you a new page for the manual. Your video is the source of the new pictures. Thanks, guys. You made this, and you got it that wrong?

- Covering the connectors will force the reader to take the stripe if it can, and many do. This is also a scam by some criminals, where they cover the terminals in the reader and force the stripes for all purchases - and snarf your data. These usually don't last long, as this is a characteristic of either a failed terminal or fraud, and someone will be sending a new terminal out to the POS. If they do it again, they will send a body also. Third time usually results in sanctions. Gas stations and small restaurants are favorites for this, but large retailers also get hit of someone can slip in a doctored terminal - usually after stealing one earlier. Mongrel terminals are usually caught pretty quickly, so go in late at night, distract the staff, nick it, fix it up in your car, come right back, and get it back in before anyone notices. Target here in the U.S. got hit by this. So far, no reports from Europe.

Chip & pin is not yet common in the U.S., and I'm not looking forward to it. In England, disputes over unauthorized charges with chip & pin almost always result in the bank ignoring the customer's pleas, and very often result in discovery later that there was a breach elsewhere in the system, like a pin pad. Many a sad tale of widows wiped out, and only after much pain is the truth found. The banks and all are hanging on to chip & pin as the 'final solution' to card fraud. Fat chance.

Re:Untested software (1)

viralMeme (1461143) | more than 4 years ago | (#30682904)

> Believe me, they they are tested. I know. But they are not always tested well .. They rewrote the spec based on actual data. Later, the 'controlling authorities' updated their specs to match our results ..

Do you have any reliable third party citations for this ?

Re:Untested software (1)

nbert (785663) | more than 4 years ago | (#30683156)

Covering the connectors will force the reader to take the stripe if it can, and many do.

That's exactly how many retailers in Germany currently deal with the situation. If the customer's card doesn't work they just put some sticky tape on it. The banks affected have also modified their ATMs to fall back to stripe-mode in case the chip has the bug. Of course that is just a workaround, because this "fix" doesn't work internationally.

Exciting news! (0)

Anonymous Coward | more than 4 years ago | (#30681846)

France makes German credit cards. The cards blow up.

Germany makes French cars. I wonder what will happen?

DUN DUN DUUHH......

And by that I mean RAT-A-TAT-A-TAT

Easy solution . . . (2, Informative)

PolygamousRanchKid (1290638) | more than 4 years ago | (#30681980)

. . . use the magnetic strip.

I just saw a clip on a German news channel showing a chick covering the chip on her card with a piece of clear adhesive tape. Apparently this forces a dual card reader to use the strip. But I wasn't listening, so I'm working, you know.

Re:Easy solution . . . (2, Informative)

Anonymous Coward | more than 4 years ago | (#30682102)

This "solution" has already clogged up several ATMs: the adhesive tape gets stuck inside the machine and blocks the reader, rendering it unusable even for those customers who have an unaffected card. Thank you very much. (Remember that ATMs are designed to prevent manipulated cards from being used, so tolerances are tight. The increased thickness could be something more sinister than tape.)

Re:Easy solution . . . (1)

PolygamousRanchKid (1290638) | more than 4 years ago | (#30682186)

Oh, well. That's brilliant advice for you. At least my chip had no problems today. Being that they showed the tape thingie on N-TV, I wonder how many more machines will be clogged by the end of the day?

2-digit years (1)

Lord Bitman (95493) | more than 4 years ago | (#30682004)

This is just an "Up yours" to everyone who, after Y2K, decided "But now we won't have to worry about 4 digit years for another hundred years, so let's just use two digit years. What could be the harm?"

How big is a country factory? (3, Funny)

Anonymous Coward | more than 4 years ago | (#30682188)

They claim cards in other countries made by Gemalto are unaffected.

Which countries were made by Gemalto?

Re:How big is a country factory? (1, Funny)

Anonymous Coward | more than 4 years ago | (#30682912)

They should hire Slartibartfast, I hear he has experience with fjords.

This won't be fixed quickly... (4, Funny)

MiniMike (234881) | more than 4 years ago | (#30682206)

Gemalto accepted responsibility for the fault, 'which it is estimated will cost €300m (£270m) to rectify.'

I hope that money isn't in a German bank...

Understandable really (0, Flamebait)

Chrisq (894406) | more than 4 years ago | (#30682346)

I mean, who in the year 2000 could have predicted that a one day the important digit would roll over from 0, 1, 2, ... 9, and back to 0 again? Especially when you are so busy eating cheese and contemplating surrender.

Re:Understandable really (1)

thht (1473001) | more than 4 years ago | (#30682826)

I am german and i don't understand the (US-)american hate against the french?! Apparently the propaganda from US-Networks like FOX-News does an excellent job.

Re:Understandable really (1)

nyctopterus (717502) | more than 4 years ago | (#30683048)

Jeez, enough with the stupid surrender monkey shit. Honestly.

Great day for Skimmers (1)

mseeger (40923) | more than 4 years ago | (#30682352)

The problem lies in the advanced security mechanisms (EMV chip). The fix (currently) is to disable advanced security features (either by disabling the chip by taping it or in POS device). I can already hear the Skimmers jubilating. They will profit greatly...
Another problem will be that a lot of people will become wary of security features.

Security problem (0)

Anonymous Coward | more than 4 years ago | (#30682522)

I hear people going on about how using the magnet strip is horrible and a security problem. But I don't get it.

People say, the bad guys can easily copy the magnet strip, but not the chip, so taping over the chip is insecure, since it forces use of the insecure magnet strip. Now, what's to stop the bad guys from just copying the magnet strip anyway? ATMs and other card readers seem to work just fine with chipless cards, so having no secure chip on the card should be no problem for them.

Could anybody explain?

Suppression of costs via minimizing testing. (1)

master_p (608214) | more than 4 years ago | (#30682806)

I don't know the exact nature of the bug, but I know that in the current economic crisis, managers first and foremost look for minimizing costs. This has laid to reductions in personnel, and ultimately in testing problems: not enough people to test the software and the people that are assigned the testing job are not experienced enough to do it properly.

I experienced this personally: I worked all throughout 2009 on a project that should have been ended by the end of 2008, because the contractor has laid off several people and they were unable to fully come out with a good specification and testing of their system. Most of the errors became apparent through the testing done by us, the subcontractor. The contractor was French, by the way.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>