Dropbox Introduces 2-Factor Authentication(dropbox.com)
dropbox.com
Dropbox Introduces 2-Factor Authentication
https://www.dropbox.com/account/security
15 comments
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)
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.
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?
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.
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.
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.
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 :-)
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...
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.
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
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.)
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.
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.
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.
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.
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.
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.
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).
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.
[deleted]
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.
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?
The problem is on mobile/console/etc. devices.
Spideroak works pretty well for me as a secure Dropbox replacement :-)
You seem like you'd be appreciative of this service: http://getsecretsync.com/ss/
Get Boxcryptor.
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 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.
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.
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?
Maybe there's people using Dropbox in some other fashion, but surely this is the intended/common use case?
My security codes aren't working (invalid). Using Google Authenticator.
Anyone else have this issue?
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.
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?
[deleted]
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/
7 reasons why you should add Rublon to your website: http://blog.rublon.com/2012/why-add-rublon/
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.
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.
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.
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.
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.
I'd suggest you work on your elevator pitch a bit more.
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 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.
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.
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.
So you've invented one-factor authentication?
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
[deleted]
how is the phone not a second factor?
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 :-/
It must be easier to build a startup on the assumption that your users are incompetent mouthbreathers. Respecting your users is hard work :-/
Although tray login still logs you in without the need to enter password or the code.