Hi - Jonathan Lampe, original research author here.

Round 1 of my research was about the "top five candidates" and Rand Paul wasn't included. Round 2 was about candidates that ran WordPress, which covered Bush and Sanders from Round 1 again and picked up about a dozen more candidates, but still didn't include Rand Paul. I hope to circle back around to Paul, Cruz, Rubio, Fiorina and anyone else I missed (Christie?) soon in a "not top five, not running WordPress" third round of research soon.

My initial take? Could be an A or a B. Paul has a site developed by CanDo.com in 2014, and appears to have been doing business with them since at least 2012. The most interesting thing on his home page is the "recent donor" display (which is phoning home for data) powered by /js/moneybomb-inner.js. (If I had more time, I'd play with that to see if I could get it to cough up more information.) His JQuery seems to be up to date and he's running PHP on the server. (Again, with more time, I'd dig in further.) Paul uses a separate site, also written by CanDo.com, for donations (https://secure.randpaul.com/). The most interesting information in there seems to be some leftover code about "tickets" that's hidden from end users. (If I had more time, I might look for interesting overposting behavior there.)

>> if Dr. Lessig was downgraded on purpose because he is actively opposing [something]

Hi - Jonathan Lampe, original research author here.

To be honest I'd never even heard of Lessig until his name appeared on the list of "presidential candidates running WordPress" I borrowed from Bryan Quigley. I didn't spend any time researching the positions of Lessig or any of the other candidates; I just looked at their tech.

(Pulls up spreadsheet with grading criteria.) It looks like I marked Lessig as the candidate with the least secure site because his WordPress site had the most problems: an out-of-date and vulnerable WordPress version, a username enumeration issue (which revealed 14 usernames), a default "admin" account, exposure of internal directory paths and an unprotected sign on page.

Jonathan Lampe (research author) again. These are good questions.

>> Isn't Shopify a large an complex web application.

Yes, like Hillary's site, Shopify is large and complex.

>> Has anyone done a security audit on shopify or reviewed its source code?

At the risk of sounding like a shill, I feel better about Shopify's security than Hillary's because:
1) Shopify has a process to contact them about vulnerabilities (https://www.shopify.com/security-response) - Hillary didn't respond to my inquiry
2) Shopify has a history of engaging with the security community and responding to complaints (https://hackerone.com/shopify) - Hillary doesn't have this
3) Shopify has taken the time to become PCI-DSS compliant (https://www.shopify.com/pci-compliant) - Hillary doesn't have this
4) Hillary's dev team is advertising a "shipped before perfect" (not exact phase) attitude and is still hiring security people to catch up with her fast-moving team - Shopify's been around a few years and, while they could also be moving fast, has hammered out well over a hundred security bugs in a more mature codebase

Hi - I'm Jonathan Lampe, the author of the original research.

>> they stated it had no store. What thu heck is this: http://store.bencarson.com/

That's new to me; I did the research a full month ago and there was no store on Carson's page then.

A quick look at Carson's store shows he's using a skinned instance of Shopify. Security-wise, I still think Carson's approach (brand a white-labeled version of an established ecommerce store) is a wise choice vs. the approach that some campaigns seem to have made (where they develop their own ecommerce site).

Hi, I'm Jonathan Lampe, the author of the original research.

>> if you don't expose usernames, how do readers track to whom each comment in the comment section belongs? And if you don't expose a login page, how do posters track which of their comments have been replied to, and how do users manage their subscriptions to various newsletters?

NONE of the presidential campaigns were using any any self-registration or comment features of WordPress. (You'll see "registration" as a column in my WordPress report.) All of the users on all of the systems seemed to be admins, editors or their assistants, and none of the sites seemed to make any effort to distinguish one author from another. With that in mind, there really is no good reason for these sites to expose the list of usernames available on the system, nor is there a particularly good reason to permit the entire Internet to try their hand brute forcing sign-ons again a list of known usernames.

Hi, I'm Jonathan Lampe, the author of the original article.

>> If you want to know how a candidate handles security, follow how they handle money

I started my research after I noticed that most of these sites DO handle money, either through merchandise stores or donations. My original report (http://www2.infosecinstitute.com/l/12882/2015-10-19/zbwt6/12882/121089/2016_Presidential_Hacks.pdf) dug into how the top five candidates handle money on their web sites; it looks like most of the links in this thread are reading my SECOND bit of research about who's using WordPress and how badly it's been configured (http://resources.infosecinstitute.com/doesnt-any-presidential-candidate-know-how-to-secure-wordpress/).

Yes, SSL 3.0 and TLS 1.0 are both affected. And yes, we'll be waiting on fixed from just about everyone. (Or, everyone may just move to TLS v1.1 - that's safe too.)

Here's a page that's tracking this for file transfer applications that includes a nice discussion of general purpose web servers and browsers and their current "support of TLS v1.1" status at the end: http://www.filetransferconsulting.com/file-transferbeast-tls-vulnerability/

If this case is successful, I would think that many "managed file transfer" vendors and "WAN optimization" vendors might find themselves served next. In these industries, it is quite common to "serve up media files" using a file system, an optimized protocol and a separate database full of file information.

Here's a little more background on the various generations of the FTP protocol.

First Generation (1971-1980)

The original specification for FTP (RFC 114) was published in 1971 by Abhay Bhushan of MIT. This standard introduced down many concepts and conventions that survive to this day including: ASCII vs. "binary" transfers, Username authentication (passwords were "elaborate" and "not suggested" at this stage) , "Retrieve", "Store", "Append", "Delete" and "Rename" commands, Partial and resumable file transfer , A protocol "designed to be extendable", Two separate channels: one for "control information", the other for "data", and Unresolved character translation and blocking factor issues

Second Generation (1980-1997)

The second generation of FTP (RFC 765) was rolled out in 1980 by Jon Postel of ITI. This standard retired RFC 114 and introduced more concepts and conventions that survive to this day, including: A formal architecture for separate client/server functions and two separate channels, Site-to-site transfers, Passive (a.k.a. "firewall friendly") transfer mode and The 3-digits-followed-by-text command response convention. ...and RFC 765 was replaced by RFC 959 (which formalized directory navigation) in 1985.

Third Generation (1997-current)

The third and current generation of FTP was a reaction to two technologies that RFC 959 did not address: SSL/TLS and IPv6.

Most FTP software now conforms to RFC 2228 for FTPS. Oddly enough, there are still a LOT of file transfer packages that still don't have IPv6 or EPSV support. The RFCs beyond IPv6 and EPSV support are pretty well baked, so if you're still dealing with a vendor without those attributes, consider that a big red flag.

Also keep an eye on draft-ietf-ftpext2-hash and draft-peterson-streamlined-ftp-command-extensions - that's where the action is in FTP today.