The Daily WTF: Curious Perversions in Information Technology

2010-10-01 Reply Admin

SecTech:
The situation in today's WTF is no different - if the company knows the problem exists but refuses to fix it, the only way to force their hand is to expose the problem. A small number of people may be inconvenienced as a result but the long term benefits far outweigh the inconvenience of a few customers.

And you're not necessarily increasing inconvenience for the customer - you're just trading an unknown for a known. Once the exploit is known and published, the customer will have a much easier time getting remedied, since there's no where for the company to hide. While it's hidden, the customer can still get screwed, but now the company can play dumb.

(Which is why I think the credit card companies are so friendly when it comes to fraud - it happens so much it's part of the routine customer service.)

alegr · 2010-10-01 Reply Admin

notaware:
newegg does this.

I wonder if those places get a unique token from the CC company that replaces the actual card number. That would be more secure than keeping the number. The token that would be tied to the retailer and can't be reused for other charges.

DWalker59 · 2010-10-01 Reply Admin

Icelander:
I had a similar experience. An application I was working on was storing passwords in the clear. Now, it's not credit card data but storing passwords in the clear is just bad practice. So I wrote an encryption function and a decryption function and a function to encrypt the passwords already in the database. I tested it, checked it in, and moved onto another task.

Encryption functions are NOT something you should write yourself. There are many reasons why; many encryption functions break down not in the theory, but due to subtle holes in the implementation. See Bruce Schneier for the reasons why. Fascinating reading.

DWalker59 · 2010-10-01 Reply Admin

Jaime:
DWalker59:
Anonymous:
Henryk Plötz:
"… containing the name, address, credit-card number, verification code and expiration date …"
Correct me if I'm wrong, but isn't storing the verification code a breach of contract with your credit card clearing center and should lead to the company losing the ability to process card payments?
You're absolutely correct. Merchants are not allowed to store the CCV (verification code), even if they store the CC number itself. The CCV must be requested from the customer for every transaction and discarded after authorisation. God knows how many merchants are currently breaking this rule though, it's pretty much unenforceable unless you audit every merchant on a regular basis.

Amazon.com does not ask me for my CVV on every transaction, even though I have a credit card number stored there, which I use to buy stuff. I know that many online companies do this (including Paypal).

On the other hand, I have read some of the Visa and MasterCard merchant agreements and their data protection requirements. A local restaurant was using a software program to send credit card information to their clearinghouse, and the software was actually storing the entire card number (perhaps without the CCV) and expiration date in a database. ("Card Present" rules are different than "Card not present" rules.) Retail places that swipe credit cards are NOT supposed to store the entire card number.

The newer version of this particular software only stored the last 4 digits of the card number, which is acceptable IIRC. They finally upgraded, then they went out of business. I tried to contact them to offer to securely erase the hard drives containing their database, but I was not successful. Ugh.
Our software does card-not-present transactions, we never ask for CVV. Perhaps Amazon simply doesn't submit it on subsequent transactions. Just because they don't ask for it isn't a guarantee that they store it. The rules for these things are a bit weird. For example, if a credit card processor sends back a fail for address verification, it's your responsibility to decide whether or not to proceed with the transaction. You are reponsible for all fraud for card-not-present transactions. So, if you screw it up, it's your problem, not the bank's.

Wait... Most of what you said makes sense, but "Just because they don't ask for it isn't a guarantee that they store it" made my head explode. If they don't EVER ask for it, they can't store it. I don't remember if they ask for it on the first submission or not; maybe that's what you mean.

Still, there are very few sites that I allow to keep a CC of mine on file. Paypal and Amazon are two of them, and there is one more.

I think I was lucky that the debit card/ATM card of mine that was compromised, which resulted in money getting taken out of my checking account, did not have too many consequences such as (for example) my mortgage bouncing.

To digress, I had a friend who worked for a VERY large company (Fortune 500) where the interest on the float per day was huge. The company always put money in the account that employee paychecks were drawn on, over a period of several days after each pay period. In other words, there was not enough money to pay all employee paychecks on the first day after the paychecks were given out. (There was enough money there by about the fifth day, when almost all employees would have cashed their checks, or their deposited checks would have reached the issuing bank.)

This was in the mid 80s when actual checks were more common than they are now (direct deposits and such).

One of his paychecks that he deposited actually bounced, and then his check to his mortgage company bounced. Boy, was he pissed. He was compensated somehow; I forget the details.

Jaime · 2010-10-01 Reply Admin

DWalker59:
Jaime:
DWalker59:
Anonymous:
Henryk Plötz:
"… containing the name, address, credit-card number, verification code and expiration date …"
Correct me if I'm wrong, but isn't storing the verification code a breach of contract with your credit card clearing center and should lead to the company losing the ability to process card payments?
You're absolutely correct. Merchants are not allowed to store the CCV (verification code), even if they store the CC number itself. The CCV must be requested from the customer for every transaction and discarded after authorisation. God knows how many merchants are currently breaking this rule though, it's pretty much unenforceable unless you audit every merchant on a regular basis.

Amazon.com does not ask me for my CVV on every transaction, even though I have a credit card number stored there, which I use to buy stuff. I know that many online companies do this (including Paypal).

On the other hand, I have read some of the Visa and MasterCard merchant agreements and their data protection requirements. A local restaurant was using a software program to send credit card information to their clearinghouse, and the software was actually storing the entire card number (perhaps without the CCV) and expiration date in a database. ("Card Present" rules are different than "Card not present" rules.) Retail places that swipe credit cards are NOT supposed to store the entire card number.

The newer version of this particular software only stored the last 4 digits of the card number, which is acceptable IIRC. They finally upgraded, then they went out of business. I tried to contact them to offer to securely erase the hard drives containing their database, but I was not successful. Ugh.
Our software does card-not-present transactions, we never ask for CVV. Perhaps Amazon simply doesn't submit it on subsequent transactions. Just because they don't ask for it isn't a guarantee that they store it. The rules for these things are a bit weird. For example, if a credit card processor sends back a fail for address verification, it's your responsibility to decide whether or not to proceed with the transaction. You are reponsible for all fraud for card-not-present transactions. So, if you screw it up, it's your problem, not the bank's.

Wait... Most of what you said makes sense, but "Just because they don't ask for it isn't a guarantee that they store it" made my head explode. If they don't EVER ask for it, they can't store it. I don't remember if they ask for it on the first submission or not; maybe that's what you mean.

Yes, that's what I meant. Most likely they ask on the first charge, they are satisfied that it is you card, then they use it without submitting the CVV in the future. This workflow doesn't require storing the CVV.

DWalker59:
To digress, I had a friend who worked for a VERY large company (Fortune 500)

We're Fortune 50. We don't store credit card numbers at all. Our credit card processor keeps them and we get a surrogate number to put in our databases. Keeping cards on file is pretty trivial for us, and very safe for our customers.

2010-10-01 Reply Admin

DWalker59:
Icelander:
I had a similar experience. An application I was working on was storing passwords in the clear. Now, it's not credit card data but storing passwords in the clear is just bad practice. So I wrote an encryption function and a decryption function and a function to encrypt the passwords already in the database. I tested it, checked it in, and moved onto another task.

Encryption functions are NOT something you should write yourself. There are many reasons why; many encryption functions break down not in the theory, but due to subtle holes in the implementation. See Bruce Schneier for the reasons why. Fascinating reading.

While you're 100% right, you seem to be assuming that his encryption/decryption functions didn't just invoke PGP or some other third-party method, which is what I'd have done.

Granted, my hypothetical function wouldn't perform any encryption itself, but I may still candidly refer to it as the "encryption function," since technically it is the function where I'm encrypting the passwords.

But if you assumed correctly, and if the GP did actually write the encryption logic, well, you're right, he SHOULDN'T do that.

DWalker59 · 2010-10-01 Reply Admin

boog:
DWalker59:
Icelander:
I had a similar experience. An application I was working on was storing passwords in the clear. Now, it's not credit card data but storing passwords in the clear is just bad practice. So I wrote an encryption function and a decryption function and a function to encrypt the passwords already in the database. I tested it, checked it in, and moved onto another task.

Encryption functions are NOT something you should write yourself. There are many reasons why; many encryption functions break down not in the theory, but due to subtle holes in the implementation. See Bruce Schneier for the reasons why. Fascinating reading.
While you're 100% right, you seem to be assuming that his encryption/decryption functions didn't just invoke PGP or some other third-party method, which is what I'd have done.

Granted, my hypothetical function wouldn't perform any encryption itself, but I may still candidly refer to it as the "encryption function," since technically it is the function where I'm encrypting the passwords.

But if you assumed correctly, and if the GP did actually write the encryption logic, well, you're right, he SHOULDN'T do that.

Right, that is true. On the other hand, if you are REALLY trying to implement an encryption algorithm yourself, don't do it unless you completely understand papers that are as complex as http://www.iacr.org/archive/eurocrypt2002/23320530/cbc02_e02d.pdf.

2010-10-01 Reply Admin

DWalker59:
Icelander:
I had a similar experience. An application I was working on was storing passwords in the clear. Now, it's not credit card data but storing passwords in the clear is just bad practice. So I wrote an encryption function and a decryption function and a function to encrypt the passwords already in the database. I tested it, checked it in, and moved onto another task.

Encryption functions are NOT something you should write yourself. There are many reasons why; many encryption functions break down not in the theory, but due to subtle holes in the implementation. See Bruce Schneier for the reasons why. Fascinating reading.

Exactly what I was going to say.

If you are not a mathematician or crypto researcher type and you are writing an encryption function... you are probably doing it wrong. Use a prebuilt, verified library.

2010-10-01 Reply Admin

Sounds like she was working for ACS:Law! http://www.bbc.co.uk/news/technology-11425789

2010-10-01 Reply Admin

Yeah, and to think my company went through all that trouble to be PA-DSS and now PCI-DSS compliance certified.

If only we knew you could just store nearly-plaintext card data indefinitely!

All that PABP stuff was plainly just a waste of our time...

2010-10-01 Reply Admin

DWalker59:
Right, that is true. On the other hand, if you are REALLY trying to implement an encryption algorithm yourself, don't do it unless you completely understand papers that are as complex as http://www.iacr.org/archive/eurocrypt2002/23320530/cbc02_e02d.pdf.

As featured by Schneier on Security quite recently. :-)

Some points exemplified by this paper are a bit more subtle than just "don't touch cryptography yourself":

First, the attack described in the paper is completely independent of the actual cryptographic primitive (block cipher) being used. It's all in how this primitive is used in a larger context. So even if you refrain from coding any encryption primitives (and get them from a platform library instead) you can still be burned.

The major opportunities to shoot oneself in the foot are not in the cipher (assuming you stay away from completely idiotic things like trying to design your own), but in mistakes about modes, key management, protocols, and various other high-level brainfarts that using even a state-of-the-art crypto library will not help against unless you understand the basics of what is going on, which safety properties you get and how the components of the system work together to provide those properties. Arguably, to the extent that using an external library lulls you into thinking that you don't need to know about these things to work at the application level, you can be worse off using it.

In fact, it is easy and not particularly error-prone to implement an existing cipher primitive such as AES or Twofish. If the source is free of blatant backdoors and tests OK against test vectors from a standard or a reference implementation, it's unlikely to be a safety problem (unless you need it to work in untrusted execution environments like a smartcard that can fall into the hands of adversaries). About the only risk is circumstantial, namely that if you're coding the cipher yourself, who knows what else you're also doing yourself, including the stuff that does present footshot opportunities.

Last but not least: the fact that Vaudenay's attack works against quite a lot of respected and widely trusted frameworks. This demonstrates that using somebody else's crypto code is not a panacea. It just means that when you're shot in the foot it won't be you who pulled the trigger. On the other hand, someone who had decided to program CBC from scratch might well be immune from the Vaudenay attack, because they'd be "too stupid" to check redundant padding bytes while decrypting.

2010-10-02 Reply Admin

I guess the reasoning is that use of MS Access more or less guarantees that the data will become lost or corrupted sooner or later, so it's perfectly safe.

Kuba · 2010-10-02 Reply Admin

Matt Westwood:
We store all our clients' login data in clear. Otherwise how would we know how to log into their data to debug it?
I am sorry, I am not being ironic, I am not being facetious, I am being honest about our working practices.

I hope, though, that at least you don't agree with the practice. Every sanely designed system would allow people with proper authorizations to impersonate customers for that very purpose (with audit trails and whatnot), without having to know their password. OSS example: Zimbra does just that. No need to know user's password, in the admin console you simply click "view email" after selecting a user account. A new browser window pops up with that user's session. Easy.

2010-10-02 Reply Admin

You have an interesting definition of "hell":
Customer: "Oh hello there, is this Visa? My card details have been compromised and I now have a fraudulent charge on my bill."

Visa: "I'm sorry to hear that sir but don't worry, we will cancel your current card and issue you a new one immediately. It should take 3-5 working days to arrive. As soon as our fraud investigation department has cleared up the details, you will be credited for the fraudulent transaction."

Customer: "Sweet, cheers dude."

Visa: "Only too happy to help sir!"

This has happened to me before and the above transcript is pretty much the exact conversation I had with my card issuer. It was HELL!!! Oh wait, no it wasn't, it was a trivial inconvenience.

Assuming that you're at home, have plenty of supplies, and have nothing to do but sit there for the next week or so waiting for your card...and don't have any bills due, then that might be trivial.

For someone who's traveling a long way from home and relying on the card to pay for their hotel, car rental, etc., or someone with rent, medical, or other bills which need that money for payment, or even just someone who expects to be able to buy groceries and fill up their gas tank to commute to work for the week, maybe not so trivial.

One of many reasons why I no longer rely on debit cards or bank accounts. They have a habit of losing your money when you need it most and then requiring you to wait through weeks or months of bureaucracy while they try to find it again. And you're lucky if they don't try to charge you extra overdraft fees for losing your money and additional overdraft fees because they lost your money so you couldn't pay the overdraft fees for them losing your money...

2010-10-03 Reply Admin

whiskeyjack:
fennec:
It's true; an internship always looks good on a resume.

Except if it's with the White House, during the Clinton administration.

Depends on the position being applied for ...

Cbuttius · 2010-10-04 Reply Admin

The real WTF is that credit cards do not use Secure ID tokens to verify them. Those contain a 6-digit number that changes every minute.

You can verify your card by giving the number for the current transaction because within a minute that number will be invalid.

Of course someone with a huge database of credit card numbers could pick a random 6 digit number and try to verify a transaction on all of them with it hoping to strike lucky, so it probably needs a bit more security too, but it would certainly be a start.

2010-10-04 Reply Admin

boog:
Jeremy:
boog:

Visa: "Are you aware there is a $3000 charge on your card in Greece?" (I live in the U.S.)

Me: "Uh, yes, I've recently been there buying antiques."

Visa: "We thought s... Oh. Well, er...
Strange, that doesn't sound like what really happened.

Ah, you saw what I did there.

boog:
Jeremy:
<disclaimer> In all seriousness, no matter how easy the fraud resolution process has become, it doesn't excuse not checking with the customer first. </disclaimer>
1) Just what do you think the phone discussion was? I'd be surprised if they didn't have everything ready, just waiting for me to confirm it.

What do you think the phone discussion was? They didn't have 'everything ready' - they had already cancelled your card! Your 'confirmation' was just rubber-stamping what they'd already gone ahead and done.

boog:

In all fairness, the previous charge was that same morning at a coffee shop next to my office. It was pretty safe for them to assume the charge was fraudulent.

But does that justify them cancelling your card?

boog:

If you want to complain about CC companies, just complain about one of the many evil things they actually do. It's not necessary to rewrite a story about a good experience with them in order to make them look evil.

I'm not trying to make them look evil. I'm pleased for them that cancelling someone's card without checking first turned out to be a good experience for their customer. It makes a nice change from the whining you normally hear about that kind of behaviour.

boog:

Wonderful rewrite of my story though, M. Night Shyamalan; what a twist!

cheers!

Jaime · 2010-10-04 Reply Admin

Cbuttius:
The real WTF is that credit cards do not use Secure ID tokens to verify them. Those contain a 6-digit number that changes every minute.
You can verify your card by giving the number for the current transaction because within a minute that number will be invalid.

Of course someone with a huge database of credit card numbers could pick a random 6 digit number and try to verify a transaction on all of them with it hoping to strike lucky, so it probably needs a bit more security too, but it would certainly be a start.

We accept checks as a form of payment. Check are essentially slips of paper on which we scrawl a promise to pay in the near future. The market needs payment methods that are less than iron-clad to keep it going. If you want an assurance you'll get paid, insist on a cashier's check from a reputable bank or a wire transfer.

2010-10-04 Reply Admin

Jeremy:
boog:
1) Just what do you think the phone discussion was? I'd be surprised if they didn't have everything ready, just waiting for me to confirm it.
What do you think the phone discussion was?

Just what I indicated: confirmation. I think that much is clear from my previous comment.

Jeremy:
They didn't have 'everything ready' - they had already cancelled your card! Your 'confirmation' was just rubber-stamping what they'd already gone ahead and done.

Call me crazy, but I'm not so sure that reading an abbreviated version of the incident secondhand gives you a more accurate perspective of the events than my own firsthand experience.

Ilya Ehrenburg · 2010-10-04 Reply Admin

boog:

Jeremy:
They didn't have 'everything ready' - they had already cancelled your card! Your 'confirmation' was just rubber-stamping what they'd already gone ahead and done.
Call me crazy, but I'm not so sure that reading an abbreviated version of the incident secondhand gives you a more accurate perspective of the events than my own firsthand experience.

Visa: "We thought so. We just canceled your card, credited the suspicious charge, and issued you a new card number. Your new card has already been sent, and you should receive it in 3-4 days.

Call me crazy, but that reads pretty unambiguously like confirmation after the fact.

2010-10-04 Reply Admin

Ilya Ehrenburg:
boog:

Jeremy:
They didn't have 'everything ready' - they had already cancelled your card! Your 'confirmation' was just rubber-stamping what they'd already gone ahead and done.
Call me crazy, but I'm not so sure that reading an abbreviated version of the incident secondhand gives you a more accurate perspective of the events than my own firsthand experience.

Visa: "We thought so. We just canceled your card, credited the suspicious charge, and issued you a new card number. Your new card has already been sent, and you should receive it in 3-4 days.
Call me crazy, but that reads pretty unambiguously like confirmation after the fact.

Thanks, that'll teach me not to paraphrase.

2010-10-04 Reply Admin

Jeremy:
boog:
Jeremy:
<disclaimer> In all seriousness, no matter how easy the fraud resolution process has become, it doesn't excuse not checking with the customer first. </disclaimer>
1) Just what do you think the phone discussion was? I'd be surprised if they didn't have everything ready, just waiting for me to confirm it.
What do you think the phone discussion was? They didn't have 'everything ready' - they had already cancelled your card! Your 'confirmation' was just rubber-stamping what they'd already gone ahead and done.

No, they don't cancel a card until you tell them the charge is fraudulent. I've had several of these confirmation calls on charges that Visa was suspicious of because they fell out of the range of my normal spending patterns. Visa calls and asks whether I made a charge for $X to merchant Y on date Z. I tell them yes I did. They thank me, mark it as confirmed, and we hang up.

Now if my answer was different (as it was in the scenario posted earlier) then they would have canceled the card, initiated the replacement, and told me it was canceled and the new one was on its way.

2010-10-04 Reply Admin

Ben:
Anonymous:
Merchants are not allowed to store the CCV (verification code), even if they store the CC number itself. The CCV must be requested from the customer for every transaction and discarded after authorisation. God knows how many merchants are currently breaking this rule though, it's pretty much unenforceable unless you audit every merchant on a regular basis.
Or customers dime them out, which I'm going to start doing.

How would a customer know what they're storing? Customers generally don't have visibility to the merchant's internal records.

2010-10-04 Reply Admin

DWalker59:
Warmasta:
Credit card have NUMBERS so ROT26 jokes are just plain stupid.
Maybe you are kidding, but credit cards have numbers that can (and generally are) stored as characters. You realize that the digits from 0-9 do exist in the ASCII (and even EBCDIC) code tables, right?

But ROT13 and ROT26 refer specifically to the 26 characters of the alphabet. They have nothing to do with ASCII (or EBCDIC) encoding.

2010-10-05 Reply Admin

LB:
DWalker59:
Warmasta:
Credit card have NUMBERS so ROT26 jokes are just plain stupid.
Maybe you are kidding, but credit cards have numbers that can (and generally are) stored as characters. You realize that the digits from 0-9 do exist in the ASCII (and even EBCDIC) code tables, right?
But ROT13 and ROT26 refer specifically to the 26 characters of the alphabet. They have nothing to do with ASCII (or EBCDIC) encoding.

Now that is the real WTF! Priceless.

2010-10-06 Reply Admin

boog:
Ilya Ehrenburg:
boog:

Jeremy:
They didn't have 'everything ready' - they had already cancelled your card! Your 'confirmation' was just rubber-stamping what they'd already gone ahead and done.
Call me crazy, but I'm not so sure that reading an abbreviated version of the incident secondhand gives you a more accurate perspective of the events than my own firsthand experience.

Visa: "We thought so. We just canceled your card, credited the suspicious charge, and issued you a new card number. Your new card has already been sent, and you should receive it in 3-4 days.
Call me crazy, but that reads pretty unambiguously like confirmation after the fact.
Thanks, that'll teach me not to paraphrase.

Ah, and perhaps that'll teach me not to assume every dialogue I read on a web forum is an exact transcription of what really happened... Bloody hell, it brings out the pedant in some of us, doesn't it?

2010-10-06 Reply Admin

TRWTF is that it took me until now to get "ROT26."

2010-10-07 Reply Admin

To solve this problem for people at companies that "standarize" on encrypting with ROT13 twice, I started anonimatron: [image]

Please help me save the world. ;-)

2010-10-08 Reply Admin

LB:
Ben:
Anonymous:
Merchants are not allowed to store the CCV (verification code), even if they store the CC number itself. The CCV must be requested from the customer for every transaction and discarded after authorisation. God knows how many merchants are currently breaking this rule though, it's pretty much unenforceable unless you audit every merchant on a regular basis.
Or customers dime them out, which I'm going to start doing.
How would a customer know what they're storing? Customers generally don't have visibility to the merchant's internal records.

Pretty simple really, if they don't ask for your CCV next time you buy something off them then they must be storing it. Obviously.

2010-10-09 Reply Admin

No, they may quite simpy charge repeat purchases without the ccv. The bank will allow it - simply the merchant takes the risk on himself. And the merchant may easily judge that the customer convenience of not requiring to enter anything outweighs the risk there.

2011-02-02 Reply Admin

if it were me, i'd have run a process to turn the entire file into text comments, or encrypted it... not from a local terminal though, and added the decrypt key to the end of the file or something. if there was cooler blab 'well, i don't know what happened, maybe the security layer i added when i was doing intern work failed' go away 'nope, someone removed the security layer. the cracker was nice enough to put the decrypt key at the end of the file though, so i was able to fix it in a few seconds. emergency over, but, you should track down the person that decided to remove that security layer and cut their toes off or something'.

2011-06-16 Reply Admin

Companies don't have to get the CVVC. Charges will go through just fine without it. I'm told there's a discount on the merchant charges if it is supplied, but it's not mandatory. Amazon (or whoever) isn't necessarily storing the CVVC, they might just be eating the extra $0.25 or so per transaction.

2011-08-17 Reply Admin

Fortune 500 company, Unsecured and unencrypted database,

I'm guessing the company is Sony.

Pretty much like them as much as we know...

2012-03-06 Reply Admin

Seriously, this is the bloody problem with interns and others who think they know everything - they have no real-world experience, and they're not willing to listen. There are always politics involved in these decisions - I'm sure the implementer knew the security was missing and wanted to add it. Did the project have budget? Probably not. Did he recommend they don't go live till it was implemented? Probably. Did management listen? Guess.

I've seen this happen so many times at so many organisations that you could call it a pattern. Then some snarky intern who thinks they know best goes to management with it, and the political games and blamestorming start. Welcome to the corporate world.

2017-01-18 Reply Admin

Which the letter of the alphabet did you drop in order to add the period and the digits two and six?

If you allow those, you are going to need ROT29 :-)

Internal Standards

Leave a comment on “Internal Standards”