Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
Security IT

File-hosting Sites Not a Safe Haven For Private Data 134

An anonymous reader tips a story at the Register, according to which "Academic researchers say they've uncovered weaknesses in dozens of the most popular file hosting sites that allow people to gain unauthorized access to data that's supposed to be available only to those selected by the user."
This discussion has been archived. No new comments can be posted.

File-hosting Sites Not a Safe Haven For Private Data

Comments Filter:
  • by Deathlizard ( 115856 ) on Sunday May 08, 2011 @07:52PM (#36067230) Homepage Journal

    Just another reason why you should be using file encryption such as Truecrypt to encrypt everything personal.

    Even if it's on your own hard drive. You're only one rootkit away from giving it away to the world.

  • by Lose ( 1901896 ) on Sunday May 08, 2011 @07:52PM (#36067232)
    That link I posted to a rar full of my favorite pr0n pics on /b/ is easy pickings to thousands of other online users? No wai!

    I mean, I had no idea most people who used quick upload services like imgur, rapidshare, and mediafire uploaded most of their files with any implied expectancy of privacy. But boy was I wrong!
  • by x*yy*x ( 2058140 ) on Sunday May 08, 2011 @08:06PM (#36067318)
    Crypting your data won't save it from rootkit...
  • by sco08y ( 615665 ) on Sunday May 08, 2011 @08:07PM (#36067336)

    “These services adopt a security-through-obscurity mechanism where a user can access the uploaded files only by knowing the correct download URIs,” the researchers wrote in a paper presented at the most recent USENIX Workshop on Large-Scale Exploits and Emergent Threats.

    Hey, guess how passwords work? They're hard to guess. How do biometrics work? Your fingerprints are hard to replicate. How do keycards work? It's hard to guess whatever code is stored in it. All security ultimately comes down to some token that is "obscure."

    All security is through obscurity. If these sites are being accessed when they shouldn't, it means that there's an information leak, that is, the owners think (or claim) that it is far more obscure than it really is.

  • by Anonymous Coward on Sunday May 08, 2011 @08:42PM (#36067532)

    The worst people are those who suggest that certificates or keys are somehow different and better than passwords.

    They seem incapable of realizing that keys, like those often used to allow for SSH logins without using passwords, are merely lengthy passwords that are often stored in files. They don't understand that if the key is compromised, it's no different than a password being compromised.

  • Wrong. (Score:2, Insightful)

    by Anonymous Coward on Sunday May 08, 2011 @09:06PM (#36067660)

    It is safer and better.

    In a contest of brute force, SSH keys are exponentially superior to passwords. You're not going to get passwords to have the same resistance. Period.

    Not to mention, keyed access removes a great deal of moronic IT bullshit regarding password policies - you know, the policies that lead to weak passwords, lead to users actively subverting those policies ("Fuck this monthly change shit, I'm using p4ssword02. And next month, I'll use p4ssword03.", et cetera.

  • Comment removed (Score:5, Insightful)

    by account_deleted ( 4530225 ) on Sunday May 08, 2011 @09:13PM (#36067710)
    Comment removed based on user account deletion
  • by DoofusOfDeath ( 636671 ) on Sunday May 08, 2011 @09:16PM (#36067726)

    Hey, guess how passwords work? They're hard to guess.

    But when you're using HTTPS, a password is usually passed along a pre-secured channel. Aren't these URI's visible to all routers in between you and the file site, as well as any computer monitoring traffic on your local LAN?

    If so, that's somewhat less secure than passwords.

  • by Anonymous Coward on Sunday May 08, 2011 @09:41PM (#36067860)

    They are different and better than passwords, and they are not lengthy passwords that are stored in files. The entire mechanism of authentication using public-key cryptography is different. When you authenticate with a password, you send the password to the server, which compares it against some stored credential. When you authenticate using a key file or certificate, you take some set of values that usually includes something random from the server, generate a signature, and encrypt it using your private key. The server then decrypts it using your public key and makes sure the signature is correct. Your "lengthy password in a file" is never sent to the server, no representation of it is ever stored on the server, and the value you send for authentication cannot be intercepted and reused on the same server or any other.

    I doubt there is anyone that thinks certificates or keys are less valuable than passwords if compromised, they just realize they are less likely to be compromised.

  • Re:Encryption (Score:5, Insightful)

    by currently_awake ( 1248758 ) on Sunday May 08, 2011 @09:57PM (#36067958)
    Considering the cost of hard drives there is no good reason to keep anything in the cloud except for stuff you want to share (free hosting file server).
  • by billstewart ( 78916 ) on Sunday May 08, 2011 @10:52PM (#36068236) Journal

    The recent complaints about Dropbox and similar file storage sites violating users' privacy in return to lawsuits is because the site is doing the encryption, not the user.

    • The user uploads unencrypted data to the site across an encrypted SSL tunnel. W00t! We're R333713 S3kr1t Heer!
    • The site unpacks the tunnel and stores the data, possibly encrypted using a key they know, or possibly just with passwords to keep unauthorized users out.
    • The receiving user gives the site a password, and the site gives the user the again-unencrypted data over another R3333713 S3kr1t encrypted SSL tunnel. ,li>The FBI hands the Storage site a subpoena or warrant or National Security Letter or a note from their mom, and the site hands over the stored data and any keys they have, along with the transaction records from the upload.

    If you want to protect your data, you can never hand the storage site unencrypted data, and this includes handing them encrypted data along with the keys. Ideally, depending on the kind of security you're looking for, you'd like their storage system not to store files in ways that are easily traced back to you (for instance, the file gets stored with a filename that's a random string, and the storage site forgets who it belongs to after storing the file, so that anybody who steals the disk drive only knows that there are files named "bunch of random digits", and has know way to know which ones belong to which users. Anybody who wants to recover the file needs to know the filename (so the service can retrieve it) and the decryption key (which the service doesn't know.)

  • Re:How about (Score:5, Insightful)

    by wvmarle ( 1070040 ) on Sunday May 08, 2011 @10:55PM (#36068264)

    It is on a remote site, out of your control, so it's not secure. End of story.

    Encrypt before it leaves your system if you want to keep it secure. Or only store data on such sites that you really don't care if it becomes public.

    And even if there really are no remote security holes, anyone with admin/root access to the servers can access your data. Without you knowing.

  • by billstewart ( 78916 ) on Sunday May 08, 2011 @10:56PM (#36068278) Journal

    There are lots of services like Dropbox and Evernote and Pick-your-favorite-Online-Backup-Service that are focused on people storing their own data or on data they're only going to share with a small number of people (e.g. web upload/download instead of FTP, for people behind firewalls or with random DHCP addresses), and many of them give their users the idea that they're getting privacy. It's different from the Youtube-without-censorship file upload site market.

  • Confucius Say... (Score:5, Insightful)

    by seven of five ( 578993 ) on Sunday May 08, 2011 @11:08PM (#36068328)
    "He who trusts private data to remote host has head in cloud..."

Work continues in this area. -- DEC's SPR-Answering-Automaton

Working...