Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Security Privacy

A Database of Thousands of Credit Cards Was Left Exposed on the Open Internet (zdnet.com) 37

A US online pet store has exposed the details of more than 110,400 credit cards used to make purchases through its website, researchers have found. From a report on ZDNet: In a stunning show of poor security, the Austin, TX-based company FuturePets.com exposed its entire customer database, including names, postal and email addresses, phone numbers, credit card information, and plain-text passwords. Several customers that we reached out to confirmed some of their information when it was provided by ZDNet, but did not want to be named. The database was exposed because of the company's own insecure server and use of "rsync," a common protocol used for synchronizing copies of files between two different computers, which wasn't protected with a username or password.
This discussion has been archived. No new comments can be posted.

A Database of Thousands of Credit Cards Was Left Exposed on the Open Internet

Comments Filter:
  • rsync? (Score:3, Insightful)

    by Anonymous Coward on Friday April 28, 2017 @04:27PM (#54322101)

    Most of us use rsync over SSH with key auth, which means something like RSA-2048 or 4096, or ED25519 (elliptic curve crypto, about the same security as AES-128). It is not even password-based.

    So, no, it was not rsync use that left things open. It was just incompetence.

    • Re:rsync? (Score:5, Interesting)

      by DaHat ( 247651 ) on Friday April 28, 2017 @04:35PM (#54322159)

      I see your problem...

      Most of us use rsync over SSH with key auth

      Far too often, it is easy to turn off/on other features of a product which make it less secure, all in the effort to just make it work. Once that's all done, there isn't always a careful examination of what the other implications of their other fiddling is.

      I'd be very curious to which which other companies/contractors were involved in this setup, as they and their other customers should probably be thinking about a PCI security audit.

    • by mfh ( 56 )

      Incompetence or intentional.

    • by Elentar ( 168685 )

      There's one advantage to using the rsync protocol like this; you can provide file access without creating a user account on the system. Even if you secure that user account (e.g. by using an ssh key and limiting commands init, by setting the shell to /sbin/nologin, using chroots, etc) it's still an account with access on the system. Using rsync in this way is analogous to putting some files on a web server behind Basic Auth. And like using a web server, it should never be used for files that contain sensiti

    • Using ssh transport instead of the native rsync protocol, which is unencrypted, is the *right* way to do remote rsync with sensitive data. Much like tunneling http over tls is the right way to do http for sensitive data.

      You can also do the rsync network protocol bare, using a rsync:// url. That's the wrong way for sensitive data, and the way this developer chose to do it.

  • sounds very PCI-compliant. Who was their auditor? Mr Magoo?

  • ssh-copy-id wide open to the outside???

    I can see some inside account using something like that to sync to an other system but that account should not be open unless they hacked in and got some passwords from an config file. Lot's of software needs DB login info in plain text there.

  • Old story is Old (Score:5, Informative)

    by sizzlinkitty ( 1199479 ) on Friday April 28, 2017 @04:59PM (#54322277)

    MacKeeper broke this story late November 2016 - https://mackeeper.com/blog/pos... [mackeeper.com]

  • by omnichad ( 1198475 ) on Friday April 28, 2017 @05:05PM (#54322297) Homepage

    Even storing credit card data at all (instead of processor authorization tokens) is a huge red flag unless they want a mountain worth of additional compliance work.

    And then they store it unencrytped....

  • by Anonymous Coward

    Aren't there laws that require companies to protect customer data? There certainly should be.

  • It's happened so many times, lost count. How many times have credit cards been exposed to this kind of peril?
  • Well, thank goodness that's gone [slashdot.org].

As you will see, I told them, in no uncertain terms, to see Figure one. -- Dave "First Strike" Pare

Working...