Stories
Slash Boxes
Comments

SoylentNews is people

posted by cmn32480 on Monday July 20 2015, @05:49PM   Printer-friendly
from the cheaters-never-prosper dept.

KrebsonSecurity is reporting that the online "cheating" site AshleyMadison.com (and other sites run by the Avid Life Media group) has been hacked with user information compromised by a group called the Impact Team.

The group is threatening to release all data online as a result of alleged lies the ALM group told members unless the sites are entirely shut down.

"Full Delete netted ALM $1.7mm in revenue in 2014. It's also a complete lie," the hacking group wrote. "Users almost always pay with credit card; their purchase details are not removed as promised, and include real name and address, which is of course the most important information the users want removed."

AshleyMadison.com does offer a $20 "Full Delete" option for a users profile, as detailed in this ArsTechnica article from 2014. Obviously, this "Full Delete" is now useless, as the information is already (allegedly) in the hands of the hackers.

Is this a case of altruistic hacking or a possible case of revenge?


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by tibman on Monday July 20 2015, @06:20PM

    by tibman (134) Subscriber Badge on Monday July 20 2015, @06:20PM (#211500)

    DBAs fear the ON DELETE CASCADE [wikipedia.org]. Just let it happen.. let all the data go free..

    It would help if they didn't design every table with at least two foreign keys to the "users" table. LastUpdatedBy, CreatedBy, LastModifiedBy, LastViewedBy, and so on. You try to delete a user and half of the entire system would be wiped out.

    --
    SN won't survive on lurkers alone. Write comments.
    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 2) by mtrycz on Monday July 20 2015, @07:59PM

    by mtrycz (60) on Monday July 20 2015, @07:59PM (#211547)

    Make a logical flag for "deleted" and zero out all account details/posts/events/conversations/whatever for the desired outcome.

    It's not rocket science.

    --
    In capitalist America, ads view YOU!
    • (Score: 2) by tibman on Monday July 20 2015, @10:17PM

      by tibman (134) Subscriber Badge on Monday July 20 2015, @10:17PM (#211621)

      That is not a better solution because you'll end up with completely useless data still tied up with useful data. You have basically proposed a cascade delete except the data is not actually deleted but set to null or some sane default. You'll probably have odd side effects where validation mechanisms or other business rules will have to ignore these zero'd records as they move through the system. The one big part where this fails is the primary keys for each of these zero'd records still exist. If anyone could associate a user with any key then that could still be used to see who they talked to and when. If anyone quoted your name, for example, that quote would still exist and expose your deleted account. That deleted account still has "meta data" because it is connected to other people's data. Adding a bit flag is the is the easiest solution, but not a good one in this case.

      I would agree with you if your solution was for a system that just deactivated accounts and left the details in place. Other people interacting with the system could still see your name and usage history. But this is supposed to be a complete removal with no trace.

      --
      SN won't survive on lurkers alone. Write comments.
  • (Score: 2) by Hartree on Monday July 20 2015, @10:11PM

    by Hartree (195) on Monday July 20 2015, @10:11PM (#211618)

    "DBAs fear the ON DELETE CASCADE"

    Real DBAs have duplexed redo logs with archiving (or the equivalent point in time recovery capability), which greatly reduces the fear.

    What they really fear is slowly seeding errors into the data over time so that a considerable number of backups as well as the current database are suspect.