Dropbox Introduces 2-Factor Authentication | Hacker News Reader

Dropbox Introduces 2-Factor Authentication

dropbox.com

243 pointsXyzodiac74 comments

Try this: https://www.dropbox.com/try_twofactor

Although tray login still logs you in without the need to enter password or the code.

That worked, thanks! Also, I just discovered a checkbox under 'Account Settings' that seems like it's an opt-in for early releases. OP probably already had this checked?

Can't find that here. Care to post a screenshot somewhere? Anyone know how to enable this? Or if it can be enabled client-side at all?

here's the full context from dropbox forums: https://forums.dropbox.com/topic.php?id=66910

Not working for Martinique (FWI), country code 596. Still waiting for a SMS to come. Asked twice 5 and 10 minutes ago.

Maybe the country list should be edited to only list countries where SMS can be sent? (I have no problem with other 2-ways services I use)

Lack of SMS shouldn't be a problem. You can use two factor authentication with the app version.It's on that same page.

Yes but SMS are handy. BTW Just got both of them with a 7 hours delay.

Worked for me. In Norway, for those curious.

More details: https://www.dropbox.com/help/363/en

It looks like they support any app that uses the TOTP protocol, so google authenticator, among others, works with this seamlessly.

That's nice. A little context: TOTP is part of OATH - Initiative for Open Authentication - and is an open standard published as RFC 6238.

For those who don't have iOS/Android/BB and/or don't want to use Google Authenticator, Wikipedia lists a few compatible applications: https://en.wikipedia.org/wiki/Google_Authenticator

These work for Gmail too.

Is OATH related to OAuth?

nope! confusingly unrelated.

Tried adding something very close (RFC 2289) to busybox - discussion is still on http://comments.gmane.org/gmane.linux.busybox/36136

Finally gave up, considering how weird the idea seemed for most people. Glad that dropbox saw how interesting this is, especially in the light of the recent journalist hacks.

Hopefully, icloud will be next :-)

I'm glad they didn't invent their own mechanism but used standard OTP tokens, so you can just add them to apps like Google Authenticator.

This is very convenient, Google Accounts, Amazon AWS[1], SSH[2], and Dropbox, all from one simple app.

If Google Authenticator allowed to change the order of accounts without removing and readding them, I would have absolutely nothing to complain about.

[1] https://aws.amazon.com/mfa/faqs/

[2] http://askubuntu.com/questions/159727/how-can-i-use-a-passco...

In the iOS app, you can change the order by tapping 'edit' and then by drag and drop. The 'edit' button usually works if you tap and cancel the '+' button first.

I don't see any mention of 2-factor auth on the linked page. Maybe they're rolling it out in stages?

Seems like it to me as well, I don't see any options to do 2-factor auth on my settings page either. Maybe it's a pro feature right now?

It's available to all users. But since it's experimental, you have to go here to enable it:

http://www.dropbox.com/try_twofactor

Then it will appear under Security.

I upgraded my account, and now the desktop client is not letting me login, saying I need the latest client. I downloaded that and it still gives me the same error..

You'll need their "experimental build": https://forums.dropbox.com/topic.php?id=66910

That is pretty horrible UX. Why would they enable it in the web UI, but make you look at a forum post to get the build you need. Also, without linking to it when you get an error on the build?

The feature seems to have been released to forum users, then submitted here by a third party. I agree, though, there should have at least been a notification when the feature was enabled to read the forum post.

Does anyone know where I can download the latest Linux binary that support 2 factor authentication? I tried downloading the linux version, but it keeps on saying "this account uses two-step verification. To link to it, please download the latest version of Dropbox from www.dropbox.com/download". Maybe there is no new linux client, not sure.

Sorry for the confusion, this was a forum release. Linux build is here:

https://forums.dropbox.com/topic.php?id=66910

Well done. I wish more sites would move to using standard OTP protocols. I hate having to carry around and use a separate dongle for each company that provides two factor authentication.

Great, now only if they actually encrypted my files.

Put a truecrypt volume in your DropBox. Why rely on someone else to do the encryption?

If Dropbox were designed to handle sequentially-numbered blobs of encrypted data, changing one file would require your other devices to download only that file (an encrypted blob of roughly the same size).

With a TrueCrypt volume or other encrypted file solution on top of Dropbox, you have to resync the entire multi-GB volume any time a single file in there changes, since to Dropbox it's just one big file. (Another option is to use something like an OS X sparsebundle -- encrypted data banded across many files -- but God help you if you have two computers reading/writing from that sparsebundle at once.)

I've started using SpiderOak and it is quite efficient even though the data is encrypted such that the server admins couldn't see your data even if they wanted too. https://spideroak.com/engineering_matters SpiderOak also offers two-factor auth. (The SpiderOak UI, however, is fairly atrocious.)

If Dropbox were designed to handle sequentially-numbered blobs of encrypted data, changing one file would require your other devices to download only that file (an encrypted blob of roughly the same size).

But they do: store files and name them sequentially ;)

I think Encfs is the best solution, since it encrypts each file separately. Just mount the encrypted end over the Dropbox directory and the plaintext end somewhere else, and use it transparently.

Only part of a truecrypt volume changes when you make a change to the data within. Since Dropbox intelligently syncs files in parts, only part of a truecrypt volume has to be re-uploaded when something changes -- not the entire multi-GB file. I know because I do exactly this with a 1GB file. It takes about 2 minutes to sync when I unmount the file. Dropbox is not re-uploading all 1GB.

However, like the other commenter, I still recommend encfs for most uses.

Very interesting, I did not know that.

If you only have Macs, using an encrypted sparse bundle disk image is pretty simple, and changed files result in a small delta for dropbox to sync. It's built in and you'll be up and running in a couple minutes: http://matthew.mceachen.us/blog/free-easy-encrypted-storage-...

it is only simple if you always manage not to open such a sparse bundle on another Mac before it has been fully synced after being used on another Mac. Otherwise, you will mess up your sparse bundle sooner or later.

A service for syncing and sharing with built-in encryption might therefore me more convenient for most users. Spideroak and Wuala are two examples.

The downside, of course, is no differential sync'ing. So, if you make a change to your volume, you must re-upload the entire volume.

Worth doing for some files, yes, but still a pain. Per-file encryption would be ideal, but a monstrous pain to implement with TrueCrypt.

Dropbox is probably not crazy about widespread encryption because it would eliminate their ability to perform deduplication. Perhaps they could get around this if you had a special encrypted quota. For example, you have 5GB of space and 100MB of encrypted space.

If you only change a few kilobytes, dropbox only has to upload a few kilobytes.

I just modified a file in a 64MB truecrypt container and unmounted it. Dropbox took roughly five seconds to sync it.

The only real problem with truecrypt in dropbox is that you can't keep it mounted on multiple devices.

What do you know, you're right. I am impressed; I was under the impression that because of the encryption, Dropbox couldn't reliably determine what pieces changed.

Truecrypt is designed to work on a block-by-block basis or else it would be horribly slow at everything. So dropbox's job isn't harder than any arbitrary binary file with a few KB changing. Easier, really, since nothing changes size and shifts the data after it.

You would also lose easy access to file histories, correct? This is one reason why I'm a fan of SpiderOak -- the index remains encrypted, but file histories are still stored (efficiently).

Kinda defeats the purpose of DropBox. If you're going to use volume encryption, might as well use Tarsnap or something else to just backup the one large file.

The problem is on mobile/console/etc. devices.

Consider what your goals are with respect to encryption -- allowing the deltas generated by modifying your TrueCrypt volume will almost certainly make it easier for an adversary to break into your encrypted volume.

Are the algorithms used weak to that? I know that deltas will reveal the locations of changes and also let you detect whenever the same sector has the same bytes written to it. What else might be revealed?

You seem like you'd be appreciative of this service: http://getsecretsync.com/ss/

Get Boxcryptor.

Spideroak works pretty well for me as a secure Dropbox replacement :-)

If you want to get the most out of this, use a hardware token generator instead of a phone or computer. Example: http://hackaday.com/2012/07/11/time-based-one-time-passwords... http://lab.infoserver.com.br/wiki/index.php/Projects:arduino...

That looks like a software generator running on Arduino.

I stand corrected. The device is more of a physical/hardware token generator than a phone or computer in that it's stand-alone. Phones with radios permanently switched off or computers without network access are probably as secure.

Carrying a set of backup codes when travelling, generating a code for each app that is linked to your account...these things make two way authentication seem very inconvenient. I went with converting my gmail account to use two way authentication but after being informed to remember to carry a set of 10 backup codes when I am going to be without my phone, was a turn off and I reverted to my old settings.

Hmm, but I can still simply open someone's Dropbox folder locally if they forgot to logoff/switch on their computer...

That's hardly an unexpected security hole - most of my devices maintain local copies of everything in my Dropbox folder (phone/iPad excepted). Requiring password/two factor auth to get at the cloud hosted version of something in the local filesystem would achieve pretty much nothing.

Maybe there's people using Dropbox in some other fashion, but surely this is the intended/common use case?

That requires physical access, which is arguably more secure than internet access should your credentials be compromised. This is a major step in the right direction for Dropbox. I don't think it's Dropbox's job to encrypt and secure my local files. This would break many use cases, and there are other purpose-built solutions for this.

Dropbox made their business on an extreme convenience (your files everywhere through a dead-simple, familiar interface). Inconveniently, convenience is often the enemy of security. It's a "good thing" that Dropbox is now offering some granularity over the convenience/security spectrum.

My security codes aren't working (invalid). Using Google Authenticator.

Anyone else have this issue?

Yup, have the same issue, went with sms-version because of this ;(. Google Authenticator on HTC Desire HD with custom ROM

When I first used Authenticator I had this problem, because the clock on my phone was a couple of minutes out of sync.

There is room for some error but it is worth making sure the time on your phone is correct.

Yeay, now I can have a really secure login to my insecure files?

Two-Factor authentication sucks. It's too hard for users. Most people will never us it. Dropbox should consider using Rublon (yes, that's my startup): https://rublon.com

7 reasons why you should add Rublon to your website: http://blog.rublon.com/2012/why-add-rublon/

This is neat but only requires a phone, there's no second factor.

Right now the second factor can be the PIN code that you set up for your phone. Soon we'll add an optional intelligent PIN option for the app itself.

How entering 6 digits hard for users?

You have to log in with your username and password first and then you have to enter another password (those digits that you're talking about). With Rublon you just scan a Rublon Code and that's it.

So you've invented one-factor authentication?

But in another post, you say that you are planning to add a second factor to Rublon, so that the user must enter a PIN when scanning the Rublon code. So it doesn't appear to be any more convenient that Google Authenticator, which is widely-supported, produced by someone I trust, and open source.

The idea of using QR codes for authentication is interesting, but I would be very careful in selling this as a highly-secure system that is capable of replacing two-factor auth.

To me, this appears no more secure than leaving a copy of your password in plain text on the phone - if someone gets access to your phone, they have access to all of your Rublon accounts. Compare this to Google Authenticator - in the same scenario, the attacker would still need to know my password as well as the token.

how is the phone not a second factor?

Rublon replaces passwords with cryptographic keys that are partially stored on your phone. This is a completely new approach to user authentication.

It's not a completely new anything, it's a password on your phone.

Because there is no first factor. You don't log into Dropbox or Google with only your OTP, you use a password and OTP. With the method above, you scan a code with your phone instead of using a password or OTP.

> Two-Factor authentication sucks. It's too hard for users.

It must be easier to build a startup on the assumption that your users are incompetent mouthbreathers. Respecting your users is hard work :-/

I've never heard of Rublon before now, but this post has started me off with a pretty negative impression.

I'd suggest you work on your elevator pitch a bit more.

This completely misses the point of Two-factor authentication, though.

Two-factor authentication is all about increasing security by combining two separate factors: something you know (password), and something you have (phone). From what I can tell, you're just switching from relying on one factor (password) to relying on the other factor (phone). It's just a different one-factor authentication paradigm.

Unfortunately, this leaves several gaps. For example, what happens when I lose my phone, or someone takes it from me? Can that other person log in immediately?

I can potentially understand an argument that this is more secure than solely password-based solutions (although I don't think it would be for me, where I use complex random passwords), but I certainly wouldn't consider it an alternative to two-factor authentication.

1) Screw outsourcing your authentication database to a third party, or incorporating third-party JS, as a mandatory thing. It's ok if you build something (like OATH) which allows a third-party service provider, but it shouldn't be mandatory; you should be able to implement the entire thing on your own infrastructure, and ideally play nicely with other sites in a user-selected client (potentially a browser).

2) I'd rather just do N-factor using a client cert stored in the web browser (mobile or desktop), combined with a password. x509 is probably terminally defective in desktop browsers due to historical accident and a messy protocol, but it could work on mobile, and stuff like OneID or BrowserID could meet the same need for regular browsers.

I don't believe in desktop + cellphone both being required to log into every site every time. The OATH compromise (using the phone periodically, along with a desktop password, and caching something in the browser) is an acceptable compromise for some apps.

Ultimately what I want is trusted keystore of asymmetric private keys on devices, and then multifactor auth to the keystore (biometric, password, location/time based heuristics, etc.), and reasonable management of keystores and keys (so I can for instance revoke every key on my phone if stolen, or disallow ipad and iphone but not mba13 for dropbox, but allow all 3 for linkedin)

The technical problem is relatively simple; it's an integration program (the auth libraries used by every site, plus mobile OSes, maybe desktop OSes, and hardware in phones and computers).

Give users the ability to make their own choices, and let sites establish minimum standards as well. I should be allowed to make a site depend on fingerprint swipe + physical location + specific machine if I want, but it shouldn't be mandatory for a random game site for everyone/anyone.

Thanks for your opinion guys. Looks like we'll have to invest much more time in creating a new website that will explain Rublon more precisely. I can see that there is way too much confusion and misunderstanding about the product.

How about this for a novel idea. Stop inventing new mechanisms for autentication, and let ME choose how I authenticate myself to your service (to gain access to MY data). http://ragmondocom.appspot.com/2012/03/My-Stuff-My-Lock

Reply on news.ycombinator.com