3

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?

Improve this question
9
  • What prevents you from doing that for any site anywhere using any form of authentication? Nothing (ish).
    – Steve
    Aug 30, 2017 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, 2017 at 17:12
  • 2
    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, 2017 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, 2017 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, 2017 at 12:50

2 Answers 2

Reset to default
3

(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.

Improve this answer
1
  • 1
    Note that the visitor cannot know that digest.bps.org.uk points to wordpress.com without specifically checking for that fact using DNS. In addition, the fact that it points to wordpress today is not proof about it pointing to wordpress in the future, too.
    – Mikko Rantalainen
    May 26, 2021 at 15:37
2

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.

Improve this answer
11
  • 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, 2017 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, 2017 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, 2017 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, 2017 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, 2017 at 9:02

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .