gistfile1.txt

Hi Meni,

On Sep 2, 2009, at 5:25 PM, iCount Support wrote:

> As a human being I'd expect YOU to have learned that there is no reason to talk about something without knowing ANYTHING about it. As you clearly stated - you recommended iCount without actually testing it out first. You based your recommendations to your friends on anything but facts and treated our answer as BS - as if we were BSing our clients and sending them lies as answers.
>

Yes, I gave a 2nd-hand reccomendation for iCount without actually using it because I had heard it was good. Then, I agreed with my friend that your service is broken when it sends out passwords in plaintext.

So you'd prefer I don't recommend your service to friends? Or do you prefer I stick my head in the sand and not tell people that receiving cleartext passwords via email is a bad thing? Or you prefer that I not speculate as to what exactly is broken in your code/process when my friends get their password emailed to them, wide-open?

Your original response to benny was "Security is important to us. We assume that people will change their password after creating their accounts (???) and so we email them their passwords for convenience."

Pardon me, but sentence A and sentence B do not compute. And I said so, and wondered why a service that deals in money could be so bad at handing the ABC's of security. Your response failed to reassure me that you knew what you were doing -- it actually made things worse.

> This is what made me angry...
>
> You assumed that we were storing plaintext passwords just because we emailed a password and so the mouse became a mountain. You then assumed that we were allowing "greedy" people next to our sensitive "password warehouse" and so the mountain became the Everest, and now you threaten to "share this [YOUR EVEREST!!] exchange with my community of friends".
>

I have no risk in this game -- I don't have my data stored with iCount. I have no stake in "making mountains" out of anything. I see bad behavior and I point it out. You can call your issues mountains or mice, I really don't care.

As for my assumption that "greedy people" are near your password warehouse, we are back to the ABC's of security: I don't care if your employees have all signed blood oaths to protect your data or commit hari-kiri. Security is about choosing a tradeoff between convenience and paranoia -- and the accepted balance, when it comes to money, is to not trust employees because everybody's loyalty has a price. These aren't my words -- if you have any kind of security background, then this should be obvious to you.

I don't know you, don't know your employees, don't know where your servers are. All I can hope for is that you implement the basic measures of security I've outlined.

As for sharing my exchanges, I think this one is particularly instructive as an example of how not to handle a failure. It is also of interest to anybody who wants to evaluate your service as a safe place to do business. By continuing this conversation, I've given you more opportunities to make your case, and you've consistently failed to do so without involving emotion.

I'm glad to hear that you store hashed passwords. I think your policy of emailing people their passwords is ridiculous, and your rationale for "why users would want their passwords emailed in the clear" sounds like my 4-year old nephew justifying why he took something he shouldn't have ("I took it so I can give it to you now!").

What can I say? You screwed up, and then got angry when I said your so-called "explanation" was BS. There are two solutions:

1. Don't screw up.
2. When someone thinks you screwed up, provide a good explanation. If you can't find a good explanation, chances are you screwed up. Fix it, apologize, and you've turned a PR failure into "wow that company's support is AWESOME!"


> To say that you have "teared down" iCount is simply ridiculous, so please let's put things in perspective.
>

I didn't say that I've "torn down" iCount in any way -- seriously, it is your own responses that are digging you into a deeper PR hole. Everything I've written represents security best-practices for the amount of risk a security breach carries to your customers.


> It's not our policy to discuss internal aspects of iCount with clients but since we already have, I will address your remarks.
> We do not store decryptable hashes. I already made that clear in my last email. If a user requests a new password the system will create a password for him, email it, encrypt it, store it encrypted and will suggest that the user change it upon next login.
> If you think that's not enough, you are more than welcome to suggest a better way to do it...

If by "encrypt" you mean "securely hash" then great! You're doing the right thing. Ale ve'hatzlech.

> You have to understand that the majority of our clients are not techy's like you, and they prefer a more user friendly system.
> Having been in the market for several years, iCount is a product that is based on a real understanding of its users' needs.

Bzzt. Wrong answer.

The majority of my bank's clients are not techies like me, and yet they implement security correctly (well, I hope -- banks in Israel suck.)

Also, security and usability are not mutually exclusive, so "prefer a user-friendly system" should have no bearing on your security practices.

I personally use freshbooks, paypal and google checkout. All of these services are usable and populous, and I have never been greeted with evidence that they are storing or transmitting my password in cleartext. Their usability does not mean they make poor security choices -- why should you?

> This is why we feel it's important to remind the user of his password. Security practices that do not match YOURS are not bugs. Get your terminology in order before you accuse us of such things.

Again, your insistence on killing the messenger. Go read a little about security -- the things I am suggesting are ACCEPTED practices. Not my practices. Not even difficult practices.

There really is absolutely no reason to store or send a user's password in plaintext. Ever. It mystifies me why you still think this is OK.


> in spite of all the above, since I am not here to fight my clients, potential or not, I will do two things.
> • I will immediately add a comment notifying registering users that their password will be emailed out to them as a reminder in plaintext.

Wow, that's like fixing a leaky boat by telling the passengers that the water will be cold. Wouldn't it just be easier to fix the problem?

> • I will add a note in the email received that it's recommended to change the password that was created during registration.
>

And you claim to have a usable system. How about just letting customers set their password securely and not ever emailing them a cleartext password? You're treating the symptom instead of spending your resources on fixing the problems.

Here's a usability tip from a usability professional: customers don't follow instructions. Good user experience involves sensible defaults which will automatically, always leave users in a secure state, without them needing to take additional action.

>
> I hope it will bring this debate to a more pleasant ending.
>

I'm not debating you, just pointing out what you're doing wrong. Not what I think you're doing wrong -- what accepted practices and experience say you're doing wrong.

If you're still unclear as to why the steps I've outlined above are important, I am happy (really! no sarcasm) to keep discussing this with you.

-Idan