Tipjoy is a cool new site that lets you exchange micropayments over the Internet. Unfortunately, on their "createAccount" page, they prompt you to give them your password without encryption!
http://tipjoy.com/createAccount/
That URL should be HTTPS-only, not HTTP. If you enter your password on that page, any "man in the middle" can read it and use it to impersonate you on Tipjoy.
By capturing your password, the attacker can spend money that belongs to you, transfer money stored in your Tipjoy account into the attacker's account, etc.
Bizarrely, tipjoy.com does support HTTPS... they just choose not to use it on most of their webpages, including the /createAccount page and the /settings/account/ page where you go to change your password. (The /login page is HTTPS by default.)
You can even opt-in to transmit your password securely, by modifying the URL to use SSL: https://tipjoy.com/createAccount/. That may be an acceptable workaround until tipjoy fixes their site.
But, even knowing that workaround, you STILL shouldn't use Tipjoy to put a button on your site until they fix this issue. If you put a Tipjoy button on your site, your users (the people who like you and generously want to give you a small tip) will probably NOT notice the problem; they will just create an account using the default /createAccount link, exposing their passwords to a man-in-the-middle attack.
Hopefully Tipjoy will get the message and fix this soon. Frankly, as a payment exchange system, their ENTIRE SITE should be behind HTTPS, not just key login pages. This is how paypal.com works; it's also how most bank websites work. When money is on the line, you really can't accept anything less.
5 comments:
nice information, very useful
We have HTTPS setup for the entire site, but don't mandate it.
You can go through the create account process with HTTPS here:
https://tipjoy.com/createaccount
Most people create an account via OAuth, which avoids this issue altogether.
Signup through widgets is a bit more complicated, as we can't load an HTTPS widget on an HTTP site. Most browsers would complain.
I don't think we're at the scale that is particularly matters.
Going forward, most signups will be through our API: http://tipjoy.com/api
All the endpoints are accessible via HTTPS.
@Ivan, I don't think it's acceptable to say "I don't think we're at the scale that it particularly matters."
If Tipjoy cares about its users, it needs to be secure by default. Until then, we can only hope Tipjoy always remains small enough that it doesn't particularly matter!
P.S. Signup through widgets isn't "complicated," it's totally insecure. Nothing complicated about it!
I don't think I expressed myself clearly.
Security is like reliability analysis, and there is a Murphy's law there. There will be failures, and you need to optimize to push out the failures as far as possible.
Because we have an API that authenticates via Twitter credentials, the likelihood of an attack based on phishing those credentials is so much higher than a man in the middle attack. That's where we focus our attention.
My comment about scale didn't mean I don't care about the issues, but that our scale makes the profile of a likely attack different than what you might expect.
Also, that process of moving money from Tipjoy to your bank account is heavily audited. That, combined with that fact that we're dealing with micropayments, means any fraud at scale is easily squashed.
Today, I'll mandate HTTPS on forms on tipjoy.com as needed. We'll probably soon pop open a new secure window instead of allowing transactions through our widgets. I'm sure there is more we can do too.
I'd like to mention that this kind of open discussion is very much appreciated. Open analysis of security problems is pretty much the only way the problem is really solved.
@Ivan, thanks for replying again. These remarks are MUCH more reassuring. :-)
(Yes, I think tipjoy *must* open a separate pop-up window to remain secure.)
I'll keep an eye out for changes to the Tipjoy /createAccount and /settings page and will update this entry when those pages are safely behind HTTPS.
Post a Comment