2

After I completed Account Setup Assistant process for a new SiteGround hosting service, I got this confirmation screen on the website:

... just log in to your Wordpress control panel with the details below:
Admin URL: XXX
Username: XXX
Password: XXX

In place of XXX, there were actually my username and password in plain text.

This was delivered in a new page over HTTPS; the HTML of the page contained:

<p><span class="bold">Username:</span> XXX</p>
<p><span class="bold">Password:</span> XXX</p>

From that I conclude that they don't use client-side password hashing. I was surprised; I thought it was normal industry practice for sensitive services. Is it not the case?

Apart from the above, is there any security issue with displaying password back to me in plain text? (I assume they don't actually save it in plain text in a database - that would be atrocious; presumably, it only stays in memory of their web server, while it's preparing the response to my POST request; I hope it is hashed/salted before being saved in any persistent storage).

Note: they did NOT include plain text password in the email confirmation; only on a single web page that is only available right after I signed up.

Improve this question
2
  • 1
    is "client-side password hashing" a thing?
    – dandavis
    Mar 25, 2017 at 23:22
  • The only issue here is shoulder surfing. That could be solved by having a "view password" button you have to click to actually get to see it. Not having that is a bit lazy...
    – Anders
    Mar 27, 2017 at 7:45

1 Answer 1

Reset to default
5

Yes, there are definitely some issues:

  • Shoulder surfing: There is a reason that password fields use stars. It's so that people who are nearby cannot see the password. Showing the password in plaintext on the screen obviously defeats this, and this is really the main downside of this approach.
  • Caching: The response may be cached by the browser. Setting appropriate headers can mitigate this.
  • It lowers the perceived security of the site, which isn't good. It may also have a negative psychological effect (if the site isn't careful with the password, why should the user be?).

they don't use client-side password hashing. I was surprised; I thought it was normal industry practice for sensitive services. Is it not the case?

No, client-side hashing is not standard, mainly because it doesn't add much.

The password should already be protected in transport via HTTPS (and hashing wouldn't secure transport anyways).

It may seem that client-side hashing could turn a weak password into a strong password (eg password -> 5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8), but any attacker would just need to take the client hashing into account and chain client- and server-hashing when cracking the password.

Improve this answer
2
  • I thought client-side hashing provides the extra protection in case web server itself (or a CDN it uses) is compromised and the attacker can actually listen in to the incoming traffic. In that case, the attacker can of course access the user's account on the compromised web server, but at least he wouldn't be able to access the user's gmail and all other services where the user reuses the same password.
    – max
    Mar 25, 2017 at 23:42
  • 1
    @max If the attacker has control over the server or a CDN, they could just inject javascript into the response and log the original password that way. If the attacker has only read access, then client-site hashing would indeed add something. But the benefit is small (an attacker can still crack the hash they can read), and the scenario seems a bit unlikely (though not impossible; a server that logs POST requests might be an example).
    – tim
    Mar 25, 2017 at 23:48

You must log in to answer this question.

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