strong authentication and emailing passwords

So this afternoon, I happened across i@mdentity listed in the OpenID Directory. They seem to be some kind of identity provider in the UK that has their own authentication protocol that they have a small number of vendors using. In addition to this centralized authentication, they also support OpenID. What really caught my attention was first that they emailed me my initial password… never a good idea, but I’ll come back to that later. The other very interesting thing was the proprietary authentication model they setup. From the looks of it, you enter your iamdentity username and password at the service provider website, instead of being redirected to the identity provider (…not good). But then, you are immediately emailed another one time use token (a five digit number) that you must immediately use to complete the authentication. Alternately, you can have them send the token as an SMS message to your phone (for a fee, I believe). So in order to compromise your account, someone would not only need to know your username and password, but actually have physical access to your cell phone (or the ability to hack the wireless phone network, I guess). The way I read it, it sounds like a new token is necessary each time you sign into a different service provider. While this may be a little bit overboard for most OpenID transactions and effectively kills single-sign-on, this certainly is a different way to raise the level of assurance of the authentication.

Of course, provides another way – client certificates, although I never got it to work under Safari. I guess it tried to automatically install the certificate for me, because I now have a couple of prooveme keys in my MacOS X keychain, but none of them appear in Safari. By the way, Safari’s support for dealing with multiple client certificates absolutely sucks and filing a bug with Apple like a year ago got no reply. And why the heck doesn’t prooveme allow me to upload my existing SSL client cert that I have with Thawte? So anyway, if and when OpenID really starts to see usage outside the blogosphere, and even just as the number of services a single password can get you into grows, I think stronger authentication like this is going to become much more important. So *poke, poke* at my OpenID provider of choice – I’d love to see some kind of stronger authentication along this line that is beyond simple username and password.

And what originally prompted this post… I’ve always thought fairly highly of the folks at TextDrive, and was strongly considering returning to my TxD VC account after Dreamhost announced their entire datacenter was going down for four hours this weekend (which means this site will be down). But TextDrive certainly lost a couple of cool points with me this morning in response to my forgotten password request…

Subject: Update on Your Request {64999}
Date: Fri, 23 Feb 2007 16:54:03 +0000
From: "Help @ TextDrive" 

Hi Will,

the current password appears to be ‘****’.


Filip Hajny Customer Support Manager Joyent Inc.

Yes, they emailed me my password in plaintext. The single password that accesses all services at TextDrive – email, website, SSH, all mysql databases, everything. The only one of those that really irks me is the fact that mysql uses your main password, but the fact that they emailed it to me unencrypted in plaintext just kills me. I’d love to see a company, hell any company, that allows me to upload my public PGP key or SSL certificate and choose to have them encrypt all communication like this that they send to me.

[update] I should add that it’s not the fact that someone would email my password unencrypted… sadly, that happens all the time. The thing that shocks me is actually who did it… I generally regard the TextDrive guys as really smart and on top of their game, but if this is their general policy then maybe I gave them too much credit in some areas.

[update2] The other annoyance with TxD was the fact that they did nothing to vet my identity. They could have easily had me verify a billing address, phone number, or whatever other information I gave them when I signed up years ago. Generally I despise the use of person-based data for authentication (particularly those “what is your favorite sports team” security questions) because of the very false sense of security they create, but anything would have been better than just blindly sending someone’s password in response to an unverified email request.

Comments and responses

Have you written a response to this? Let me know the URL:

Will, we all know who you are (Filip was also a “VC” and the pool is pretty small).

We also expect you to log in and change your password.

And also if you send in a gpg or pgp key, we’d be sure to use it.

Regards, Jason (txd founder)

In regards to not vetting my identity, I forgot that by default all of my outgoing emails are signed using my x509 certificate from Thawte (which includes both my name and email since I went through their vetting process). So given that, I guess that would have been sufficient to determine that the request was truly from me… my apologies on that point. However, that also means that you then had my public cert right there and could have easily used it to encrypt the reply email. Perhaps you are just a PGP shop and would have done so if I had used that instead of x509? That would definitely be encouraging, but still a little short-sighted since there are still a number of people that use x509, if for no other reason than it is more commonly supported in email clients.
It’s a help desk application that sends the emails out, I’ll pass on the idea of including x509 or other encryption support in there to the developers.
It's a help desk application that sends the emails out, I'll pass on the idea of including x509 or other encryption support in there to the developers.
Or more simply, don't email out passwords. It shouldn't be too terribly difficult to come up with some other way to distribute or reset one's password in a secure manner that does at least minimal identity verification. In any event, thanks for the reply... it is definitely comforting to know that TxD is actively listening.
The issue here is that they actually know what your password is, meaning it is stored somewhere on their end in plain-text. Forgetting your password should always be a secondary auth and reset procedure rather than what you see here..
The issue here is that they actually know what your password is, meaning it is stored somewhere on their end in plain-text.
Oh I certainly agree in principal... password should be thrown into something like Kerberos which is actually designed for this, and then point of all applications at that. That's the way everything works at my employer, with the addition of an LDAP directory which applications can use to authenticate users, although the directory in turns goes to Kerberos.

However, given the type of setup a company like TxD must have, I can somewhat understand the need for not doing this, especially since that password is shared among so many systems (not that I necessarily agree with that either).