Hacker News Reader

Comment by icebraining | Hacker News Reader

If you're the client, you need to store the password in a way such that you can send it to the SMTP server. Storing it in any other way than plain text is just security theater, because if WP can read it to send the emails, so can the attacker who takes over WP.

https://developer.pidgin.im/wiki/PlainTextPasswords

The only way to secure this is at the email server itself, by limiting the permissions of those credentials; for example, the IMAP/POP server could have a filter to save the bounces to a specific folder, and then allow access to only that folder for those credentials.

View on HN

Ah that's the obvious detail I was looking for. I guess my other question would be...is there any reason why a front-end site like WordPress has to have mailing functionality built-in? I mean I know WP is more than just a blogging platform...but...I'm trying to think of a situation in which a company has so many clients and client interactions that it's just convenient to bake email functionality into the homepage/news site...but that it's apparently not worth the effort to invest in a proper CRM? I know they're a law firm and not a tech company and CMS architecture is not their specialty, but they're not also running a site to manage the church bake sale. What kind of IT people could such a wealthy firm hire that wouldn't have enough experience to worry about this kind of thing?

A CMS would need to send email so that it can reset passwords, just as an example. Again, as the parent has said, the failing here is not that the CMS is provided with email credentials - that's very common for all but the simplest CMS, but that it didn't separate and limit the accounts properly

Right, but...in this specific situation, their WordPress homepage doesn't appear to be the client-serving portal...That's what Drupal is for:

https://portal.mossfon.com/

Drupal was apparently where the CRM was handled, including the posting of documents and so forth. The use-case you mention seems to be something that should be handled by the Drupal site.

Though I guess this speculation is just moot. The severity of the Drupal flaw would seemingly allow access to whatever Drupal uses to talk to the email server. That the WordPress server used the same email server and had the same access is just coincidence, another example of careless IT by MF, not that MF was necessarily using WordPress as a client-serving site.

The Wordpress blog editors would need to reset their own password occasionally.

libpurple2, surprisingly, gets that incorrect. The correct thing to do is use the OS-provided mechanisms. On Windows, that's CryptProtectData. That way the data, at rest, is inaccessible to anyone without the user's password.

But this doesn't apply to server applications like SMTP. I guess with SGX + some trusted storage, you could work it to only release the password to a known-encrypted socket or something.

Well, the blog post presupposes you can get remote code execution on the WordPress server. There's very little you can do to secure yourself if the opponent already has RCE, because at that point the attacker has at least as much privilege as the application itself. In that case you have to fall back on limiting the amount of damage that can be done by respecting the principle of least privilege.

Ideally you could have a send only password. I know gmail has app specific passwords but unfortunately they don't seem to have specific permissions

Reply on news.ycombinator.com