1

I’m framing this question vis-a-vi Automatic and Jetpack, but I think it’s about something I don’t personally understand that is happening in a WordPress context, so I’m posting here. It’s not about Automatic though, this could be any general case. So bear with me...

My hypothesis is that Automatic / Jetpack has an inhearently insecure auth system, so I expect someone here to tell me what I don’t understand, assuming I’m wrong.

There are Auth / Signon plugins for many sites to use a particular network’s auth creds to login to another one. For instance, you can login to bitbucket.org with your google.com credentials like this: enter image description here

When you click the signon button, you get redirected by a modal to google.com, where you enter your password. Then google authorizes your login to the client site, WITHOUT EVER GIVING YOUR PASSWORD TO THE CLIENT SITE. In other words, when I login like this, bitbucket.org has no way to actually get my password unless my browser or the network has been compromised somehow. Many sites have this, facebook, yahoo, AOL etc. enter image description here Contrast to this login technique which I noticed on sites like digest.bps.org.uk jetpack.com

Which I understand to be fully qualified domains hosted by automatic, or at least sites using the jetpack product. I don't use either so I'm not sure...

When I try to make a comment on jetpack.com, I am prompted for my WordPress.com password FROM THE JETPACK.COM domain. I'm not re-directed to wordpress.com or gravatar.com . Yet, I am logged in if the password is correct. enter image description here enter image description here My understanding of these auth systems used is that the SSL cert being green, is the method by which the user can confirm that the site they are dealing with can be trusted, as long as the domain is confirmed. You can log in to bitbucket.org with your google.com creds, because when you are asked for them, the browser says "google.com" at the top, not some random site. What is to stop me from setting up blogs all day on random domains, ask for wordpress.com creds, automatically check them, and then signon the user if the creds are good, and then steal them myself? Please explain to me why this isn't a massive security flaw?

  • What prevents you from doing that for any site anywhere using any form of authentication? Nothing (ish). – Steve Aug 30 '17 at 16:23
  • No. The concept of SSL prevents that. In the login with bitbucket / google example, when you are prompted to enter your google password, the URL in the browser, which is SSL secured, is "google.com". This is the standard practice. You can only spoof the SSL remotely if the browser or network has been hacked. In the Jetpack examples, the URL in the browser is ANY URL. In other words, you enter your Google password when thte SSL says "google", you enter your WordPress.com password when.... what? Compare the 2nd and 4th images and their URLs. – Jim Maguire Aug 30 '17 at 17:12
  • 1
    In other words, google will tell you, "Never tell a thrid party your Google.com password. You should only enter your google.com password when the browers says 'Secure' and the URL is google.com". Jetpack is saying, "You can reveal your WordPress / Gravatar password to anyone who asks for it, and you can trust them because ..... " This is the risk. Getting an SSL itself isn't proof of identity, just encrption. How can the user trust the site asking for their Gravatar password? Because their Gravatar image has been revealed? That doesn't make sense. – Jim Maguire Aug 30 '17 at 17:19
  • 1
    So in the example above, when you enter your google password, the modal [which has the URL google.com] pops up and you send your encrypted password TO GOOGLE, NOT BITBUCKET. Google then subsequently send a login cookie to bitbucket. Bitbucket NEVER sees your password. That's the point of cross site logins. However, in Automatic's case, the client site DOES get the password. It's very different. Compare the red circles in the 2nd and 4th picture. – Jim Maguire Aug 31 '17 at 1:06
  • 2
    My point was that the certificate and the domain are generally not checked when a user enters creds, so it's easy to phish. That said, of course its bad to share creds across sites. In your scenario though, the sites are owned by the same company, so its not across parties. It would be better to centralize on the one site and do SSO. – Steve Aug 31 '17 at 12:50
2

(Disclaimer: I work for Automattic)

The OP is right to be concerned, because there is something wrong here. But, it's not nearly as bad as it appears on the surface.

WordPress.com is a WordPress Multisite network, so digest.bps.org.uk is not a separate site from wordpress.com, it's just an alias. It's the exact same server/codebase/database serving both sites. Once the application receives the request, it determines which content/theme/etc to show based on the hostname.

So, when you submit your credentials into digest.bps.org.uk, they are going to wordpress.com, because digest.bps.org.uk is wordpress.com. Individual site owners do not have access to the code/servers/database, though, so they can't see the credentials that were entered.

The actual problem here is that it trains users to enter their credentials on what appears to be a different site, which would be dangerous in most situations. Fixing that is on our roadmap.

We make mistakes, but we do care deeply about security and privacy. If you come across anything else that seems wrong in the future, we'd love to hear about it privately first, so that we can have a chance to fix it before people with malicious intent learn about it. Our website describes the process for security disclosures.

1

If the domain is hosted by Wordpress, then there is no 'cross domain'; the commenting system is controlled by Wordpress. The domain never sees the credentials.

Can you create a page/widget to collect creds from unwary users? Sure, but that's nothing new or noteworthy.

  • I'm not talking about a wordpress.com subdomain, I'm talking about a fully qualified domain like "digest.bps.org.uk". It might be hosted by the company Automatic, but the domain does not contain "wordpress". – Jim Maguire Aug 31 '17 at 20:56
  • Of couse it's not new, that's my point! This is something that other companies have dealt with like 20 years ago. Can you show me another case on the internet, where I log into a client site using network auth, where I am NOT redirected to the authority site in a modal to login? For instance, when I try to log in to gmail.com with my google.com credentials, a modal pops up that takes me to the subdomain "accounts.GOOGLE.com" in the root URL of the dom. When I log into bitbucket.org using my facebook.com credentials, a modal pops up where the base url is FACEBOOK.COM, not BITBUCKET.ORG. – Jim Maguire Aug 31 '17 at 21:01
  • In this case, when I log in to "digest.bps.org.uk", the base URL of the dom of the login modal is "digest.bps.org.uk", NOT "wordpress.com". This is different from every other use case. Am I insane? – Jim Maguire Aug 31 '17 at 21:02
  • i.e. this site. If you log out, and then click the "login with facebook" button, you are re-directed to facebook.com. stackexchange.com never directly asks for your facebook password. – Jim Maguire Aug 31 '17 at 21:06
  • 2
    But I would side-step all the speculation and judgements and critiques by rephrasing your question to: "is it better to disclose the domain of the authenticating source so people can check it when they log in?" to which the answer is "sure", but you already know this (you have stated as much). And from this perspective, I have no idea what you are asking except to gather support for your condemnation of this method of authentication. – schroeder Sep 1 '17 at 9:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.