• elliptic (unregistered)

    This comment has been standardised by Corporate.

  • Ouch! (unregistered)

    Oh well, I guess it works, and by the "If it ain't broke, don't fix it" rule, they did the right thing.

  • (cs)

    And that was a fortune 500 company? Well, just goes to show that stupidity resides at all levels.

  • (cs)
    Remy:
    All of it was protected using the doubly safe ROT26 encryption.

    The narrator in my head said this without a hint of sarcasm.

  • pabraham (unregistered)

    sechma?

    No it's not my captcha.

  • Mike (unregistered)

    It's fun to realize that every rule about securing customer data has been born from a breach somewhere. The entire credit card and financial industries have grown by the trial-and-error method.

    It's a miracle we've been as successful as we have. It's not too late to invest by stuffing your money into a mattress.

  • SR (unregistered) in reply to Ouch!
    Ouch!:
    Oh well, I guess it works, and by the "If it ain't broke, don't fix it" rule, they did the right thing.

    It's a nice day here. I'll assume you're being sarcastic.

  • Rottweiler (unregistered)

    The rest of the comment has been rot26 encrypted and no one can read it:

    "Jeff cannot read this database entry"

  • Ouch! (unregistered) in reply to SR
    SR:
    Ouch!:
    Oh well, I guess it works, and by the "If it ain't broke, don't fix it" rule, they did the right thing.

    It's a nice day here. I'll assume you're being sarcastic.

    No way. I'm totally serious. Always.

  • Death (unregistered)

    That stash of credit-card numbers is someones retirement insurance:P. Until they are shamed by a major data leak, the policy is unlikely to change.

  • Worse Than Jail (unregistered)

    Really. Someone should be in prison for this.

    Inexcusable.

  • Daniel (unregistered)

    I worked at a major auction house that kept customer information (passwords and credit card numbers) in plaintext on a mssql database that anyone could access.

  • (cs)

    A company I worked for sent out a survey. The survey asked for your email address and other personal info, so that they could contact you, as there was a prize for a few lucky survey respondents.
    The survey stated that was only reason for collecting that information, and would be used for no other purpose.

    So, what do they do? They email the results out to everyone in the company, complete with all the personal info.

    On the plus side, after this was pointed out, the next update had the fields removed.

    Granted, not nearly as bad as credit card information.

  • David (unregistered)

    This sentence was originally encrypted using ROT26. If you can read it, you have successfully decrypted it.

  • Anonymous (unregistered)

    Sometimes it's not enough to simply highlight the security flaw - it requires a practical lesson to reinforce the point. Several thousand customer CC numbers turning up on P2P should do the trick, for example. Let's see how long the flaw remains unpatched after that.

    But cover your tracks kids, us software developer types are too fragile for prison.

  • Skippy (unregistered)

    This comment has been ROT26 encrypted 3 times for triple the security.

  • Sergey (unregistered) in reply to amischiefr

    I guess you haven't ever been to the Fortune 500 companies. The Fortune 500 companies set the standards of stupidity.

  • a thief (unregistered)

    mmm free credit cards... Which company is that? O:)

  • (cs) in reply to frits

    lol I had to look up ROT26. Having never heard of it I assumed it was a real encryption method and I was confused about why the story mentioned storing data in plaintext later.

  • Bob (unregistered) in reply to pabraham
    pabraham:
    sechma?

    I noticed that, too. I think it is a misspelling of "smegma".

  • PCI DSS (unregistered)

    That's why we need PCI DSS.

  • Anonymous (unregistered)

    You can't read this so don't even try. No human can defeat the complexity of double ROT13 encoding. Why are you still here? It's not going to happen, just give it up. I'm so confident in this encryption I don't even mind telling you that my password is hunter2.

  • (cs) in reply to David
    David:
    This sentence was originally encrypted using ROT26. If you can read it, you have successfully decrypted it.

    I discovered a shortcut for ROT26. Because there are 26 letters, -1 is equivalent to 25. Now, using this we can convert the entire sentence (by subtracting 1) to:

    "SghrrdmsdmbdvrnqhfhmkkxdmbqxosdctrhmfQNS15-Hexntbmqdchs+xntg`udrtbbdrretkkxcdbqxosdchs-"

    Now from here, we just add one to each character again, and voilà:

    "This sentence was originally encrypted using ROT26. If you can read it, you have successfully decrypted it."

  • no name (unregistered) in reply to Daniel

    Oooh, I've just worked out who you are...

  • Charles Duffy (unregistered)

    At a Fortune 500? Oy.

    The Fortune 50 I recently left had a lot of things messed up, but they had lots and lots of policies about not using production data in dev. In the employee handbook. And the mandatory ethics training. As firing offenses.

  • GW (unregistered)

    Personally, I'd use triple ROT26 encoding.

  • Piedone (unregistered)

    SPOLIER ALERT

    Just double click ROT26. Oh dear.

  • (cs) in reply to GW
    GW:
    Personally, I'd use triple ROT26 encoding.
    What a waste. ROT13 is almost as secure as ROT26 but takes only half the time. Use sixfold ROT13 for more security with the same effort.
  • Henryk Plötz (unregistered)

    "… 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?

  • Larry (unregistered) in reply to Henryk Plötz
    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 not wrong and no correction is required.

  • Anonymous (unregistered) in reply to Henryk Plötz
    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.

  • Polar Bear (unregistered)

    ALL YOUR COMMENTS ARE BELONG TO US.

  • me (unregistered) in reply to amischiefr
    amischiefr:
    And that was a fortune 500 company? Well, just goes to show that stupidity resides at all levels.
    Even worse -- in Fortune 500 companies stupidity runs rampant like mold in a bag of wet bread, because there's so many layers to insulate it. I've worked for 4 huge companies and 1 tiny one (30 employees). Only the tiny company had competent developers and competent management.
  • by (unregistered) in reply to David
    David:
    This sentence was originally encrypted using ROT26. If you can read it, you have successfully decrypted it.
    Next time you should use Triple-ROT26, it's three times as secure. 'Oppeto'
  • Joe citizen (unregistered)

    Your data is only as safe as the idiots you trust it with. Good thing we trust the government with our data

  • Rogier (unregistered)

    Is Jeff in the database?

    Send him a cake with the text: "The database needs encryption", paid for with his own credit card.

  • QHS (unregistered) in reply to Anonymous
    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.
    As someone who's had to go through all the PA-DSS bullshit, I find this story particularly annoying.

  • (cs) in reply to Piedone
    Piedone:
    SPOLIER ALERT

    Just double click ROT26. Oh dear.

    Oh dear, indeed. I tried that, and now I hate you.

    Oh, and it's a SPOILER alert. I don't want things that are more spoly.

  • Leo (unregistered)

    Ah, so you think you've decrypted ROT26. The joke is on you, as I've already upgraded all my encryption to ROT52.

  • anonymous (unregistered) in reply to Steve The Cynic
    Steve The Cynic:
    Piedone:
    SPOLIER ALERT

    Just double click ROT26. Oh dear.

    Oh dear, indeed. I tried that, and now I hate you.

    Oh, and it's a SPOILER alert. I don't want things that are more spoly.

    Remy!

  • (cs) in reply to Steve The Cynic
    Steve The Cynic:
    Piedone:
    SPOLIER ALERT

    Just double click ROT26. Oh dear.

    Oh dear, indeed. I tried that, and now I hate you.

    But, to be fair, he warned you that clicking would spoil (your day).
  • CC Compliance (unregistered) in reply to QHS
    QHS:
    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.
    As someone who's had to go through all the PA-DSS bullshit, I find this story particularly annoying.

    I'll second that. The code changes necessary to lock it all down in production, scrub it all clean for dev/test systems, plus making the output from Java's crypto package make sense to Microsoft Dynamics ... it really sucks to hear about other companies storing credit cards in plaintext.

    Also, I'd like to know which Fortune 500 company that was, so I can always pay them with a money order.

  • Warmasta (unregistered)

    Credit card have NUMBERS so ROT26 jokes are just plain stupid.

  • (cs)

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

  • (cs) in reply to Ouch!
    Ouch!:
    Oh well, I guess it works, and by the "If it ain't broke, don't fix it" rule, they did the right thing.

    But it was broken. You simply do not store credit card information in the clear. And that's just for starters since IIRC, they aren't supposed to store credit card verifications codes at all.

    running code != working code

  • your name (unregistered) in reply to Warmasta
    Warmasta:
    Credit card have NUMBERS so ROT26 jokes are just plain stupid.
    Fine we'll use ROT10 instead. ;-)
  • (cs) in reply to Warmasta
    Warmasta:
    Credit card have NUMBERS so ROT26 jokes are just plain stupid.

    Yeah, but convert-to-ASCII-ROT128 jokes aren't funny.

  • Eaten by a Grue (unregistered) in reply to Anonymous
    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.

    They also aren't allows to store CC numbers in the clear. Someone should be sued into the ground for this, as this is the kind of thing that PCI standards were created to prevent.

    CAPTCHA: luctus - Well, I hope I shed some light on that.

  • whiskeyjack (unregistered) in reply to fennec
    fennec:
    It's true; an internship always looks good on a resume.

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

  • (cs) in reply to Charles Duffy
    Charles Duffy:
    At a Fortune 500? Oy.

    The Fortune 50 I recently left had a lot of things messed up, but they had lots and lots of policies about not using production data in dev. In the employee handbook. And the mandatory ethics training. As firing offenses.

    And encryption for critical personal data. I currently work at F500 company working on busting into the Fortune 50; and if I built something that stored personal customer data unencrypted and unsecured, I'd be fired faster than you can say "and don't ask us for a reference". Mainly because that would mean that I'd have deployed an application that didn't follow the design documents that I'd submitted for approval in quadruplicate to corporate Information Security, since they'd never in a billion years have approved a design like that. Heck, even good designs can take a fair fraction of that time to get approved.

Leave a comment on “Internal Standards”

Log In or post as a guest

Replying to comment #323710:

Log Out

« Return to Article