Re [2], it doesn't matter if a form's action posts to an https link. Using an unencrypted HTML form to post to an encrypted post handler is a security anti-pattern. Attackers will simply intercept the form render instead of the post, alter the form, and insert themselves in the middle of the transaction. This attack is no harder than intercepting the POST itself.
Don't ever give your Google Mail password to another company. Even if they "encrypt" it on the wire, you can never be sure they're not storing it insecurely on the back end. Please take this from someone who spends his days beating up other people's applications: everyone screws up something.
This is yet another comment that reminds me of what in my mind is a related problem. I encounter more and more sites, including major ones, that include insecurely delivered (http://) assets into their secured pages (https://). My understanding is that this is another vector to get at e.g. forms and cookies, or basically anything on the page; by intercepting the insecure asset, you can inject yourself into the secure parent page.
I always wonder "what's up with that"? Is it that the particular assets don't lend themselves to injection, or an assumption that items delivered from a server under their control can't or won't be intercepted? If the latter, particularly once the traffic hits an unsecured wireless segment, I'd be inclined to say all bets are off.
EDIT: Nit: HN linkified the bare protocol designations.
I probably should have made this very clear: While the lack of encryption is maddening, the very worst part is that Tumblr isn't performing this data pull properly (and Google does provide a proper and relatively safe mechanism for doing what they're doing--it's used by Facebook, LinkedIn and anyone else with a need, API key and good conscience).
While I wasn't a huge fan of the tone here ("They really don’t give a shit, huh?"), it does seem like something that needs to be brought to everyone's attention.
Hey, at least the substance is there... if this situation is as you characterized it, I see it as a rather massive breach of trust on the part of Tumblr. The tone might be regrettable, but that's a minor concern.
8 comments
[ 3.7 ms ] story [ 33.4 ms ] threadDon't ever give your Google Mail password to another company. Even if they "encrypt" it on the wire, you can never be sure they're not storing it insecurely on the back end. Please take this from someone who spends his days beating up other people's applications: everyone screws up something.
I always wonder "what's up with that"? Is it that the particular assets don't lend themselves to injection, or an assumption that items delivered from a server under their control can't or won't be intercepted? If the latter, particularly once the traffic hits an unsecured wireless segment, I'd be inclined to say all bets are off.
EDIT: Nit: HN linkified the bare protocol designations.
I probably should have made this very clear: While the lack of encryption is maddening, the very worst part is that Tumblr isn't performing this data pull properly (and Google does provide a proper and relatively safe mechanism for doing what they're doing--it's used by Facebook, LinkedIn and anyone else with a need, API key and good conscience).