Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

There's a lot of data people need to sync and share that is confidential enough that you don't really want it to leak out, but still not that secret that it's the end of the world if it does. You know, the kind of data you would be perfectly comfortable letting a reasonably big and relatively trustworthy service manage for you.

And if that service gets even more secure, you can rest easy knowing that if the data does leak out, it's not because you where careless with your passwords, and thus you have someone

You're talking about Dropbox, the service that accidentally during a code push made it so that a user's password wasn't needed to get at their Dropbox files, and managed to get an extract from their user database stolen. I don't call that "a proven track record of security and reliability", unless you mean a bad track record.

Someone will hack them and will export the shared secret used for RFC 6238 TOTP: Time-Based One-Time Password Algorithm [ietf.org]. Two factor authentication job is to protect the user, It doesn't make Dropbox security practices better, and they already demostrated are bad

Dropbox wasn't hacked in the prior attack. Also, in a successful attack now you have two different products you have to find a security exploit on. Just throwing up your hands and saying 'everything can be hacked' isn't a security methodology.

The problem is that in the Dropbox company it was fine to just make a drop box account with some password that you reuse elsewhere. That is the fundamental problem. They don't have their employees use KeePass, or 1Password or something similar and generate random passwords that they change routinely, or any of these other security practices that would have prevented this attack without the two factor authentication.
Dropbox is a huge target and does not have the expertise to play in that league (evidenced by the fact that they needed outside help to figure out this attack). I think the two factor authentication is a good thing, but if they think "OK, problem solved" then it is not helping them. There is no replacement for good security practices, especially in a company with such a high profile.

Someone will hack them and will export the shared secret used for RFC 6238 TOTP: Time-Based One-Time Password Algorithm [ietf.org]. Two factor authentication job is to protect the user, It doesn't make Dropbox security practices better, and they already demostrated are bad

Although I fundamentally agree that the underlying issue is their security practices (or lack thereof), this does address the specific recent hack (of an employee of theirs reusing the same password on Dropbox as on another account with another company that was compromised), and is a good idea regardless. I wish more sites did it.

It's in Debian repositories (And probably Ubuntu.) You can download it yourself [googlecode.com] and integrate it into anything that supports PAM.

I have my code on both my phone and iPod touch so I always have something on me that can generate the code. The 'backup codes' are in a safety deposit box with other documents. Not sure if it actually is secure but it feels a bit more secure knowing that to get into my home server you have to have both my password and one of my devices. (And if I lose one I can easily generate a new key).

It makes a QR-code in the bash terminal that you can take a picture of with your devices.

How well does it work with stuff that uses ssh but doesn't actually use openssh in a terminal to do it? For example, some nice GUI application that lets you access your home directory via ssh, or nx/x2go, etc. That would be my main concern with it. I'd also prefer not to have to use it if I was using RSA - that essentially is a two factor process already.

Not sure about non-terminal use... I image it would not work. An option with RSO keys would be to use a key with no password for convenience, with the 2nd factor being the authenticator. It would be mildly more convenient. Of course, leaving the password in lace makes it even more secure.

1 the public folder: you can send a link to a file in your dropbox to anybody2 if both of "us" have dropbox accounts then i can share a folder to you and anything i put in you get and anything you put i i get (i think editing files is a bit wonky but...)

Great, but is it still the case you can just copy %APPDATA%\Dropbox\config.db to any computer and have instant access with no visibility that the credential is being double-used and no way to revoke or invalidate it?

Why would someone implement a keystroke logger if they can just steal this file and have unlimited future access with complete stealth? Sounds like this just makes it harder to remotely brute force against DB servers to login.

Back when OpenID was popular the argument was that you can outsource your authentication to a service that actually has a clue about security. Back then, though, none of the popular identity providers actually did anything better than username/password. (With the exception of MyOpenID, but they were always kinda niche.)

Now that I've embraced Google's two-factor auth -- accepting a little inconvenience for a little more security -- I find it useful that when I log into Google properties I only need to do the two-factor stuff once in a while, rather than for every single service. Two-factor auth *is* less convenient, but if you have single sign-on then you can make it less so.

If the latest trend is for every service to implement its *own* two-factor auth then this is going to get much less convenient. I'd sooner see services like DropBox just integrate with Google's auth (and with anyone else who has a decent auth system) and let users benefit.

I don't mind if they all use a compatible OTP system, so that I can just have the one Google Authenticator app for my iOS device (or a compatible J2ME program on my non-smartphone). The services that annoy me are the ones that use different methods that I can't integrate with code generating programs I already have.

The nice thing with TOTP/RFC 6238 [ietf.org] is that it's an open standard and not subject to the whims of a particular company. It's also completely independent of third-parties: I can set up my own TOTP s

I'm not really sure what this is. Google+ spams me now and then to link a phone, but I won't do that as it's insecure. I don't want my phone linked to anything. I don't want google+ linked to anything. I don't have important pictures stored only on the net. I don't have automatic upload of pictures or data. I don't want one failure to cascade and take down multiple accounts.

Besides I have disabled SMS entirely. Google's method can't work for me.

Dropbox adds a much better user identification method, for the sake of privacy.As the second factor is an SMS, and because in all countries the law requires the mobile operator to be able to identify at any time who's the person using a certain SIM.Identification of a user based on her/his email address is trivially uneffective.Better security is a tiny side effect. Any techie of the VAS team at the mobile operator would be able to circumvent that method. As well as law enforcement men in black.Really bette

Um, in almost no countries is it law that the mobile operator has to know who the customer is. Here, we can just buy a prepay SIM for $10 at the supermarket, put it in the phone, and start calling. No ID needed. Your post is a huge crock of shit.

While I agree that would be a nice feature, I find handling the encryption myself painless enough. There are many tools to do it but I find Axcrypt integrates quite nicely for Win/Linux systems but not Android yet.