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."
Encrypt Everything Private (Score:5, Insightful)
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.
Re:Encrypt Everything Private (Score:4, Insightful)
Re: (Score:2)
Unless the rootkit records the decryption keys, or changed the algorithm, yes it will.
Rootkit isn't some magical hack everything solution. It is low level access to a machine, bad enough, but not unstoppable.
Re: (Score:2)
Re:Encrypt Everything Private (Score:5, Informative)
But in order to actually use encrypted data, it has to be decrypted at some point, so the rootkit just needs to wait for you to decrypt it. In the case of say, full disk encryption, this is rather easy.
The idea is that you encrypt the file you send to the filesharing site, that way when the filesharing site is hacked all the attackers get is an encrypted file. In fact this is a "perfect" use for data encryption: the file is never decrypted on the remote machine, only on your local one, so stealing the data off the remote site can never give an attacker access to anything but cyphertext.
Re: (Score:2)
Just to clarify my parent post.
I was talking more about the Virtual Encryped Disk file based encryption rather than Full Disk Encryption. FDE wouldn't be much help in a rootkit situation but using Truecrypt to make Virtual disk files and only opening them when necessary would be a more ideal choice.
Another option would be to use 7zip files with encryption.
Re: (Score:2)
If your computer is rooted, you might as well assume (for purposes of your security) that every key stroke and mouse event is being tracked and the "good stuff" is being extracted from that data stream for purposes of decrypting your encrypted files and vaults, etc.
Re: (Score:2)
A really evil person would seed their personal data with lots of child porn images, then block the same sites in a local HOSTS file so their own traffic doesn't go anywhere.
Which will in turn cause web traffic to honeypots or servers that will eventually be bagged and monitored by jack booted thugs working for some government who are going through the logs.
Then, anybody looking at the data gets a small but non-zero chance of assault by cop followed by PMITAP.
"What? I am not allowed to keep a list of U
Re: (Score:2)
Did exactly that a couple of years ago. I discovered that the "unlimited storage" only applied to "media files" which were accessible from your web pages.
So after I'd uploaded a pile of my stuff (family photos, etc) crunched up into zip files, totalling a few 10s of GB (which takes a while on standard 0.5MB/s upload ADSL here, but would have taken longer on my 33kb/s acoustic modem), the hosting provider
Re: (Score:2)
What? You mean the hosting provider doesn't *really* have unlimited stocks of hard drives to host people's data for $10 a month?
Re: (Score:2)
I was expecting to find out what their real limits were and then negotiate an appropriate rate, or trim my storage to an appropriate size. I didn't expect an immediate uncompromising shut-down.
So, off to Flickr for a paid account, and upload all the photos there.
Re: (Score:3)
Re: (Score:2)
It's the difference between unlocking a door to find a big pile of cash and unlocking a door to find a locked safe.
So yeah, it helps.
Re: (Score:2)
If you're using full-disk encryption, your decryption key is entered at boot and from there the OS doesn't even know the hard drive is encrypted (I know this is how TC and LVM encryption works, I think BitLocker works the same way). Likewise a rootkit wouldn't know the hard drive is encrypted. it would have access to the decrypted data like any other program. So full-disk encryption doesn't help with that, it only protects against physical access to a powered-off computer.
Re: (Score:2)
Good points - and just to add to your line of thinking, even if you use a secure TrueCrypt volume that is mounted with a unique password *after* you boot into your OS, that volume is still vulnerable when your computer is rooted b/c the key presses of the decryption password are passing through your rooted kernel (whatever OS you're running - doesn't matter) - basically keyloggers running with admin/root privileges make just about any security measure weak. Not sure if hardware keys/cards these days make th
Re: (Score:1)
Umm.. yes but what if the rootkit comes into action *after* you have applied the TrueCrypt key?
That makes it pretty worthless...
Re: (Score:2)
Exactly. People seem to forget that in order for data to become useful, the user has to decrypt it at some point. That involves providing the key, and that's when a clever rootkit will spring into action.
You Have to Encrypt It Yourself (Score:4, Insightful)
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.
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: (Score:2)
SpiderOak encrypts and decrypts the data on the client. You can access your data over a web interface which sends the decrypt password to the server but they warn you that you are risking your privacy by doing so. It's a fair bit more slow and complex to set up than Dropbox though.
Re: (Score:2, Funny)
Re: (Score:2)
Re: (Score:2)
False. Truecrypt also (primarily?) does file container encryption. It's like an encrypted disk image. Granted, if the pc is nabbed while it's mounted your point is still valid, but I never leave my truecrypt container file (which primarily contains tax/financial data) mounted unless I am using it at that moment. I've never even used it for full disk encryption (which I leave to dmcrypt+luks).
So what you're telling me is... (Score:1, Insightful)
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!
Re:So what you're telling me is... (Score:4, Interesting)
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!
That was my initial reaction, but on second thought I think it is fairly newsworthy.
The Register's audience is regular users, who do stuff like put sensitive documents on a file sharing site. It's worth a few paragraphs to remind people not to do idiotic things.
It's also worth noting that these sites either a. have index pages turned on and don't know it, which would be so incompetent as to make me wonder how they keep a file server running or b. are allowing these pages to be crawled and telling their users that they aren't, which is unethical as hell and possibly illegal.
Re: (Score:1)
Hell, flags should be raised to an average user when you consider how many of them probably also use these rapidshare/megaupload/mediafire/et. al. search engines to dig up content
Re: (Score:1)
I've set the bar pretty low... I mean, it's a British rag that's not talking abut their fucking wedding.
Re:So what you're telling me is... (Score:4, Insightful)
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.
Re: (Score:3)
"The Register's audience is regular users"
El Reg?
Hardly.
Gamers and tech heads, through IT folk, security researchers and software engineers. It's got articles for everyone. It's often more hardcore than slashdot these days, which says more about the decline of slashdot than anything else...
Re: (Score:2)
Encryption (Score:5, Informative)
Why would you upload private data to some file hosting site? These (e.g. RapidShare) aren't the kind of services where you can modify files after uploading (such as Dropbox), so encryption is not much of a hassle. You have no reason not to encrypt the files before uploading them.
Comment removed (Score:5, Insightful)
Re:Encryption (Score:5, Insightful)
Re: (Score:2)
Considering that the summed total of everything digital that I've ever actually created fits nicely on my free Dropbox account there is no good reason not to use them as a convenient, transparent, and immediate part of a complete backup solution.
It's nice having the same pile of stuff available to me, whether I'm at my desktop, using my laptop, or fiddling with my Droid, and the revision history is simply awesome.
I don't use Dropbox to share files with others -- that's what Apache is for. (YMMV.)
(And, no,
Re: (Score:2)
Re: (Score:2)
They can have my identity. It is just as uninteresting, and far more useless.
Re: (Score:1)
Re: (Score:2)
> there is no good reason
Sure there is security and not wanting your stuff "published" or otherwise "shared".
If you don't have squat, then DropBox is pretty pointless in an age where multi-gigabyte portable devices are cheap and plentiful and available at Walmart and Target.
It's not like a drag & drop copy operation is terribly complicated. (although in this day and age it's hard to tell what some people will claim)
Re: (Score:2)
No, it's not horribly complicated. But keeping good, off-site backups can be.
But that's not the point, is it? The point is that you don't like Dropbox for reasons that I fully understand, and but which I simply don't care about.
Re: (Score:2)
Except if my apartment gets burgled, burnt down, has a pipe burst and flood everything (or any number of surprisingly common scenarios) then all my hard drives are as useless as each other. There is definitely something to be said for off-site backups, maybe not for my collection of TV shows and movies but definitely for photos, documents and other information like that.
(of course you should use a backup program that encrypts the files on your local machine with a key known only by you before you upload any
Re: (Score:2)
Indeed.
I don't care, so much, if my poorly-backed-up collection of media gets destroyed: Most if it is not something that will be difficult to find (or rip) again.
I do care, however, about the stuff I made myself, and that's what Dropbox is good for. I even keep some of my financial and billing data there.
Of course I "should" encrypt things, but why? My identity is too useless to steal, and my own data is only valuable to me. I mean, seriously: What would someone find if they did attack my Dropbox acco
Re:Encryption (Score:4, Informative)
Many people for some reason think it's safe because the site says they will protect your data.
Well maybe they can protect your data and will do some effort for it, the fact is you're putting your data on someone else's computer. The owner of that system (basically anyone with high enough privileges or physical access to the system) can access your data. They not necessarily will, but they can. And that little factoid is enough to make it insecure.
That such file hosting sites may have additional security holes allowing access to data one shouldn't have access too, is not important any more. When it's out of your controlled environment, the data is out of your control.
The only way to use remote hosting securely is to either own and directly control the remote hosting site by yourself, or to encrypt everything before it leaves your controlled environment, and keep the secret key to yourself. It's as simple as that. I'm wondering why this is even considered news here.
Like Shark Week? (Score:5, Funny)
This is the kick-off to Slashdot's "No Shit Week"
Re: (Score:2)
Re: (Score:2, Funny)
Then they could follow up with the quality bunch of Ask Slashdot articles of late:
Re: (Score:2)
This demands a "-4 depressing, quadruply so" mod.
And is anyone surprised ? (Score:1)
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.
And is anyone surprised?
And is anyone who has only uploaded *encrypted backups* terribly concerned? They may still change providers do to a loss of confidence but they are probably not losing a lot of sleep.
No shit, sherlock (Score:2)
How about (Score:3, Informative)
Re: (Score:1)
You can password entire folders/files on mediafire, so even if the link to the file somehow gets to the public, they need a password to be able to proceed and download it.
Re:How about (Score:5, Insightful)
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.
No, no, no! (Score:1)
Re: (Score:3)
do they provide docs about how they're done their stuff? are the access rights checked everytime someone uses a link to the file? because um some don't. eh heh. saves cpu and infra.
non-story (Score:3)
The services, which include sites such RapidShare, FileFactory, and Easyshare, allow users to upload large files and make them available to anyone who knows the unique URI (or Uniform Resource Identifier) that's bound to each one. Users may post the link on websites or forums available to the public or share it in a single email to prevent all but the recipient from downloading it. RapidShare, for instance, says it can be used to “share your data with your friends, colleagues or family.”
But according to academics in Belgium and France, a “significant percentage” of the 100 FHSs (or file hosting services) they studied made it trivial for outsiders to access the files simply by guessing the URLs that are bound to each uploaded file. What's more, they presented evidence that such attacks, far from being theoretical, are already happening in the wild.
Stopped reading right there. It's not private just because the URL is some randomly generated string. These sites are not designed to securely transfer files to only the recipient so this is not in any way a "weakness".
Re: (Score:3)
Stopped reading right there. It's not private just because the URL is some randomly generated string. These sites are not designed to securely transfer files to only the recipient so this is not in any way a "weakness".
Neither is email, so I guess if you could read everyone's email that wouldn't be a weakness either. Get off your high horse, the URL is supposed to be the equivalent of an email account password, if you have it you can access the files otherwise not. You have to make sure only the right people have the URL, but anything that lets others grab the file anyway is obviously a goatse-class backdoor just as if gmail or hotmail was wide open.
Re: (Score:3)
"Neither is email, so I guess if you could read everyone's email that wouldn't be a weakness either. Get off your high horse, the URL is supposed to be the equivalent of an email account password, if you have it you can access the files otherwise not. You have to make sure only the right people have the URL, but anything that lets others grab the file anyway is obviously a goatse-class backdoor just as if gmail or hotmail was wide open."
I've heard this argument before, and here's the reason I'm skeptical of
I think you missed his point... (Score:2)
E-mail itself isn't encrypted and any email you send transmits through and may even reside, unencrypted, on several servers between the sender and the recipient. If someone were to gain physical access to whatever server your email is stored on, they can read all your email. Or gain physical access to any server that transmits email and read a lot of email going through that server.
An email provider is a bit like your doctor - they have several motivations for NOT disclosing your private information, but t
Re: (Score:2)
Re: (Score:1)
Re: (Score:2)
A priest or doctor giving testimony on a client is liable to prosecution - the have an obligation of secrecy. Such testimony (if given) will also not be allowed as proof for any wrongdoing. E-mail providers are in a totally different class - they are not allowed to keep things secret when formally asked for information.
Re: (Score:1)
Re: (Score:2)
Can you back up "most jurisdictions" with some numbers? I wouldn't even be sure of it being a majority for "any" data. I know for sure that certain personal medical information the doctors here are obliged to report to the relevant authorities.
I also remember cases such as the infamous "Typhoid Mary" that suggests that the situation in your locality may not be exactly as you paint it ; sometimes limits to p
Re: (Score:2)
Actually, it's a pretty good analogy. Yes, there are laws that say the doctor can't divulge certain information. There are also laws that create liability if someone inappropriately discloses what's in your email.
But, ultimately, the only thing that prevents the doctor from disclosing your information is his own choice. Additionally, the doctor has staff that work at his office with access to your information. Your insurance company may also have it. Health authorities may have access to it. And the i
Re: (Score:2)
Easy to guess?... (Score:2)
Well e-mail security is poor but that isn't the point. A URL is not a password and should not be treated as one. It's fairly easy to guess random text strings until you get a hit on these URLs. You will eventually find *something*.
Not really, the random string just needs to be random enough and long enough and it will take you longer than the life of the universe to "find something". Since no user needs to remember it, making it unguessable does not impact usability either. And if you want to make sure it does not become known to a MiTM, just do all the file downloading over HTTPs.
Yes, the web is a mess of technologies taped onto each other, but that doesn't mean there aren't right ways and wrong ways of using it from a security
Re: (Score:2)
It could be, but probably 95% of all mail servers out there still fail to do SSL because the admins can't figure out SSL certificates. Or they use a simple self-signed cert, which is fairly useless at preventing MiTM attacks (you end up talking over an encryp
All security is through obscurity (Score:5, Insightful)
“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.
Re: (Score:1)
+1. This is how session ID's work for your online banking, email access etc too.
Re:All security is through obscurity (Score:4, Insightful)
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.
Re: (Score:2)
Not when using HTTPS, supposedly. Without SNI not even the domain is known, which cause problems for shared hosts.
Re: (Score:3)
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.
Right, so the normal usage of the terms "secure" and "obscure" is ambiguous. And pardon me if I'm explaining the obvious, but some people definitely don't get it, and the Internet has a desperate need for my opinion.
Obscurity is an intrinsic property of things. A Babe Ruth rookie card is obscure because there aren't many of them. It often, but not always, makes something valuable. Vogon poetry might make a great secret key, but no one would pay for it.
Security is something you impose upon a thing. I can sec
Re: (Score:2)
While you have a point that many security methods such as passwords rely on 'obscurity', one can still make a distinction between methods which rely on poorly measured (and typically low) entropy and methods which rely on well defined entropy. Usually when people talk about the dangers of security through obscurity, they are talking of the former; the use of methods such as pass-phrases have well defined entropy, and the degree of difficulty ('obscurity') is controlled. Of course, pass-phrases are not a mag
Security-by-obscurity (Score:4, Informative)
While you have a point that many security methods such as passwords rely on 'obscurity', one can still make a distinction between methods which rely on poorly measured (and typically low) entropy and methods which rely on well defined entropy. Usually when people talk about the dangers of security through obscurity, they are talking of the former;...
No. Security by obscurity means security achieved by keeping the details of your system secret (architecture, algorithms, etc), so people don't know how to break in. The accepted way to do security, on the other hand, is to build a system that is secure even against adversaries who know everything about your system, lacking only a well defined credential or set of credentials (a password, certificate, fingerprint, etc).
Using "secret" urls to provide access is not security by obscurity if there is enough randomness involved that urls are practically unguessable, though if it does not go over HTTPs it is certainly weak against certain threat models (Man-in-the-middle).
Re: (Score:2)
I think we are in agreement, though you perhaps described it better. Keeping details of the system secret involves an 'obscurity' that is difficult to measure; exactly how hard is it to guess the architecture or algorithms? It is poor security because it is ill-defined.
On the other hand, the GP was pointing out that a credential is a form of data 'obscurity'. But while that is true in some literal sense, it isn't the generally accepted meaning of the term 'security through obscurity'.
An interesting discussi
Re: (Score:2)
No.
So what you've done there is redefined obscure to something that you think that it should mean and then reduced everything to your new definition. And of course you haven't done it properly so everything collapses into a single case. If I have a token with 1000 possible values then it could possibly be described as obscure (although that is not the technical definition used in security). If I have a token with 10^9 possible values then I'm really stretching the definition that you are imposing upon the w
Re: (Score:2)
No.
Yes!
So what you've done there is redefined obscure to something that you think that it should mean and then reduced everything to your new definition. And of course you haven't done it properly so everything collapses into a single case.
You're right in that "obscure" isn't the perfect word, but I'm just trying to rebut the "security through obscurity" meme rather than do a course in cryptography, which I wouldn't be qualified to do anyway.
What about 2^128 values? Well beyond the limits of computational feasibility. We don't treat this as "just a bit harder to guess" because beyond some limit things actually do operate differently and the mental intuition from smaller domains breaks down. ...
If you start to reinforce the door on your house, long before the door becomes unbreakable a determined attacker will just go through the walls.
A key with 128 bits, while impossible to guess, is also impossible (or at least highly impractical) to memorize. You're right, there are plenty of things that
Re: (Score:2)
Oooo!
I actually quite like your line of argument. If I knew of a term that was somewhere between the weakest link in a chain and obscurity then I would suggest it now. Even though I don't know of a name the concept that you are describing seems to be quite a good model of the usefulness of a security system. Seems to be a notion that reduces directly (and quite obviously) to security, thus showing that it captures some interesting part of the term.
Wrong. (Score:2, Insightful)
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.
Re: (Score:2)
Re: (Score:3)
One of the main problems with keys is that they're much too long for most users to remember, so they almost always end up stored in a file or database of some sort. This act alone reduces the overall security far, far more than the risk of a brute-force attack.
Uh, no it doesn't. You not only have to get into my machine to find the key file, you also have to break the passphrase on that key file.
So at worst it's no less secure than a password, and at best it's far more secure.
Re: (Score:2)
One of the main problems with keys is that they're much too long for most users to remember, so they almost always end up stored in a file or database of some sort. This act alone reduces the overall security far, far more than the risk of a brute-force attack.
Uh, no it doesn't. You not only have to get into my machine to find the key file, you also have to break the passphrase on that key file.
So at worst it's no less secure than a password, and at best it's far more secure.
First, you can crack keys. Bit length determines how long. So if you are using a short bit-length (e.g. 40-bit, 56-bit) as opposed to a long big length (e.g. 4096-bit, 16384 bit) then it is no different from an easy password (e.g. password) versus a harder password (e.g. #839djAiejf@938). Cracking the key does not require knowledge of the passphrase - you only need that if you gain access to the stored private key file.
Second, a stored key file does not require a passphrase - that is optional, and not ev
Re: (Score:3)
Brute-force attacks should never be an issue, regardless of whether passwords or keys are being used. Even shitty authentication systems will lock accounts after a small number of failures, or will at least introduce an exponential delay between subsequent attempts. If you can only perform 20 failed logins per day, if not fewer, for a given account, then it will significantly reduce the potential of a successful brute-force attack.
If that was implemented for SSH on a Internet facing machine, nobody could ever log on, the accounts would be always locked.
And if it's 20 failed logins per IP, then it's useless, since many attackers use botnets.
One of the main problems with keys is that they're much too long for most users to remember, so they almost always end up stored in a file or database of some sort. This act alone reduces the overall security far, far more than the risk of a brute-force attack. Given that they're often stored in common locations, even on different installations of different operating systems, all it takes are slightly incorrect permissions on a user's home directory and their keys are easily accessible. It gets worse if the system or home directory is periodically backed up, with the key being propagated (perhaps unknowingly!) to other media and locations,.
That's why keys have - wait for it - passphrases!
Re: (Score:1)
A private key is *much less likely* to be compromised. Because, since it's being used in public key crypto and not shared secret crypto, you don't pass it to another system (unless you're retarded).
Re: (Score:3, Insightful)
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 k
When?? (Score:1)
does this surprise anyone? (Score:2)
does this surprise anyone?
Re: (Score:2)
well the hubbub about dropbox a while ago did surprise me. but maybe that's because I don't use it.
Confucius Say... (Score:5, Insightful)
even worse than a safe haven... (Score:2)
Even worse than a safe haven are all those unsafe havens! Never put your data there!
Compress, generate strong password, encrypt. (Score:1)
Using the same password over and over again?
Install passwordmaker.org to generate all your passwords.
Exists for most browsers, as javascript, CLI, also Maemo (in development), android, iphone.
All the above is useless of course, if your OS is not up to date and depending on platform don't use the usual anti-malware/virus.
Re: (Score:1)
No shit, Sherlock! (Score:2)
If I upload a file to a public URL, you mean anyone can access it? I'd never have guessed!
For those saying "Well, duh!" (Score:3)
Part of the issue is how these sites market themselves. Many sell themselves as "a fast, easy, secure way to send files to friends and colleagues without being hit by such bothersome things as email size limits or limits on sending executables".
The security they provide varies. Some allow you to password-protect the download (so nobody's getting it without entering the password first). Others don't do this, the security stems from the URL they give you to include in the email being apparently-random and not published anywhere. Security through obscurity, in other words. To you and me, this is a disaster waiting to happen, but these products aren't being used by you and me. They're being used by others in the business who are annoyed that the IT department is blocking them from sending out a particular attachment, and rather than ask the IT department to come up with a solution are instead using such a service. It's actually pretty common for these companies to offer corporate accounts so you can give your users a solution which is branded with your company name and logo and allows you to enforce rules regarding what options users may choose when they come to send a file. But corporate accounts cost money, getting the money means setting up a project and will take a minimum of a couple of months. This file needs to reach the recipient in a couple of hours.
These researchers have demonstrated that not only are the URLs generated not particularly random, they're easy to guess and people are already guessing them left and right.
a little obvious, don't you think? (Score:2)
Is this news for nerds? (Score:2)
Excuse me. Sure, i trust free web-services, who aehem usually are programmed in the cheapest way to get salting right. Such a thing has never happened before that IDs could be guessed.
Let me say it like this: if you dont want that people access it, then enrcypt it and dont put it to a free filehoster.
But... (Score:2)
Re:Bogus (Score:5, Informative)
At a guess, an embedded URL that's loaded automatically when someone opens the document, for example an IMG tag.
Re: (Score:2)
Re:Bogus (Score:5, Informative)
Re: (Score:1)
It's rather similar to a trojan. It communicates with the outside world without your explicit approval. I think they are using the term 'beacon' to imply that the communication is one-way, and they hope to imply that no personal data is transmitted, etc ad nauseum.
Re: (Score:1)