Security Concerns in Popular Cloud Storage Services

50 PERVASIVE computing Published by the IEEE CS n 1536-1268/13/$31.00 2013 IEEE

E d g E o f t h E C l o u d

Security Concerns in Popular Cloud Storage Services

C loud storage and synchroniza-tion services let users access their digital content any time, from anywhere, and with any devicesmartphone, tablet, or desktop PC. It has become common for people to outsource their data to the cloud without being concerned about how the storage is managed. At the same time, the rapid adop-tion of portable equipment and the growing integration of computation into consumer

products have brought mobile and pervasive computing into the mainstream, with cloud storage and synchronization services widely used across mobile devices.

Many cloud service pro-viders (CSPs) offer a large amount of space for consumer use. Here we focus on Drop-box (www.dropbox.com), Google Drive (drive.google.

com), and Microsoft SkyDrive (skydrive.live.com). Typically, a user who signs up for a cloud storage service can get a few gigabytes for free or a hundred gigabytes for just several dollars per month. Users can access their data via various interfaces, such as a standard soft-ware client, a Web browser, or a smartphone application.

To ensure the security of a cloud storage service, all communications between users and the CSP are encrypted, so nobody can eaves-drop on the data during uploading or down-loading (see the Related Work in Cloud Se-curity sidebar). However, once users hand over their data to the CSP and begin sharing it with others, the security of that data can move beyond their control. Here, we identify sev-eral security weaknesses in Dropbox, Google Drive, and Microsoft SkyDrive that could lead to data leakage without users awareness. Fur-thermore, some of the weaknesses might exist in other cloud storage services, due to the simi-larity in data sharing methods.

data SharingMost popular CSPs support data sharing. A data owner can share data with business part-ners, friends, or coworkers, letting them access designated data directly from the cloud using one of the following sharing methods:

Public sharingthe data is intended for the public, so theres no access control. A link to the shared folder (called the sharing URL) can be published, giving anyone on the Internet access to the shared documents.

Secret-URL sharingthe owner shares the data with others by sending them a sharing URL generated by the CSP. Anyone with this

The authors perform a systematic security analysis of the sharing methods of three major cloud storage and synchronization services: Dropbox, Google Drive, and Microsoft SkyDrive. All three services have security weaknesses that could result in data leakage without users awareness.

Cheng-Kang ChuInstitute for Infocomm Research

Wen-Tao ZhuChinese Academy of Sciences

Jin Han, Joseph K. Liu, Jia Xu, and Jianying ZhouInstitute for Infocomm Research

pc-12-04-chu.indd 50 01/10/13 2:02 PM

OCTOBERDECEMBER 2013 PERVASIVE computing 51

URL can access the data without fur-ther authentication or authorization. The data owner is responsible for (though not always capable of) iden-tifying the URL receiver.

Private sharingthe owner must specify who (with identifiers usu-ally in the form of email addresses) can access the shared data. The CSP then authenticates the identi-ties of the specified users, usually by requesting that they sign into their account before accessing the data. Each specified user thus must have an account with the corre-sponding CSP.

Clearly, public sharing is the simplest way to share data, but this method doesnt apply to private information. Private sharing is the most secure, but

everyone must sign into the system, and it might not be easy to have everyone involved register with the same CSP. Secret-URL sharing strikes a balance between security and convenience, let-ting people without an account access the shared data as long as they have the required URL.

dropboxDropbox, hosted on Amazon Simple Storage Service (aws.amazon.com/s3), is one of the top network storage ser-vices. Each user must register an ac-count on Dropbox to obtain a certain amount of storage space, and the first few gigabytes are free.

As we review various data-sharing mechanisms throughout the rest of the article, we assume a scenario in which data owner Alice is sharing a file in the

cloud with her friend Bob by sending him a sharing URL.

dropbox Sharing MechanismsFor public sharing, Alice can just put her files in a folder named public (which must be enabled for accounts created after 4 October 2012; see www.dropbox.com/help/16). Anyone can ac-cess the files as long as they know the corresponding URL, such as http://dl.dropbox.com/u/10312344/cloud1.pdf, where 10312344 is a sequence of decimal numbers identifying a users public folder. With this sequence, any-one can access this users other files as well, as long as they specify the cor-rect file name (cloud2.pdf, for exam-ple). If we search filetype:pdf site:dl.dropbox.com on Google, we can find nearly one million pdf files in Dropbox

F or the past several years, industry and the research commu-nity have been striving toward a more reliable and secure cloud.14 While these research efforts focus on the cloud infra-

structure, few investigations5 have focused on the edge of the

cloudfor example, from the user perspective.

Cryptography-based solutions let users share their data more

securely in the cloud.69 However, theyre not widely adopted

because they require complicated key management. Moreover,

cryptography alone cant enforce the privacy demanded by

common cloud computing services.10

Some studies address usable confidentiality for users on ex-

isting cloud storage services11in particular, access control for

cloud storage in mobile devices.12 This shows that nowadays, the

security of accessing cloud data through mobile devices is also

an important concern, where new forms of threats can arise.

REfEREnCES

1. C. Christian and M. Schunter, A Cloud You Can Trust, IEEE Spec-trum, vol. 48, no. 12, 2011, pp. 2851.

2. K. Ren, C. Wang, and Q. Wang, Security Challenges for the Public Cloud, IEEE Internet Computing, vol., 16, no. 1, 2012, pp. 6973.

3. R.K.L. Ko, S.S.G. Lee, and V. Rajan, Understanding Cloud Failures, IEEE Spectrum, vol. 49, no. 12, 2012, p. 84.

4. M. Green, The Threat in the Cloud, IEEE Security & Privacy, vol. 11, no. 1, 2013, pp. 8689.

5. T. Hahn et al., Vulnerabilities through Usability Pitfalls in Cloud Ser-vices: Security Problems due to Unverified Email Addresses, Proc. 11th IEEE Intl Conf. Trust, Security and Privacy in Computing and Com-munications (TrustCom 12), IEEE, 2012, pp. 850856.

6. M. Li et al., Scalable and Secure Sharing of Personal Health Records in Cloud Computing Using Attribute-Based Encryption, IEEE Trans. Parallel and Distributed Systems, vol. 24, no. 1, 2013, pp. 131143.

7. X. Liu et al., Mona: Secure Multi-Owner Data Sharing for Dynamic Groups in the Cloud, IEEE Trans. Parallel and Distributed Systems, vol., 24, no. 6, 2013, pp. 11821191.

8. C.-K. Chu et al., Key-Aggregate Cryptosystem for Scalable Data Sharing in Cloud Storage, IEEE Trans. Parallel and Distributed Systems, preprint, 2013; doi: http://doi.ieeecomputersociety.org/10.1109/TPDS.2013.112.

9. F. Kerschbaum and L.W.F. Chaves, Secure Sharing of Item-Level Data in the Cloud, Proc. 4th IEEE Intl Conf. Cloud Computing (Cloud 11), IEEE, 2011, pp. 756757.

10. M. van Dijk and A. Juels, On the Impossibility of Cryptography Alone for Privacy-Preserving Cloud Computing, Proc. 5th Usenix Workshop on Hot Topics in Security (HotSec10), Usenix, 2010, pp. 18.

11. S. Fahl et al., Confidentiality as a ServiceUsable Security for the Cloud, Proc. 11th IEEE Intl Conf. Trust, Security and Privacy in Comput-ing and Communications (TrustCom 12), IEEE, 2012, pp. 153162.

12. J. Shin et al., DFCloud: A TPM-Based Secure Data Access Control Method of Cloud Storage in Mobile Devices, Proc. 4th IEEE Intl Conf. Cloud Computing Technology and Science (CloudCom 12), IEEE, 2012, pp. 551556.

Related Work in Cloud Security

pc-12-04-chu.indd 51 01/10/13 2:02 PM

52 PERVASIVE computing www.computer.org/pervasive

EdgE of thE Cloud

users public folders (one more click on repeat the search with the omitted re-sults included might be needed for the search).

The secret URL generated by Dropbox is in a form like the fol-lowing: https://www.dropbox.com/s/192tmt67scsel57/cloud.pdf, where 192tmt67scsel57 is an alphanumeric sequence identifying exactly this file. Unlike with the public folder, this se-cret value is unique for every file shar-ing. So, you cant access another file in the same folder by just changing the file name. The secret value is irrelevant to the user identity (of either the file owner Alice or her friend Bob). However, Dropbox doesnt authenticate Bobs identity when he connects to Dropbox with such a secret URL, so anyone who gets this URL can access the shared file directly.

The private sharing is only provided for foldersnot fileson Dropbox. Bob needs a Dropbox account to ac-cess the folder shared by Alice. Alice can specify Bobs email address and send him an invitation email. There are two cases for the invitation. If Bobs email has been registered with Drop-box, he can access the sharing folder after he signs into Dropbox with that invited email address and accepts the invitation. Or, if Bobs email hasnt been registered with Dropbox, he can use the invitation link to sign up for a new Dropbox account with any email address. Once he signs up, hell have ac-cess to the sharing folder.

dropbox Security WeaknessesAlthough Dropbox is convenient and popular, we observed several security weaknesses in its sharing methods.

Nondead URL. For secret-URL sharing, the URL links to a path (the general form of a file name) rather than a spe-cific file object. Suppose that Alice gen-erates a link for a file in Dropbox that she wants to share with Bob. The link can be used by Bob to access the file (in a certain folder) with that file name,

no matter how many updates are made to the file itself. Surprisingly, the link remains nondead, even if the file has been removed. Later, if some other file object is associated with the same file name, Bob can access the new object.

For example, lets say Alice wants to collaborate with Bob on a paper named mypaper.doc. She puts the paper on Dropbox and shares its link with Bob. After finishing this work, Alice removes the file. At a later date, Alice writes an-other paper with the same file name, mypaper.doc. However, this time the work is private. Alice might not know that Bob can use the same link to access the new mypaper.doc, thereby un-knowingly exposing her private data.

NonHTTPS shortened URL. If Alice re-quests the sharing URL using a mo-bile device (such as a smartphone), the Dropbox application might generate a shortened URL in an HTTP form, such as http://db.tt/A4Y6YKfw, where A4Y6YKfw is a case-sensitive alpha-numeric sequence. The shortened URL will redirect users to the original (full) sharing URL. This lets Alice send the URL more easily via SMS or Bluetooth, or even by speaking over the phone. However, the shortened URL isnt SSL protected, and an eavesdropper could acquire the link and access the file.

Note that HTTPS protects not only the transmission of the involved data but also the resource locator. The orig-inal URL might be in an HTTPS form, but that doesnt help, as well discuss later. Moreover, if we search site:db.tt on Google, we might get more than 60,000 files in various types. The al-phanumeric sequence isnt long, with a cardinality of at most 628 (< 248). An attacker could perform an exhaustive search to get a significant part of all the links, many of which might be the shortened sharing URLs linking to the users private data.

Unauthorized resharing. For private sharing, Alice can change the settings to ensure Bob cant invite others to

view this data. However, Bob could still share the folder or some of its files using secret-URL sharing. He could generate a secret URL of a file in the sharing folder and send it out without Alice knowing.

Although Bob is eligible to down-load the files and send them to others, resharing via URLs is a different sce-nario. Bob can easily publish the URL of the entire folder on some website and let the public download the files directly from the cloud. More seriously, access-ing a file via the sharing URL provides access to any updates made to the file.

No privacy on sharing. Anyone with ac-cess to Alices sharing folder can learn the identities of other people with ac-cess to this folder (see Figure 1), which isnt always desirable. Assume that a folder is internally shared in a company, so all employees can access this folder. However, what if someone shares the folder with a business partner? The partner could then see the list of em-ployees and their email addresses.

Uncertain identities. For private shar-ing, if Bobs email address hasnt been registered on Dropbox, he can follow the invitation link to register a new ac-count with any email address to access the sharing folder. Although Alice can check the list of people who have ac-cess rights to the sharing folder, it only shows their names and email addresses being used on Dropbox. If Alice sees an email address thats different from the one to which she sent the invitation, she might not know who owns the address.

For example, if Bob uses his official email and real name (bob@mycompany. com) in the office, but he uses his pri-vate email and a nickname on Dropbox ([email protected]), Alice might not recognize him (see Figure 1). In partic-ular, if Alice shares a file with a num-ber of people, its difficult to track all the names. Even worse, if the invitation link is somehow leaked to another per-son, the sharing folder can be accessed by that person with a new registration.

pc-12-04-chu.indd 52 01/10/13 2:02 PM


google driveFigure 2 shows the sharing settings for Google Drive, which was released in 2012. Each file, once uploaded, is asso-ciated with a unique URL. Regardless of the sharing method employed, the files associated URL remains fixed. Us-ers who have such a URL might not be able to access the fileaccess depends on the files sharing settings (see who has access in Figure 2).

google drive Sharing MethodsFor public and secret-URL sharing, Al-ice can change the visibility option for each file from private to public on the Web or anyone with the link, and then she can publish the associ-ated URL or send the link to a friend, respectively.

For private sharing, the shared file can only be accessed by someone with a Google account (in the form of an email address but not necessarily a Gmail address). The sharing settings let Alice specify email addresses in the files sharing list (who has access). Once Alice enters Bobs email address, the system will send an email to the address.

If Bobs email address is registered as a Google account, the fixed URL of the file will be sent to him. When Bob opens the link, Google Drive will ask him to log in to the system. If the account he signed into (which might be different from the email address specified by Al-ice) is included in the sharing list, Bob can access the file directly; otherwise, hell be asked to request access permis-sion from Alice. If Bobs email address isnt a Google account yet, a special in-vitation link will be emailed to him. By following the invitation link, Bob can sign into the system using any Google account (or sign up for a new account if needed). The account he signed into will be included in the files sharing list.

google drive Security WeaknessesUnlike with Dropbox, Google Drive us-ers get only one sharing URL for each

file, and they can control the sharing setting anytime. However, there are still some other issues with this method.

Sharing of trash files. When Alice de-letes a file from Google Drive, the file is actually moved to a trash folder. This sounds reasonable, because Alice might need to recover her file in the future. Nevertheless, people can access the deleted file (in the trash folder) via the same URL as before, no matter how Alice chooses to share this file. This is a serious problem, because when Alice removes a file, she prob-ably doesnt want to share it anymore. However, in Google Drive, she wont be aware that people can still access these in the trash folder.

Fixed URL. The URL of a file in Google Drive is fixed. If Alice made a file pub-lic previously but wants to privately share it via the secret URL, this will be-come a problem. Because the URL has been published, its not possible to re-call this public information. Someone

who already got the URL can still ac-cess the file.

Note that Google Drive doesnt pro-vide an explicit option to change the URL for a given file. Even if the file name changes, the access URL remains the same. The only way to generate a different URL is to make another copy of this file.

Unauthorized resharing. If Bobs email address isnt registered as a Google ac-count and he receives Alices sharing in-vitation, he can sign into Google Drive with his own Google account. How-ever, the invitation URL can be used multiple times. That means Bob can redistribute the invitation URL to let other people sign in to the system with other Google accounts so that they can all access the file.

Indiscriminate accessing URL. On the Google Drive website, any file is ac-cessed via the associated URL, even for the file owner. So, the file owner will need to open a link to access the

Figure 1. The private sharing options for a folder named paper in Dropbox. All people who have access to Alices sharing folder can learn the identities of other people with access to this folder.

pc-12-04-chu.indd 53 01/10/13 2:02 PM


EdgE of thE Cloud

file. Setting the file to be shared via the secret URL significantly increases the chance of data leakage. For example, if Alice is in a meeting and accesses her file while using a projector, the URL will be shown in the browsers address bar.

No privacy on sharing. As in Dropbox, people who have access to Alices files can learn each others identities.

Uncertain identities. As in Dropbox, Alice will be confused by some email addresses shown on the sharing list, because she might not have sent in-vitations to these addresses. If Alice shares a project file with her busi-ness partners by sending invitations to their official email addresses (not Google accounts), she might not rec-ognize these partners by their Google accounts (with which they actually sign in) shown in the files sharing list. Moreover, considering the possibility of unauthorized resharing, it seems necessary to authenticate the identi-ties in the sharing list.

Microsoft SkydriveMicrosoft SkyDrive also supports the three sharing methods, but in a relatively more secure way. In Microsoft SkyDrive, each file is associated with a fixed re-source ID (see resid in Figure 3), which can be made public. All users, including the file owner, must access the file via a URL containing the resid. The access per-mission of a shared file is controlled by an additional secret authentication key (authkey), which can be appended to the sharing URL (see the first two links in Figure 3) and the usage of which depends on the sharing method.

Skydrive Sharing MethodsThe file is publicly accessible via the URL with the corresponding resid (see the last link in Figure 3). As with Google Drive and Dropbox, no autho-rization key is required.

In secret-URL sharing mode, the sharing URL includes the resid and

Figure 2. The sharing settings for a file in Google Drive. Users can determine who has access to the file.

Figure 3. The sharing settings for a file in Microsoft SkyDrive. Each file is associated with a fixed resource ID (resid).

pc-12-04-chu.indd 54 01/10/13 2:02 PM


authkey. The system lets the file owner generate two versions of the authorization keyone for view only and the other for view and edit. Therefore, Alice can control Bobs permission by sending him the URL with the corresponding autho-rization key. This key can be revoked when Alice wants to stop sharing the file, and it can be regenerated when Alice wants to share it again. So, un-like Google Drive, the sharing URL isnt always fixed.

Bob will need to sign into the sys-tem using his Microsoft account (in the form of an email address) before access-ing a file shared with him. The system lets Alice send a URL with an authori-zation key to Bob via email. However, unlike in Google Drive, Bob can sign in with any Microsoft account, regard-less of the email address to which Alice sent the URL with the authorization key. After that, Alice can only see on the sharing list the Microsoft account that Bob has signed in with. The autho-rization key can only be used oncethat is, Bob can use this key with only one account.

Skydrive Security WeaknessesMicrosoft SkyDrive has been cautious about a few potential threats (such as the employment of a one-time autho-rization key). Still, at least two aspects have been overlooked.

NonHTTPS shortened URL. Microsoft SkyDrive provides (and perhaps rec-ommends) a URL-shortening service for secret-URL sharing, as shown in Figure 3. The shortened URL wont be protected by SSL, as with Dropbox. In addition, the URL is in a form such as http://sdrv.ms/WEkgCn, where WEkgCn is a case-sensitive alpha-numeric sequence. The number of pos-sible combinations is approximately 626 (< 236), which is even less than Dropbox. Its not hard for an attacker to perform an exhaustive search to dig out a few interesting files intended for secret sharing.

Uncertain identities. As described, even if Alice sends the sharing email to one of Bobs Microsoft accounts, Bob can still sign in with any Microsoft account. Only the signing account will appear in Alices sharing list. This makes it diffi-cult for Alice to identify the people with whom she shares the file.

the Security of Secret-uRl SharingHere, we revisit secret-URL sharingwhere obtaining the URL is equivalent to obtaining the datato determine how secure it really is.

Recall that a secret sharing URL in-cludes the domain name of the storage server and the path of the resource on the server. For example, for Google Drive, the URL might be https://docs.google.com/open?id=0B02uz8F_ BS8C V DFOLW V h M m xh M3M , where docs.google.com is the server domain name and the remaining URL text is the secret query string. If Alice sends such an HTTPS link to Bob via a secure channel, and Bob follows it to access the shared data, at most only the public domain name will be exposed (during DNS query) to network sniff-ers; the remaining resource locator is protected by SSL against eavesdrop-ping. However, embedding secret infor-mation in a URL is still risky. There are many possible covert channels where the secret URL might be revealed.

Browsing logsIn the Internet, URLs are saved in log files on various servers (Web access or error logs, firewall logs, proxy logs, host or network-based intrusion detec-tion system logs, and so on). The CSP might protect the users outsourced data, but not necessarily the various log files (even the Web logs on the same physical server of the CSP). Usually, these log files arent well protected, or at least arent considered confidential. As a result, secret URLs will likely be saved in plaintext (as opposed to ci-phertext) in the log files and thus can later be divulged.

Note that in the case of Internet ac-cess via a proxy, even if the connection to the destination server is protected by SSL (as in the Google Drive ex-ample), the intermediate proxy server, independent of the CSP, can still re-cord in its log file the entire URL in plaintext.

Browser historyOn the user side, Web browsers save the entire URL, regardless of whether the fetched resource is cached. Conse-quently, there are several situations in which the URL can be leaked.

First of all, JavaScript Web appli-cations, exploiting history sniffing, could reveal the users browser his-tory to third parties.1 Malware thats not Web-based might also apply to this case.

Second, even as a trusted software ap-plication, the browser itself might send the browsing history to its software de-veloper for analysis or services (such as suggested sites2), which could cause in-advertent leakage of secret URLs.

Furthermore, many users dont clear their browsing history, even after they use a public computer (such as in an In-ternet cafe) to access the shared data.

Finally, when a user connects to a website incorporated with certain third-party analysis services, the URL might be sent in the referral request header.3 By checking this referrer, the website can learn where the request originated. Again, a third party can obtain the secret URL.

BookmarksBob might bookmark a secret URL sent by Alice securely. The URL will be stored in plaintext and might then be synchro-nized with Bobs other computers, be-cause browsers can save bookmarks in the cloud. Note that the CSP to whom Alice outsources her data (and performs secret-URL sharing with Bob) might not necessarily be the CSP involved in Bobs bookmark synchronization. Some users might even explicitly employ dedicated online bookmark services.

pc-12-04-chu.indd 55 01/10/13 2:02 PM


EdgE of thE Cloud

uRl ShorteningURL shortening, which we regard as an interesting intersection of two techni-cal trendsmobile and cloud comput-inghas become very popular. Even if the CSP doesnt shorten the secret URL, Alice can find many third-party services to shorten her secret URL to

be accessible on mobile devices before sending it to Bob.

In this case, the secret URL must be sent to a shortening service provider. Again, its not a good idea to send a secret URL to another party. More se-riously, to the best of our knowledge, no URL shortening service provider

protects the shortened URL with SSL. The shortened URL (which will be re-directed to the original secret URL) will be sent out in plain text both when Al-ice requests it and when Bob asks for the original URL, so its subject to eavesdropping.

Countermeasure SuggestionsTable 1 summarizes the identified weaknesses for the three major cloud storage services, and here we provide some suggestions to counteract poten-tial data leakagesome of which can be conveniently implemented without changing either the sharing mechanism or the user behavior.

The nondead URL is easy to fix. The file link should be invalidated when the file is removed. If the file is moved back, the sharing URL should be regenerated.

For uncertain identities, the sharing list can show the sharing information in more detailfor example, the original email address where Alice sent the invi-tation and the new address where Bob signs in, if they differ. Then Alice can figure out the identity of each person who shares her files.

To reduce the URL exposure possi-bility, the service provider should use different URLs for sharing and for the owners viewing. The data owner shouldnt refer to the secret sharing URL when viewing data, so an eaves-dropper (or over-the-shoulder at-tacker) cant obtain the URL from the owner side.

To the best of our knowledge, no shortening service supports SSL, so secret URLs shouldnt be short-enedeven if the service is provided by the CSP.

The file owner should be able to choose not to allow other people to see the sharing list of the shared file. This option could be added to the system easily.

To prevent unauthorized secret-URL resharing, no one should be allowed to generate a new sharing URL to reshare a file. Moreover, every invitation for

the AUThorSCheng-Kang Chu is a research scientist at the Institute for Infocomm Research in Singapore. His research interests are in information and network security, applied cryptography, and cloud security. Chu received his PhD in computer sciences from National Chiao Tung University, Taiwan. Hes on the founding editorial review board of the International Journal of Privacy and Health Informa-tion Management. Contact him at [email protected].

Wen-Tao Zhu is a research professor in the State Key Laboratory of Informa-tion Security (DCS Center), Institute of Information Engineering, at the Chinese Academy of Sciences. His research interests include network and information security as well as applied cryptography. Zhu received his PhD in communica-tion and information systems from the University of Science and Technology of China. Hes a member of the IEEE Computer Society and is a senior member of the China Institute of Communications. Hes on the editorial board of the Jour-nal of Network and Computer Applications. Contact him at [email protected].

Jin Han is a research scientist at the Institute for Infocomm Research. His cur-rent research interests mainly focus on mobile security and leakage-resilient password systems. Han received his PhD in information systems from Singa-pore Management University. Contact him at [email protected].

Joseph K. Liu is a research scientist in the Infocomm Security Department at the Institute for Infocomm Research, Singapore. His current technical focus is particularly lightweight cryptography, wireless security, security in smart grid system, and the cloud computing environment. Liu received his PhD in infor-mation engineering from the Chinese University of Hong Kong, specializing in cryptographic protocols for securing wireless networks, privacy, authentica-tion, and provable security. Contact him at [email protected].

Jia Xu is a research scientist in the Institute for Infocomm Research. Hes inter-ested in applied cryptography and cloud computing security. Xu obtained his PhD in computer science from the National University of Singapore. Contact him at [email protected].

Jianying Zhou is a senior scientist at the Institute for Infocomm Research, and he heads the Infocomm Security Department. His research interests are in computer and network security and mobile and wireless communications security. Zhou received his PhD in information security from the University of London. Contact him at [email protected].

pc-12-04-chu.indd 56 01/10/13 2:02 PM


private sharing should be responded to once only. After someone accepts the invitation and signs in with his or her account, the invitation link should be invalidated immediately.

If the cloud server moves a file de-leted by its owner to the trash folder, it should also disable the associated shar-ing options. A deleted file is one that the owner doesnt need anymore, so it shouldnt be shared anymore.

The URL shouldnt be fixed for all kinds of sharing methods. The CSP should regenerate the URL for a file when the file owner changes its sharing setting. This ensures that an old URL can no longer be used to access the file.

For the secret-URL sharing, one more effort the CSP can exert is to add password protection: in addi-tion to the secret URL generated by Alice, the CSP should provide a ran-dom password to Bob, who needs to additionally input the password to ac-cess the shared file following the secret URL. Even if the URL is exposed, an attacker without the password wont be able to access the file. The pass-word should always be under SSL protection, and shouldnt be recorded anywhere. Password protection can help alleviate indiscriminate URL ac-cess, nonHTTPS shortened URLs, and weaknesses in fixed URLs.

W e hope our efforts to highlight the need to better secure data shar-ing methods in existing cloud storage services will encourage further research and developments in this area.

AcknowlEDGMEnTSThis work was supported mainly by the Singapore A*STAR project SecDC-112172014 and in part by the National Natural Science Foundation of China under grant 61272479.

rEFErEncES 1. J. Dongseok et al., An Empirical Study

of Privacy-Violating Information Flows in

JavaScript Web Applications, Proc. 17th ACM Conf. Computer and Communi-cations Security (CCS 10), ACM, 2010, pp. 270283.

2. Windows Internet Explorer 9 Privacy Statement, Microsoft, Mar. 2011; http://windows.microsoft.com/en-GB/internet-explorer/products/ie-9/windows-internet-explorer-9-privacy-statement.

3. Referral Traffic, Google Analytics Help, 2013; https://support.google.com/analytics/answer/1247839?hl=en.

TAblE 1 comparison of security weaknesses of the three major cloud storage services

(identified weaknesses are marked with an X).

Dropbox

Google Drive

Microsoft SkyDrive

Nondead URL X

Uncertain identities X X X

Unauthorized resharing X (secret-URL sharing)

X (private sharing)

Indiscriminate accessing URL X

NonHTTPS shortened URL X X

No privacy on sharing X X

Sharing of trash files X

Fixed URL X

Selected CS articles and columns are also available for free at http://ComputingNow.computer.org.

Advertising Personnel Marian AndersonSr. Advertising CoordinatorEmail: [email protected]: +1 714 816 2139Fax: +1 714 821 4010

Sandy BrownSr. Business Development Mgr.Email: [email protected]: +1 714 816 2144Fax: +1 714 821 4010

Advertising Sales Represen-tatives (display) Central, Northwest, Far East: Eric KincaidEmail: [email protected]: +1 214 673 3742Fax: +1 888 886 8599

Northeast, Midwest, Europe,Middle East: Ann & David SchisslerEmail: [email protected],

[email protected]: +1 508 394 4026Fax: +1 508 394 1707

Southwest, California: Mike HughesEmail: [email protected]: +1 805 529 6790

Southeast: Heather BuonadiesEmail: [email protected]: +1 973 304-4123Fax: +1 973 585 7071

Advertising SalesRepresentative (Classified Line & Jobs Board) Heather BuonadiesEmail: [email protected]: +1 973 304-4123Fax: +1 973 585 7071

ADVERTISER INFORMATION OCTOBER-DECEMBER 2013

pc-12-04-chu.indd 57 01/10/13 2:02 PM

Documents

Security Concerns in Popular Cloud Storage Services