Pressgram Security Concerns

NOTE: This is the first of two posts looking at problems I see with Pressgram. The second, addressing the Terms of Service can be read here.

Hi, folks. Gather round, and let’s have a little chat about password security and transparency.

So Pressgram just released, after a rather successful Kickstarter campaign, and lots of excitement by the community. Hurrah, congratulations, folks! Getting a public release actually shipped is the toughest part of any project, and you’ve got that out. Well done!

I installed the app last night, kicked the tires, and examined how it operates a bit, and I’ve got some concerns that I’d like to voice.

First, though, a bit of background. On the official WordPress Mobile Apps, there’s only so much security that can be reasonably achieved via the XML-RPC API that they (and pretty much all apps) use. With XML-RPC, there are no authentication tokens, you need to send your password in plaintext. Which is normally totally fine, as the password is just stored by your local phone (the security of which you are responsible for yourself), and then stored in a double-hashed and salted form on the server.

It seems that, unlike the WordPress Mobile Apps, the password that you enter in Pressgram isn’t kept private on your own device. Without noting it on a Privacy Policy or in any way notifying you that Pressgram is doing it, your password is stored in plaintext on their server. Which — to be fair — is necessary, if they’re going to be pushing data from the Pressgram Server to your WordPress site, and not going to require having a specialized plugin (like Jetpack) installed on your WordPress site to do it. And I don’t think that Jetpack is necessarily a worthwhile dependency to have for an app like this.

My first concern is that I don’t really like my passwords being stored in plaintext on a third-party server that could be hacked (or for that matter, required to be turned over by an order from a FISA court). Some other applications, such as IFTTT do the same thing, but at least with them, it’s transparent that it’s going to be their server holding your credentials and accessing your WordPress site.

With Pressgram, without further investigation, one would believe that it’s the app directly uploading the files to your WordPress site. After all, that’s what the Kickstarter initially pledged:

I suppose another way you could say it is… it’s your filtered photos published directly to your WordPress-powered blog, when you want, where you want, how you want.

But that’s not the case! For the curious, here’s what I saw when running a test against a honeypot standalone site where I was trapping all the requests sent to it:

Firstly, the App sends two requests to /xmlrpc.php

XXX.XX.XXX.XXX - - [06/Sep/2013:02:51:51 +0000] "POST /xmlrpc.php HTTP/1.1" 200 904 "-" "John.Saddington.Pressgram/1.0 (unknown, iPhone OS 6.1.4, iPhone, Scale/2.000000)"
[Fri Sep 06 02:51:51 2013] [error] [client 174.59.108.165] <?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName><params></params></methodCall>
XXX.XX.XXX.XXX - - [06/Sep/2013:02:51:52 +0000] "POST /xmlrpc.php HTTP/1.1" 200 512 "-" "John.Saddington.Pressgram/1.0 (unknown, iPhone OS 6.1.4, iPhone, Scale/2.000000)"
[Fri Sep 06 02:51:52 2013] [error] [client 174.59.108.165] <?xml version="1.0"?><methodCall><methodName>wp.getUsersBlogs</methodName><params><param><value><string>admin</string></value></param><param><value><string>password</string></value></param></params></methodCall>

These two requests firstly make sure that the site is there and is a WordPress install, and secondly makes sure that the credentials work — and if it’s a multisite install, returns the available blogs.

So far, so good. The User Agent strings are clear as to what they are and what they’re accomplishing.

Then, ten requests come in:

YY.YYY.YYY.YYY - - [06/Sep/2013:02:53:27 +0000] "POST /xmlrpc.php HTTP/1.1" 200 1845 "-" "-"
[Fri Sep 06 02:53:27 2013] [error] [client YY.YYY.YYY.YYY] <?xml version="1.0" encoding="iso-8859-1"?>
<methodCall>
<methodName>wp.getTerms</methodName>
<params>
<param>
<value>
<int>1</int>
</value>
</param>
<param>
<value>
<string>admin</string>
</value>
</param>
<param>
<value>
<string>password</string>
</value>
</param>
<param>
<value>
<string>category</string>
</value>
</param>
<param>
<value>
<array>
<data/>
</array>
</value>
</param>
</params>
</methodCall>

and nine others very much like it. If anyone is curious to see them, tweet me, and I’ll post them for folks to review. Checking existing taxonomies, creating new terms, uploading the photo, and creating the post.

XXX.XX.XXX.XXX is the IP address of my phone. YY.YYY.YYY.YYY is the IP Address of the Amazon Cloud Server that Pressgram works off of. I’ve anonymized these just for the sake of privacy. They’re easy enough to find, but it’s not my business to release them. I’ve also removed the base64 encoded image data.

I’ve also captured the request that the Pressgram App uses to send your password up to the Pressgram server — it looks something like this:

URL: https://api.pressgr.am/index.php/Api/postPhotoData
Data:
{
	"social": {},
	"post_content": "Pic",
	"sessionId": "00000000000000000000000000000000",
	"blog": [{
		"title": "Pic",
		"password": "password",
		"login": "admin",
		"url": "honeypot.example.com"
	}],
	"identifier_photo": "0000000000.0000000000"
}

So at least it’s being sent to the Pressgram server over HTTPS.

You’ll notice that the requests coming from the Pressgram Server have no User Agent to identify what they’re there for. They’re all signed with username and password — meaning that the Pressgram servers now have my username and password in plaintext, with not even a notification to me in their Privacy Policy or Terms of Service that this is being transferred up to their servers.

So what does this all mean?

Well, it means that Pressgram is storing your credentials in plaintext (or potentially encrypted alongside a decryption key) on your behalf, without notifying you or doing anything publicly to indicate that this is the case. No matter how high entropy your passwords may be, if you hand it to someone and they get hacked, it doesn’t matter. You are vulnerable — doubly so if you use that password for other accounts as well.

To some folks, this may be a worthwhile tradeoff. But as I look at it, I don’t see it as a necessary tradeoff. Your credentials could just as easily be kept private between the app on your phone, and your WordPress site. Just have your phone upload the photo directly to your WordPress install. It wouldn’t be difficult to do, it’s already making XMLRPC requests to the server. And it fulfills the initial Kickstarter promise of “your filtered photos published directly to your WordPress-powered blog”. It also would provide the added security that if Pressgram is eventually shut down or sold off, the app would still function, as it’s not needlessly dependent on the Pressgram Servers.

To protect yourself, you may want to consider making a seperate account for your WordPress site with the Author role, and using those credentials with Pressgram, and make sure you’re using a distinct password — as well as with any service that you provide a password to.

Conclusion

So in the end, what am I calling for?

Ideally, I’d like to see Pressgram give users the option of simply taking photos, and uploading them directly from the app to their WordPress blog. No servers in the middle with potential vulnerabilities for your data. In short — make the account creation and login optional. Give folks a choice! That sounds a lot more like what the Kickstarter was proposing. If you’d like to build a new social network on top of it (if I had a dime every time a potential client tried building that), make it optional!

Do I see that happening? Well, I hope so, but I’ve found that companies don’t normally like to make themselves less integral to a process. So at the very least, notify your users that their credentials are going to be stored on your servers. To take them as Pressgram has without any such public warning I see as morally questionable, and totally contrary to the values of the WordPress community, which embraces transparency, and not forcing unnecessary service dependencies between you and your site.

UPDATE: Pressgram has updated their Terms of Service to indicate that your content may travel through their network to get to your blog.  Unfortunately, it says nothing in the TOS or its Privacy Policy about your username and password being stored on or passing through its servers.

Published by

George Stephanis

WordPress Core Contributor, Jetpack Pit Crew, CSS Guru, jQuery Fanatic, HTML5 Aficionado, Letterpress and Carpentry Nerd.

57 thoughts on “Pressgram Security Concerns”

  1. Security is an issue here, but I think focusing on that misses a larger point: That an application designed to be philosophically different from Instagram should also provide for a decentralized path your content takes. Having a server in the middle only serves as a point of failure — both technologically, and as something that could just stop working one day, change its policies or terms of service, be sold, or what have you.

    1. Agreed.

      On the terms of service, they’re really not philosophically different than Instagram. They claim so, but a closer look reveals that they get basically the same license as Instagram does. Instagram also makes no copyright/ownership claims against its users photos, as Pressgram seems to imply.

      Basically the difference between Instagram and Pressgram is that, for now, Instagram doesn’t have an option to publish to a WordPress site – something that could easily be added if they so wanted.

      Thanks for this post, George.

      1. Agreed 100% — I’ve got some thoughts pending on the Terms of Service. The TL;DR: sections really are just statements of intent, and have absolutely nothing to do with the small print that follows (and in fact often seem to contradict it).

  2. It’ll be interesting to see how Pressgram evolves. Kudos for doing something outside of the box. On the other hand – and this is just something I’m wondering about – if people want to do mobile blogging, why can’t they just use the WordPress App? It works great for me for short blogs with photos from my camera roll… Really just curious about why Pressgram is really trying to change. I just discovered it a few days ago via twitter

    1. ..”if people want to do mobile blogging, why can’t they just use the WordPress App?”

      Here’s the workflow for posting from Pressgram to a WordPress blog.

      Launch app, take photo, apply filter, enter some info for blog post ( text, tags, category), post.

      Here’s the workflow for using WordPress to post an image.

      Launch camera app, take photo, apply filter, save photo, exit app, launch WordPress, create new post, tap to import image, enter blog post info, post.

      Pressgram is one app.

  3. Password security is good and plaintext is bad – not sure if you’ve opened a ticket w/ the Pressgram folks. I just submitted the issue via the support site and pointed them to this post.

    The bigger architectural issue (whether or not Pressgram has servers and sends content there) seems like a separate concern. I’m not sure how one would build the social network component without it at this point… we know that distributed social networking has been a long-unsolved problem.

    1. I agree. I just happen to think that from how Pressgram was marketed in the Kickstarter, the social network addition should be totally optional. Otherwise you’re basically building something indistinguishable from Instagram, except 1) It also posts to your WordPress site (which you could easily accomplish with Instagram using IFTTT or a plugin that scrapes your feed), and 2) it doesn’t have the existing community that Instagram has.

  4. This is fantastic. The point of the central server “in the middle” is to provide a consistent user experience to the users in the application itself.

    Can you imagine having 100 friends and requesting data from 100 different servers from all over the world from different hosting environments with different performance? The usability in the app would be… well, nasty.

    So, we use AWS to provide that universal, global experience.

    1. Yes, but you’re assuming the social network. I’ve been chatting with lots of folks who don’t care about that. All they want is what the Kickstarter initially promised — an app that lets you take pictures, apply filters, and upload them directly to your own WordPress site. They don’t want the extra baggage and licensing headaches that goes with the network you’re making folks sign up for.

        1. It’s parsing words but the original copy was “…you’ll still have the ability to create your own Pressgram creative social network” not “you’ll be required to be part of the PressGram network”.

          I suspect most people don’t have a problem with being part of the PG network but feel it shouldn’t be mandatory step in the process of posting images to one’s site.

        2. John,

          The Kickstarter was entitled “Pressgram: An Image Sharing App Built for an Independent Web” — you were clearly Kickstarting an App, not a Service. And if it’s truly for an Independent Web as the title asserts, then why do you make the Pressgram app wholly dependent on the Pressgram service that you’re requiring everyone to sign up for, as opposed to being a functional standalone application?

    2. I take your point, John, but I’d prefer that the social aspect was secondary to the primary purpose the application was billed for: posting images to my WordPress blog.

      Do that first, then have your service layered on top for the consistent social experience. As it stands now, I’ve been able to post one photo to Pressgram (before the app succumbed to iOS7 issues), and it has never appeared on the blog that was configured.

  5. I agree with your ideal conclusion – I’d love to see the ability to use the app without being required to create an account or pushing anything to Pressgram’s service at all. I think it’s recognized that in order to have a social component, a centralized service is necessary, but I think the app should still be usable for those of us who are more interested in the original pledge of direct publishing than browsing other people’s pictures and collecting likes.

    I also don’t see any good reason for the push to come from Pressgram’s servers as opposed to directly from your phone – seems risky to have a point of failure both because you’re relying on Pressgram+AWS to be up in order to publish to your own blog and because they’re holding your password.

  6. Doh! Thanks George for discovering this. Thanks John for responding and looking into it.

    I too thought there was no relay server involved and images were going straight to the WP site via XML-RPC. Hope this can be fixed. I wasn’t looking for another social network, just a quick camera app to post to my sites/accounts.

  7. If there’s no need for a social app, I would say that Kitcam and the WordPress app accomplish exactly the basics you’re asking for. I would really, really like to have an alternative to Instagram, however, with the social and so on.

    1. I think that’s fair in a practical sense – I’m certainly going to end up still using the WP app directly for various reasons, including open source principles. However, beyond the social piece, there are two base issues for me: the security implication of Pressgram storing your password in plaintext on their servers without explicit permission and when it could be avoided in the first place, and that it was promoted as publishing directly to WordPress and supporting freedom of publishing without strange/changing TOS when that seems to not be the case at all.

      Social sharing apps and ownership of data are largely at odds with each other – I think that’s perhaps why myself and others read into the “you’ll still have the ability to create your own Pressgram creative social network” line as it being an optional part of the app, not a required one. Otherwise it is inherently going to have external components that are not in your control, which was an issue Pressgram was advertised as solving.

      I look forward to George’s post on the TOS and general philosophy. :)

  8. Since I don’t have an iPhone, I don’t have any real skin in this debate. but simply from an outsider point of view, adding the social layer makes it an Instagram clone, not something truly different. I already have a script on my WP site that pulls in my photos and stores them locally on a schedule, so if Instagram shut down tomorrow or made their service otherwise unacceptable to me, I’d be fine.

    The TOS part is a bigger issue to me. the terms basically mirror IG, so where’s the true “freedom” it advertised? yes, they say they aren’t going to sell them, reuse, etc but words don’t mean shit. Especially considering the owner has made radical decisions in the past with little advanced notice (i.e. WPDaily and Standard) so I’d be less likely to take that statement at face value. You’re good people, John, but that’s the reputation you’ve made for yourself with recent events.

    As for the plain text passwords? That’s just sloppy.

    1. appreciate the candor here andrew (and the coffee… it makes me wonky thinking about it).

      there’s no denying it – lots of work to be done to make this a great product. i wish i could deliver the perfect app that’s universally lauded but it’s not possible (as no app can do – i feel in good company). but… i’m going to do my best.

      thanks buddy.

      1. indeed, I can’t imagine what’s involved with getting something of this scale out the door. and I’ve released sloppy code, I can’t find a developer who has. And please don’t take this as an attack on you as a person, because it isn’t.

        But coding and tech issues aside, I’m still concerned about the TOS issues. Is there an explanation about why the terms are granting Pressgram license?

      2. John, open source this project and you’ll get the benefits of all these highly skilled people who have supported this project from the get go. Why do it all yourself?

        1. John seems willing to consider open sourcing it eventually, my understanding was for the initial buildout, he just didn’t want to spend a lot of time curating bug reports that he’s already got on his list, or wrangling feature requests. The initial buildout I can understand wanting to keep the code private for.

          I’d love to see it open sourced as well going forward, but I understand why he didn’t initially.

          1. I brought it up as a potential solution to this problem John stated “i wish i could deliver the perfect app that’s universally lauded but it’s not possible (as no app can do – i feel in good company).”

            My point is that now that the app is released and is closed sourced, John still has to do all the work himself. If he open sourced it he’d have a whole community to help him to turn the app into what he promised.

          2. I agree a team can do the hard work of forking the existing WordPress app, developing some Creative Commons filters and … Voila!

            Since the iOS WordPress app has the security functions already, and has the secure XMLRPC core code already, the work would be more about adding the photo filters.

            Seems to me this is a way forward that addresses the “short comings” outlined here.

            I don’t expect this will be easy but it’s doable. As for the social community part of it, see what Pixter has done using app.net.

            http://pixter.in/mobile.html

            If Pressgram were to tie into that would that address the other concerns?

          3. Pressgram is not open source. The official WordPress mobile apps all are — but they’re also overly complicated from a UI standpoint and don’t bundle the filters.

            In the end, it’s John’s decision whether to open source the Pressgram code or not. Not really sure what you’re getting at.

          4. From what I understand contributions to the iOS app are welcome. I would imagine if someone forked it, built photo filters into it and submitted a pull request it’d have a good chance of inclusion.

            Maybe someone should spearhead kickstarter’ing that effort. I’d certainly chip in more than I did for PressGram.

          5. The only difference between what most of us want and the WordPress iOS app is filters. This seems to be a pretty straight forward thing to add, no? Probably in the works somewhere.

          6. FWIW, iOS 7’s camera app includes filters, but AFAIK it’s no where near as flexible at Instagram/Pressgram (no blur/shadow highlight)

  9. It’s XML-RPC, so there’s not much better that things can get there as is, but I was thinking about installing this app for my own use this weekend. Will have to wait until these thing are addressed a bit more.

    1. XML-RPC would be fine, just so long as the password isn’t stored on someone elses servers.

      It’s a bit like WordPress.com storing all passwords in cleartext when using the official WordPress mobile apps for Android and iPhone. They don’t do that of course, because that would be unethical.

  10. The concept of having an app on my phone directly send photos to my WordPress site was something i was REALLY looking forward to. Granted, the WordPress app can do it in a similar way, but I think the experience could definitely be improved upon. The “server in the middle” thing bothers me a great deal though – mainly for the reasons already presented here.

    I don’t have a big problem with Instagram. I know some people practice the “my own data” as a religion, but as long as you know what you’re getting into with Instagram and other services then I think that’s fine.

    I would love to see more interaction between WordPress sites and mobile devices/apps/existing networks. When WPArmchair pulled 1000 photos from Twitter and Instagram (wcsf.wparmchair.com) I thought that was cool… i was hoping to add PressGram into the mix somehow. It’ll be interesting to see how this moves forward. I think John should be given some credit for what’s been currently done – because none of this is easy – and I’m confident things can be cleared up. Looking forward to using PressGram in the future.

Comments are closed.