Archive for: August, 2012

What IT Really Does

Unfortunately, not many people really understand all the amazing work that goes into systems administration, network engineering, technical support, computer security, and all of the other IT related disciplines.

Businesses these days are extremely reliant on technology, and most people take for granted that they can show up at the office in the morning and their email Just Works™.  But beneath the covers there are so many little things that need to be impeccably configured in order to make everything seem simple.

And the infrastructure that keeps everything running smoothly is becoming increasingly more complex.  With each day that passes there are more platforms to support, more devices, more software, more employees, more hackers, and most importantly more data.

More data, more problems, right?

Every day we create 2.5 quintillion bytes of data that we have to process, manage, protect, backup and move. In our recent data and domain migration survey we compiled some fascinating results that we’ll be sharing very soon about how much time and effort IT pours into migrations alone.  If you’re in IT, you might not be shocked because you live it every single day, but CEOs will probably be floored.

Luckily, there are people in the business world that appreciate IT.  Some might even celebrate Systems Administrator Appreciation Day.  For the rest, well, rather than give you advice on how to explain what it is you really do, I offer a bit of comic relief. Enjoy!

 

Case Study: City of Buffalo

Located in western New York, Buffalo is the second most populous city in the state of New York (after New York City) with a population of 261,310, according to the 2010 census. Its municipal government provides network resources for the 8,000+ employees, encompassing various departments, from its emergency services including the Police and Fire Departments, to its Municipal Housing Authority.

In the words of City of Buffalo’s systems administrator for network security and communication, the challenge it faced was not dissimilar to any other organization, “We have too many windmills and not enough Don Quixote’s. As far as our network security went, we were hard on the outside and soft on the inside, and this needed to change.”

The IT team refers to City of Buffalo’s Active Directory as a ‘bit of a basement and that, since using DatAdvantage, they’ve managed to turn it around into a very effective, efficient and intuitive warehouse. He adds, “The thing with Varonis is it gives you that stand off capability but then allow you to almost instantly come in and work to a fine gradient of detail that, without the product, would take hours and hours.”

Find out how Varonis® DatAdvantage® is helping the City of Buffalo clean-up their permissions and audit access activity efficiently

Click here to see the complete case study.

 

Near-Field Authentication over Avian Carrier

I read about “chirp” the other day – a new iPhone app that lets you share pictures andChirp
links from your phone with an audible tone that sounds like—surprise—a bird chirp.

Here’s how it works:

  • You open up the chirp app on your iphone or ipad
  • You select a hyperlink, a note, or a picture that you want to share
  • The item is uploaded to chirp’s servers (somewhere in the cloud)
  • You hit the chirp button
  • Anyone else whose phone/tablet: 1) is within audible range, and 2) happens to have the chirp app open – will receive the chirp
  • If they’re online, chirp will automatically download your item for them to see
  • If they’re not online, they can download it later

Chirp starts “listening” for other chirps as soon as you open the app, so if you have a bunch of people chirping away in the same place, you should see a stream of shared items.

It seems like an easy way to share digital items with one or more nearby people, and only those that are physically nearby (as opposed to on a network together). Not that people will be sharing sensitive things necessarily, but it’s an interesting form of authentication – only phones in an audible range with the chirp app open will be able to receive the chirp.

From a functionality standpoint, there’s no need for an email distribution list, no need to pair with Bluetooth or “bump” your phones together, no GPS or cellular location awareness required.  It’s also more aesthetically pleasing and takes less coordination than a QR code.

If your phone is within “earshot”, you can share stuff.

Be careful whose chirps you choose to receive though—it’s conceivable that a chirp could deliver a link to a hijacked website that delivers malicious code to your device. Right now it looks like it’s up to you to authenticate the sender.

Musing a bit on what could come next by extending the idea…

First, a future version of the app could (conceivably) become persistent, meaning your phone might be listening for chirps all the time, and there would be a little queue of chirps waiting for you when you decided to look. Perhaps there will be an app that can merge chirps with tweets.

With a persistent chirp app, you’ll be at a party where people are taking pictures with their phones and they’ll chirp them as they take them so you can view them later without having to be their Facebook friend.

You’ll be walking down the street and stores will chirp you coupons. When everyone starts wearing Google glasses later this year your chirp feeds will fill up with localized information like advertisements, landmark descriptions, public service messages, and a million other things you probably won’t want.

Sounds noisy.

Next innovation:  make chirps inaudible to humans, and/or to people older than 20 (e.g. Stealth Tone). We won’t scare birds, we might stay a little saner, and it’s more mysterious.

If you’re a spy, or doing a scavenger hunt, when you get to your secret drop thingy or have scavenged the right area you’ll just open up chirp to get the next clue.

So next we’ll need little battery-operated chirpers that can be hidden under a park bench or placed on top of a statue somewhere. They’ll either chirp when you press a button or chirp intermittently every few minutes.

For a more practical use, what if the police need to find someone in a busy train station or airport and Eagle Eye is down? They could just chirp a photo or a description over the loud speaker—everyone in the station might aid in the search.

What’s clear is that there is still a lot of innovation going on to share content, as quickly and easily as possible, with the people you want to share it with. In a business meeting in the future, someone might just chirp you a copy of their presentation. Careful though—others might be listening.

Vote Now on the Finalists for the 2012 Varonis Data Governance Awards

In May 2012, Varonis launched its first customer awards program – the Varonis Data Governance Awards. Entry has now closed, and we are delighted with the response we received and the outstanding strength of the different entries. We have reviewed the entries and selected our shortlist.

The judging panel is made up of independent industry experts and Varonis executives who will be meeting over the coming weeks to review the shortlist and decide the winners. We also want to give visitors to our website the opportunity to have their say by casting their vote for the entries they feel most deserve success.

Vote Now!

Social Engineering in the Enterprise

Spy vs. SpyIn light of Mat Honan’s harrowing story, where both Apple and Amazon fell victim to social engineering attacks attributable to profound weaknesses in their identity verification processes, the billion dollar question becomes: how vulnerable are your company’s internal processes to social engineering?

Have you ever called the IT help desk for a password reset?  What do they ask you in order to verify your identity?  Your name and department?  Your boss’s name?  A badge number?

Hopefully Mat’s story will prompt security teams at companies of all sizes to take social engineering very seriously.

What can we do?

One highly effective tactic to help guard against social engineering is to carry out benign social engineering and phishing attacks on staff members.  Just as we learn from being burned on a hot stove, hacking staff members in a simulation may help educate them on what to look for.

Unfortunately, because we are humans, some people will be fooled at least some of the time, so we need to make sure that we minimize the risks when that happens. That’s where the principle of least privilege helps.

One example of where organizations may be vulnerable to both social engineering and an inability to ensure least privilege is in its authorization processes. IT is often in the position of granting access to data without having the required knowledge of who really should have access.

Call your help desk and tell them you’re the new Associate Head of HR and need access to payroll data and the payroll processing application.  You might just get it. And when would that inappropriate access be reviewed, caught, and revoked?

This is precisely why Varonis is emphatic about data ownership and authorization processes.   If all access requests for HR data are routed to someone in HR, the likelihood of someone mistakenly doling out excessive or flat-out wrong permissions is dramatically reduced. If HR staff regularly reviews access (even better with the assistance of automated recommendations), the likelihood of inappropriate access drops even further.

These are just some of the precautions we can take in along the path to least privilege, and better security.

As Mat stated in his follow-up post:

“As more information about us lives online in ever more locations, we have to make sure that those we entrust it with have taken the necessary steps to keep us safe. That’s not happening now. And until it does, what happened to me could happen to you.”

This also holds true for our business data both in the cloud and behind the firewall.

Photo credit: Tony Fischer

Complete our Data Migration Survey for a chance to win a 13″ Macbook ...

You know the feeling – you get a brand new, shiny, screamingly fast NAS for your data center.  Everyone’s excited to plug it in.  Then reality hits.  Now you have to plan a migration.  Buzzkill.

Every time I talk to a sysadmin or storage pro about what their biggest headache is, the answer is almost universally: migrations.  It’s like going to the dentist – we know it’s going to be painful, but we have to do it.  And it’s a routine thing.  It never ends!  We’re always buying new hardware and decommissioning old stuff, consolidating domains (due to M&A or otherwise), archiving stale data, etc.

Our bosses think it’s easy – “just move the data” they say.  But we’re going across domains, from Windows file shares to SharePoint, and we have to complete the process within 36 hours without causing a blip on the radar.  Cue Mission Impossible theme song.

Varonis is conducting a survey to learn how you’re doing migrations today, where your pain points are, and how big a problem data and domain migrations are for your organization.  The data will help us create free resources to help you in your data migration planning and execution.  Plus, you could win a new 13″ Macbook Air (which you’ll have to migrate your personal data to!).

Take the Survey!

The Definitive Guide to Cryptographic Hash Functions (Part II)

Last time I talked about how cryptographic hash functions are used to scramble passwords.  I also stressed why it is extremely important to not be able to take a hash value and work backwards to figure out the plain text input.   That was Golden Rule #1 (pre-image resistance).

But if hashes can’t be reversed, why do we always hear about passwords being cracked?  And why the heck are people always telling us to create really complex, hard-to-remember passwords?

Does Password Size Really Matter?

In Part I, you saw that both “dog” and “the eagle flies at midnight” generated MD5 hash values of the same exact length.  What’s more, the hashes are equally hard to reverse.  So what makes weak passwords weak? Answer: Brute force attacks.

Brute Force Attacks

Brute Force

Instead of reversing the hash of your password, I can simply keep trying different inputs
until I guess one that generates a hash that matches yours.  (Remember: the hashing algorithms are public). This is called a brute force attack and it can be very effective at cracking weak passwords.  (In fact, thanks to my spotty memory, I brute force my 4 digit garage door code almost every day.)

A weak password that is just 3 lowercase alpha characters (e.g., “dog”) requires a maximum of 17,576 times to generate a match.   An attacker can further reduce the number of guesses by limiting it the “guesses” to the most likely candidates, like 3 character words that exist in the dictionary (try “dog” but don’t try “fgz”).  This variation is unsurprisingly called a dictionary attack.

In contrast, if a password is 8 case-sensitive alpha-numeric characters (e.g., “d0G5Fr0g”), an attacker has to guess potentially 218,340,105,584,896 times.  No thanks!

Rainbow Tables

Generating billions of password hashes can be time-consuming and computationally expensive.  As a result, crackers sometimes use rainbow tables – gigantic, pre-computed tables of hash values for every possible combination of characters—to speed up the cracking process.

Rainbow tables take a really long time to generate, but once they’re available (e.g. at freerainbowtables.com), they can help attackers find a match for a given hash in seconds versus hours, days, or months if they have to compute all the hashes themselves.

It should be obvious by now that the more complex your password, the less likely its hash will be in a rainbow table.  Some of the most effective rainbow tables available are ones that contain hashes of common dictionary words, so never, ever use dictionary words as your password!

So, given that brute force attacks and rainbow tables exist, aren’t we all vulnerable?  Fear not, my friends.  Part III will feature a rather tasty solution (salt).

Photo credit: Jeremy Thompson

My Grandmother Uses Dropbox — Why can’t I?

My first involvement with tech occurred in the early 80s. I recall the days of modems, time division multiplexors, acoustic couplers, and dipswitches.  Most people don’t realize it, but cloud based file sharing existed in the 80s, but required an account with a major X.25 “cloud” service provider, such as Tymnet or Telenet.

At the risk of sounding nostalgic, back in the day, only people who had a keen interest in electronics (mainly, those of us under 30) were exposed to these esoteric products.  Neither my grandmother nor my mother understood technology and, frankly, I never tried to explain it to them.  It was a language that only a privileged few could understand. That has certainly changed.

Today, grandma owns an iPad, has a Twitter account, does her banking online, and knows what megapixels are. She texts, tweets, and takes pictures…lots of pictures.  She happily uses the modern cloud to post pictures on Dropbox so her niece—who is going to school for archeology in the Middle East—can see the scarf grandma is knitting her for Christmas.

So, if grandma can use Dropbox, WHY…CAN’T…I?

That’s a question that business areas are asking IT professionals on a daily basis.

In order to answer the question, we need to examine why grandma is using Dropbox.  Simply speaking – it’s easy to use.  Grandma logs in with her username and password, drags and drops her scarf photo, and voila, her niece can download and view the picture almost instantly.

Unlike previous X.25 cloud services like Tymnet and Telnet, current cloud-based file sharing services, including Dropbox, have done a fantastic job adhering to the mantra – “Simplicity as a Design Goal.”  Many other consumer-oriented services and products also have gained widespread adoption following the same blueprint – e.g., the iPod.

So, when the person who runs the HR Department comes to you and tells you that she’ll be using Dropbox to share employee information with a vendor (just as easily as she shares her family photos), what do you tell her?  And, more importantly, what alternative can you provide her for sharing sensitive information with third parties?

Here’s a list of 5 tactics you can use:

1. Explain that consumer-oriented web sites don’t provide the same level of protection as modern enterprise IT systems.

2. Explain that while protecting pictures of a scarf with a username and password may be appropriate, protecting data which contains an employee’s social security number, home address, and medical information deserve more than password protection.

3. Explain that data breaches occur on a regular basis on cloud based services and losing data can cause irreparable harm to a corporation.

4. Explain that regulatory requirements force many companies to review entitlement on an ongoing basis, to verify access by auditing data use, and to encrypt certain types of data. Most cloud-based file sharing services do not allow for these types of controls.

5. Explain that there are alternatives! Specifically, there are products that can provide similar functionality, that are easy to use, that can be used to share both employee records and pictures of a scarf, without sacrificing security.

Interestingly enough, according to a 2010 report, the fastest growth on social networking sites came from internet users 74 and older.  Enough said.  Now please excuse me while I go play Pong.

Image credit: http://en.wikipedia.org/wiki/File:Televideo925Terminal.jpg

Lessons Learned from Mat Honan’s Epic Hacking

” Password-based security mechanisms — which can be cracked, reset, and socially engineered — no longer suffice in the era of cloud computing.”

If you haven’t read Gizmodo writer Mat Honan’s gut-wrenching play-by-play of how his entire digital life was evaporated in the matter of hours, do yourself a favor and Instapaper it. Or, if you’re too busy to read the whole article, I’ve created a quick-and-dirty summary that retraces the hacker’s steps and highlights some steps we can take to protect ourselves from similar attacks.

How It Happened

1.) Hacker targets @mat via Twitter

2.) Hacker browses to @mat’s personal website, which is linked from his Twitter profile

3.) Hacker sees @mat’s Gmail address on his website

4.) Hacker tries to login to Gmail using @mat’s (knowing he won’t get in)

Hmm, if the hacker can’t break into @mat’s Gmail account, why is this important?

When you tell Gmail that you’ve lost your password, it responds by showing you the partially obscured alternate email address it has on file for account recovery.

This is a big hole. Why? Because m***n@me.com was enough information to know which service to attack next – iCloud, which, as you’ll see in a minute, is extremely vulnerable to social engineering.

It’s worth noting that, as @mat mentions in Wired, if Gmail’s two-factor authentication was enabled, the nightmare ends here. Hopefully Google will figure out a better mechanism for securing your alternate email account other than blanking out a few characters (a security question would be a good start!).

Email is the skeleton key to your online identity since so many services reset your account via a confirmation link sent to your email address.  Guard it well.

How can you protect your Gmail account?

Go enable two-factor authentication for your gmail account…now! Jeff Atwood wrote an excellent tutorial for Gmail in his Make Your Email Hacker Proof post and Matt Cutts posted a video today.

5.) Hacker obtains @mat’s billing address by doing a simple WHOIS lookup on his website’s domain name

I can’t really ding @mat here since, as he points out, most peoples’ billing addresses are obtainable via WhitePages or a similar service unless you’re unlisted, which isn’t a bad idea. If you own a domain name, think about paying the extra $20/year for private registration.

6.) Hacker obtains last 4 digits of @mat’s credit card

Why was the hacker after the last 4 digits?  Because this was the last piece of the iCloud-cracking puzzle. In order to verify your identity, AppleCare phone support requires: 1) name, 2) email,  3) billing address, and 4) the last 4 digits of the credit card on file.  The hacker already had 3 of the 4.

Where might someone’s credit card number be stored? Amazon!

The hacker (correctly) assumed that @mat had an Amazon account that used one of his two known email addresses as the account name.  But how did the hacker gain access?  Hint: he didn’t crack the password.  He used social engineering.

The hacker placed a call to Amazon tech support claiming to be @mat.  He provided his name, address, and email (yikes!), and then asked the tech support rep to add a new credit card number to the account. Then he hung up the phone and waited.

Later, the hacker placed a subsequent call to Amazon saying he lost access to his account. Upon providing name, address, and the newly added fake credit card number, Amazon support let the hacker add a new email address to the account (e.g., hacker@danger.com).

Game over.

The hacker could now click “forgot password” on the Amazon login page and the subsequent password reset email would go to hacker@danger.com instead of @mat’s real email address.  Having reset the password, the hacker then logged into the Amazon account and nabbed the last 4 digits of the real credit card on file.

@mat notes:

“And it’s also worth noting that one wouldn’t have to call Amazon to pull this off. Your pizza guy could do the same thing, for example. If you have an AppleID, every time you call Pizza Hut, you’re giving the 16-year-old on the other end of the line all he needs to take over your entire digital life.”

How can you protect your Amazon account?

Until Amazon rethinks their identity verification process, the only way to protect against this social engineering hack is to delete any credit card data you have on file with Amazon. Yes, it’s painful to have to enter your credit card information every time you place an order, but is it as painful as having your digital identity stolen?

Let’s recap: Hacker grabs public information: name, gmail address, billing address.  Gmail’s login system reveals that @mat has an AppeID (m***n@me.com).  The hacker knows that in order to own that AppleID the only missing piece is the last 4 digits of @mat’s credit card, which can be socially engineered from Amazon support.  Whew.

Still with me?  Good.  Here’s where it gets really ugly.

7.) Hacker calls AppleCare with the information required to infiltrate an iCloud account: name (public), email (public), billing address (public) and last 4 digits of a credit card (virtually public).

How can you protect your AppleID?

Apple requires you to have a credit card on file if you want to use iTunes and the App Store, so deleting your credit card data might not be a viable option.  However, you could dedicate a single purpose credit card for Apple.  If the card @mat stored with Amazon didn’t match the card stored with Apple, the attack would have stopped here.  Regardless, Apple needs to seriously rethink their identity verification process.

8.) Hacker remote wipes @mat’s iPhone, iPad and Macbook Pro

There are more security steps involved to opt into a MailChimp newsletter than to remotely decimate an entire laptop. The way iCloud’s remote wipe process was designed leads me to believe they didn’t even think through the possibility that an iCloud account could be hacked.

How can you protect your data?

Backup your data. No excuses. Have multiple backups and test your restores. You can get a 2TB external hard drive for $120 on (wait for it…) Amazon, and online backup services are a few bucks a month for unlimited data. (Anecdotally, the only hard drive failure I ever experienced was 1 day after my very first online backup completed. Most people aren’t so lucky.)

So many systems are interconnected in the cloud making things more convenient than ever before, but we have to realize that this same interconnectedness makes security exponentially harder.  Passwords are no longer good enough—not for the important stuff.  If Apple, Amazon, and (too a much lesser extent) Google—companies with a combined market cap of 900B—can’t get security right, what are the lesser known providers doing?

The Definitive Guide to Cryptographic Hash Functions (Part 1)

Give me any message and I will create a secret code to obscure it.

Try it!


Try another one.

MD5 Hash

This is called hashing—a technique often used to secure passwords (among other things).  Instead of keeping your secret, “dog”, in plain text for everyone to see, I’ll store the ugly 32-character code (the code is commonly called a hash).

Do I have to remember 06d80eb0c50b49a509b49f2424e8c805?

If I don’t keep the original plain-text password on file, how do I verify your password when you try to login?  In other words, how does authentication happen?

It would be silly if I forced you to remember 06d80eb0c50b49a509b49f2424e8c805 every time you wanted to use your password.  Instead, whenever you give me the password “dog”, I will run that text through my hash function and compare the result to the hash I have stored in my database.  If it matches, you’ve authenticated successfully.  Hooray!

Crucially, this only works if my hash function always generates the same output for a given input (in this case, “dog” always produces to 06d80eb0c50b49a509b49f2424e8c805). No exceptions.  Cryptographic hash functions are not random.

All your hash are belong to us

The benefit of hashing is that if someone steals my hash database, they only make off with the hashes and not your actual password.  Unless the hacker was able to reverse the hash values, they’re useless.  Luckily for us, one of the golden rules of cryptographic hash functions is that they must be irreversible.  That is, you mustn’t be able to look at 06d80eb0c50b49a509b49f2424e8c805 and figure out the input was “dog.”

In fact, the requirement is even stricter – you mustn’t be able to look at 06d80eb0c50b49a509b49f2424e8c805 and be able to find any input that would generate that same output.  The fancy term for this requirement is “pre-image resistance,” which leads us to our first golden rule.

Golden Rule #1 – Pre-Image Resistance

A cryptographic hash function must be pre-image resistant—that is, given a hash function and a specific hash, it should be infeasible to find any inputs that generate that particular hash.

This is important for password security because it becomes virtually impossible for anyone to find your password (“dog”) or any other password that would hash to the same value (06d80eb0c50b49a509b49f2424e8c805) and thus give them access to your account.

The SHA-2 hash function is pre-image resistant.  Don’t believe me?  Here’s the SHA-2 hash of my LinkedIn password:

5c84260bcfde21e071a43fab2f6cc5c328569ea5d78aeefa156f1f1b206268b4

See you in a few millennia!

But why are hashes irreversible?

I’m going to let you in on something that is going to make this conversation even more interesting—the cryptographic hash functions that many people use—including your bank—are completely public.  Anyone can get hold of the source code and see exactly how these functions work, yet the hashes are still irreversible.  Why??

Think of a secure hash like grandma’s meatballs—you can’t take one of her meatballs and deconstruct it back into the exact quantities of meat, cheese, water, oil, and breadcrumbs grandma used because that information was destroyed during the cooking process.   What’s more, it’s theoretically possible that multiple variations on grandma’s recipe could produce identical meatballs.  So, given any one meatball, you wouldn’t be able to tell which recipe variation produced it.

Too abstract?  Let’s get a little more concrete.

Pick a random number and divide it by two.  Now write down the remainder.  You’ve got either a 0 or 1.  Now, could you take that 0 or 1 and work backwards to figure out the original number?  That would be really hard to do since an infinite number of inputs—i.e., any even or odd number—could produce a 0 or 1 respectively.

Irreversibility is only the beginning

There’s a real problem with our over-simplified hash function above.  It is a hash function, yes, but it’s not a cryptographic hash function.  Can you see why?

While the hash produced is irreversible, it’s not pre-image resistant!

Given the hash value of 0, I can very easily produce any number of inputs that produce that hash: 2, 4, 6, 8, 10, etc.  While I can’t work backwards to find your exact input, I can quite trivially find another input that maps to the same hash and, remember, when I’m authenticating I only care about comparing hashes.

Unfortunately, even when systems use cryptographically strong hash functions, there are ways for hackers to penetrate defenses.  In Part 2, we’ll talk about brute-force attacks, dictionary attacks, and rainbow tables (warning: they’re not as innocent as they sound).

Go to Part II →

Dropbox – Please Reset Everyone’s Password

Yesterday, Dropbox confirmed that they were indeed hacked.  They issued a blog post explaining:

Our investigation found that usernames and passwords recently stolen from other websites were used to sign in to a small number of Dropbox accounts. We’ve contacted these users and have helped them protect their accounts.

Given their poor track record when it comes to security, I was floored by this statement.  They are assuming they know exactly which accounts were compromised.  What about the accounts whose passwords might have been stolen but haven’t been breached (yet)?

LinkedIn made the same mistake a few months ago—they only reset the passwords for the accounts they believed to be affected.  What did they base this on?  The list of hashes that were published BY THE HACKERS?  Is it beyond the realm of possibility that the attackers might not have published the whole list?  They’re HACKERS!

Zappos, on the other hand, took their medicine.  They said, “We know it’s a royal pain, but we don’t really know exactly which accounts are at risk, so we’re resetting them all.”  While it was a pain, this made at least one customer  (me) feel like Zappos was taking security seriously.

Another unsettling thing is that apparently a Dropbox employee was storing customer data in their own Dropbox account.  That blew my mind for the second time in the same morning.

Here’s what we can deduce from what the company has disclosed:

  • Dropbox stores at least some customer information in Dropbox  in folders that are accessible by at least one employee
  • At least one Dropbox employee uses their Dropbox password somewhere else
  • Dropbox is taking the same road that LinkedIn took by addressing only the problems they know about. What about what they don’t know they don’t know about?

This raises some disturbing questions:

  • What other customer information is stored in Dropbox folders? Credit card data? Passwords?
  • Which employees have access to customer data?
  • Of the employees that have access to customer data, how many of them re-use their passwords?

A least it’s not all bad.  Some good news is that Dropbox is introducing:

  • Two-factor authentication
  • Automated alerts on anomalous behavior detection
  • A visible audit log of account access

These features are critical– the ability to determine, at all times, who has access to data, who is accessing data, locating sensitive data, and using automation to monitor use and flag potential abuse. (This is what the Varonis Data Governance Suite is all about).

These security measures will prove crucial for Dropbox to recover from their recent woes and gain any kind of traction with businesses.  In fact, in our recent cloud collaboration survey, a vast majority of organizations said they would love to use something like Dropbox for collaboration if they felt it was as secure as their internal networks.

The bottom line is, when you have a breach, always assume the worst case scenario.  Dropbox may be risking another breach from the same attack rather than inconvenience their users by forcing a password reset.  That’s a really curious decision.

Needless to say, if you’re a Dropbox user, go reset your password. You might also want to heed Marco Arment’s advice and treat Dropbox as a public repository.