In particular, I'm thinking that backups of all your "cloud" data mostly takes care of the fear of losing it like written in the OP. However, to not lose your email address itself, you have to have your own domain, but is that really sufficient? In the end, you mostly lease it rather than owning it, so can it just be assumed that a .com address won't be messed with (as long as there aren't any trademark issue)? (as opposed to, say, a .ly)

Do you use your own domain for email? Do you think that email addresses have some inherent risks that make them potentially disposable after 5-10 years?

A bigger question is how could anyone (that is: people who have currently no idea what a domain really is and how to get one) take control of their addresses in a similar way?

As far as I'm concerned, I haven't used my own domain yet for emails but my alumni association gives me a lifelong forwarding address. I haven't been super strict with using it everywhere though, so it's a bit all over the place. The truth is too that my Gmail address is much easier to type and give away than either my alumni one or my own domain…

I run a DTC server (like open source CPanel) on which I manage email addresses for my workingsoftware.com.au domains, but I just forward all mail from there (for multiple accounts) to a single gmail account, iaindooley@gmail.com.

I have setup that account to allow me to send email as multiple different accounts, and send using my own, external SMTP server so that it looks "real".

I then have fetchmail running on one of my servers which downloads everything from gmail (except the spam) and I mostly read my email with alpine although using gmail as a waypoint has the advantage of lots and lots of free storage, excellent search and very easy accessibility from the web and multiple devices.

I periodically archive this when it gets too big onto the same server that holds my nightly backups (a 5.3TB RAID-Z NAS in the same rack as my primary development machine).

If my gmail account got hacked and all my messages were deleted, I'd still have them (because I POP them off) and the email address that I use publicly is not associated with my gmail address, so I would just be able to open a different gmail account and forward my mail there. I'd lose the ability to search a crapload of messages, though, without un-archiving all my old tarballs that I'd popped off of gmail but that's more of an inconvenience than a catastrophe.

I wrote about this a while ago: http://sneak.datavibe.net/20100227/the-future-of-the-interne...

I think that most people's FQDNs will be third-level or deeper, granted by some identity provider, though once the whole user@host format is abandoned I'm guessing that there will be lots of identity/email providers that allow one to one-stop register a domain and integrate it with the service (something that's beyond most casual users of email today).

I think there was a point where everybody wanted to blog, and thus might have an URL that they considered "me", but that's gone away with Twitter and Facebook. Come to think of it, many people have a Facebook claimed URL, but I've never typed or clicked one, and I don't even know my own.

I understand that there are limits to what technical support you can offer your end users but the fact that someone is a reporter with 'access' should not be the determining factor in who does and does not get back their email after a hack (which is a large word, account compromised would be a better description) like this.

Update: I would even be willing to pay Google for extra features such as the above, and more importantly, for guaranteed/quicker support from them if anything goes wrong.

If you don't trust Google with your old messages, then why do you have a gmail account at all?

If you don't trust them to keep your email backups safe, you shouldn't be using them.

http://www.slate.com/articles/technology/technology/2009/07/...

take a phrase - ask not what you can do for your country -> Anwycd4yc

for each site mix in some letters from the domain, ie 2nd two letters of amazon -> maAnwycd4yc

bingo - easy to remember - strong - unique for each site

password safe like keypass is also good. occasionally you get services with silly password rules where your generator function doesn't return a valid password.

still important to have 2 factor on that one email account that has your banks etc., otherwise one encounter with one of these bad boys and it's all over -

http://www.google.com/search?q=usb+keylogger&tbm=isch

http://xkcd.com/936/

250000^4 = 4 x 10^21 combinations

vs

26^(~10 characters) = ~10^14 combinations

Even counting for capitolization and numbers and symbols, you get something like:

72^(~10) = 4 x 10^18

> To anyone who understands information theory and security and is in an infuriating argument with someone who does not (possibly involving mixed case), I sincerely apologize.

You are the "someone who does not".

Please do the calculations described in the comic and tell us what your results are.

If I have maAskNotWhatYouCanDoForYourCountry then someone seeing it could possible guess the relevance of the ma, and try ew or hn, etc. on this site.

Woth maAnwycd4yc on the other hand, without being told, are you going to guess that maybe it's a generic password with a small site-specific portion?

My passwords tend to be based off nonsense sentences. Personalized nonsense I can remember, but nonsense nonetheless.

To avoid confusion some websites let you type in x characters, but only take the first y characters.

My main reason is: a pain to type on a mobile device

As others mentioned: may also get truncated or not accepted as a valid password due to length; if you added Amazon in there somewhere it might be easy to reverse engineer for other sites

That being said, I've pushed off and on some development for a network identity device. Not the big 'Identity' problem that most people run away screaming from but a much reduced (and tractable) part of the problem. A device which can prove that the person making a request is in physical possession of the identity device they had when they created the account.

Such a unit prevents people in Lagos from exploiting your password even if they get it as they don't have the device.

That seems kind of like a 'nit', I know, but if we learned anything from Steve Jobs it is that there is a difference between providing an answer and providing a solution.

The elements that will be present in a solution include;

1) You won't have to type anything else, a program will have an API which can definitively tell it you are making this request or you are not.

2) The 'key' won't be anything else, it won't be an app on your phone or a plug-in to your browser.

3) It will work with any service you care to use it with and if it has not been implemented there will be no legal/enumberance/techincal barriers to doing so.

4) It will not degrade your privacy options.

Google's two factor authentication fails on a number of these, not the least of which that it requires that you own a 'smart phone' which is something my father in law will never do before he dies.

So no, Google doesn't do this yet.

As I said elsewhere in this thread, some countries in Europe require you to use a fob that generates another key for your second authorization factor. But you still have to type in extra numbers. How would you get around that? How does the service know that you're in possession of the key unless you give it some kind of input about the key that's unique to the key and to the current time?

Personally, I much prefer having it on my smartphone, and this seems like a good approach considering smartphone adoption rate. But Google's 2-factor will sms your dumb phone, too.

How does the service know that you're in possession of the key unless you give it some kind of input about the key that's unique to the key and to the current time?

Lets say you've got a 'fob' which is plugged into a USB port. Application sends the fob a challenge, fob responds. Application validates the response and proceeds. Perhaps the key uses 2.4mhz wireless, perhaps it uses bluetooh (a protocoled 2.4mhz wireless solution :-). The benefit is that these things can only occur when you're key is present. No key, no transaction.

We don't worry about Nigerians stealing our cars, but we should consider what they might do with our self-driving cars if we don't have some durable way to say we're in the car right now.

I appreciate that you prefer having something like this on your smart phone, but such a solution fails for the larger internet population. And while SMS works for 'dumb' phones you cannot have it validate on every send, every post, every tweet, every page view.

You may not share my urgency on this as a threat but I invite you to start to watch more closely. In the Atlantic article a Google representative said "Thousands per day" this is big business for folks. I was talking with a senior executive at Wells Fargo who mentioned hundreds of millions of dollars 'lost' every year. This is a growing problem, its getting more expensive, and like some digital herpes my expectation is that it is going to pop out suddenly in boils of financial putritude dripping pain, financial suffering, and expense for everyone involved. With luck we'll fix it before then but most folks who are getting burned are more interested in covering it up rather than addressing it sadly.

I think it would be wonderful to have a possible solution prototyped and demonstrable for people in pain. Your passwords will be compromised, and if you do anything financial online you will have money vanish and you will experience arguing with a bank as to why they should give it back to you and take the loss. This isn't a 1 in 10, or 3 out of 5 type statistic, I'm pretty confident that every single person who has an online account which can tranfer funds (whether its an iTunes account or a checking account) will experience this. 100%.

I still fail to see how this solves anything. Once you get malware on your computer, that malware can send requests to the USB device, and you're back at square one.

One of the features of RSA security fobs is that only someone physically present can use it. What you've made is an RSA fob that's vulnerable to viruses.

But lets say that at the 'introduction' stage the service set a cookie with the fob by saying 'remember this about me, I'll call my self ecb994af and your magic number is 3551eff' then later on verification passes it sends a message encrypted by its self key to 'tell me your magic number divided by 2 and encrypted with your id.' The attacker can see the whole sequence but if they don't understand what is being asked and returned they can't reproduce it, and they don't have the initial secrets either.

There are lots of ways to do this with smart protocols. Something I tried (and failed) to patent back in the Java days where you sent a packet which could be executed. The nice thing about such protocols is they can be dynamically designed between device and service and malware is stuck out in the cold.

There are things it cannot protect against, malware running in the Google servers or Amazon's for that matter which has access to all of their server data. But if it does get compromised it only compromises one relationship, no additional damage is done because other systems can have their own protocols, their own dynamic data.

Also, you wouldn't be able to log into a public terminal.

"Also, you wouldn't be able to log into a public terminal."

Actually depending on capability (no pun intended) I could easily see 'read' access being usable without the key but recognize the issue there. The real 'issue' if you will is universal appeal/buy-in which is to say if anyone can use it then you will get some early adopters who will provide support as a differentiating factor and that can drive adoption into more slowly changing markets. Because it has to be everywhere to be effective it won't be a big money maker (this is where a lot of VCs stop listening :-) basically the barrier to implementing it has to be 0 and the value to the implementor has to be non-zero. Given how thinly marginallize 'security' fixes are, this margin won't leave anything for the manufacturer in terms of on going revenue so the key itself has to define the value for the company. (I've actually thought a lot about this :-)

So to your point, for early adopters the experience would be to get a 'key' and to install a plug-in and then enabled sites and services would be secured. Pretty easy sell to an enterprise if their only cost is the 'fob cost' and there isn't some giant consulting revenue stream attached to it. For big companies it has to be completely implementable (once the key infrastructure is set up) in a way that is custom (and probably private) that enterprise. That gives their IT folks confidence and it makes the risk low.

For more general engagements like PayPal or Facebook its a bit different. On things that are appifyable (if that makes sense) there is a potential for differentiation (look at how the World of Warcraft Authenticator stuff was worth it for them to implement).

The key for me is that the existing way of doing things is under attack and it will eventually succumb, when it does there is a tremendous opportunity there.

ObDisclaimer: not a representative of, etc, just messing around with them at the moment.

http://www.google.com/support/a/bin/answer.py?answer=175197

less of a nit - if your browser automatically confirms your identity, whatever token it's based on, the privacy implications may not be completely warm and fuzzy

  > there will be no legal/enumberance/techincal barriers to doing so

  > it won't be [...] a plug-in to your browser

  1) Try to login
  2) Google calls your phone and says the auth code
  3) Type it in

I remember that when my wife was in school in the Netherlands, her bank there gave her a fob that created a second factor for sign in, too.

I'm curios as to what the reasons are? How do you bruteforce a gmail account? Surely Google will not allow you millions of tries?

Break into a less-well-secured site, steal the password file, which may use something like md5. Brute force offline. Then, try that password and username on a more secure site like gmail.

Just don't do it. And tell all your friends.

  > "DON'T REUSE PASSWORDS EVER"

I can't possibly be the fastest runner from this bear.

2. Use the first letter of each word in a phrase. Again, now it's easy to remember but not a dictionary word.

3. Find a way to customize the password for each site in such a way that you can remember the pattern. Use letters from the stock symbol, the dominant color, the domain name, or some other word you associate with that site. Boom - now your password is unique per site.

Really, what IS sensible is having sensitive sites with different passwords and "who cares" sites with simillar ones. As the author actally says in the end of the article.

Of course that's also too much work for the average user.

I think single sign-on systems with two factor authentication and other advanced security are a step in the right direction.

I'd like to know what the author really meant.

Since most of these systems are rate-limited per-account, instead of iterating over passwords for a given account, you can iterate over accounts for a given (common) password. This won't work for a targeted attack, but if you have thousands of valid email addresses, trying them all with e.g. "password" as the password will likely yield a few for which it works.

However many sites won't allow you to have a different email account just for password recovery, that is insecure, as people would then know where to go for.

Worse is if someone manages to get malicious software directly to my computer. At that point I'm screwed, and everything including email/bank accounts are an open book.

I don't know what the answer is but I sure hope someone would fix it.

Gmail is a different story. Anyone with access to that gets access to most other things. So the inconvenience of inputing a text message code once a month pales in comparison to the hurdle it adds to accessing my account.

(I'm not affiliated, just a user. It works a charm.)

Only downside is that the keychain file is not encrypted as a whole, only the passwords, so if someone steals your database file they've a list of all your usernames and sites that you have an account on (but not the passwords thereto). It's the same for the OSX keychain, e.g.:

    strings ~/Library/Keychains/login.keychain | egrep -i 'com|net|org'

"The account had seemed sluggish earlier that morning because my wife had tried to use it at just the moment a hacker was taking it over and changing its settings [...]"

It does not sense to me that GMail is sluggish when someone else changes the settings.

That is a good reason. Moral of the story: make your own personal backups of everything that you wouldn't want to lose.

Single sign-on systems are the only reasonable solution. Of course that introduces a single point of failure, so they need to be extremely secure, but at least it's easier to secure one system with two factor authentication, advanced monitoring, etc than every site on the web.

If you care about your mail, you should be doing some kind of personal backup with any service like this. I just fire up Thunderbird, like the author, but I'm sure there must be a lot of scripts and programs out there to do local gmail backup.

This person's tale should be a warning to those who have not done a backup recently. Harddrives have never been cheaper in terms of price per byte. It only takes a couple of steps to set it up so that it's done automatically.

I have my own personal domain I could sync it all to, somehow, I suppose. Then I need a linode box, scripts, etc, etc...

I don't really want maintain or worry about a local backup of 6 GB (and growing) of mail grom gmail...

http://secretgeek.net/sg_hijack_1.asp http://secretgeek.net/sg_hijack_2.asp