1

I host a mail server (postfix and dovecot) and I wish to set up a password change feature (especially useful when creating a new address provided with a temporary password).

Does my scenario has security vulnerabilities?

usage:

from their email address, user send an email with the subject "password" and containing in the body the new password in clear to a special address that run a script.
This script read the new password in the mail content and change the user's password.

context:

  • Only the addresses of the domains managed by the mail server can send an email to this special address
  • SMTP and IMAP connection using TLS only
  • Mail are delivered locally to the domain and do not pass through an intermediate SMTP
  • After the change password, the script delete the sent email in the mail sent folder of the user account

EDIT:

  • the SMTP server accept only authenticated user
  • my script check the value of sasl_username provided by postfix

EDIT 2:

I hear that this is a bad practice. This technique was experimental purpose and test, but I wanted to check if there was no security hole (omitting the user side).

For the production I certainly will use a password change request with a temporary token to an https web form that passes variables in my script.

Improve this question
2
  • 1
    Sidenote: even if your script deletes the sent email, it might still persist in the user's email app. Additionally, it's a Bad Idea to teach your users it's ok to email passwords anywhere.
    – Joel L
    Dec 29, 2014 at 12:05
  • Question for someone smarter than me - Does the fact he is using SMTP and IMAP connection using TLS only make it so that emails could not be sniffed in transit?
    – Abe Miessler
    Dec 30, 2014 at 0:57

1 Answer 1

Reset to default
3

Is your script checking sasl_username in the headers or elsewhere?... if it's from the headers you may have issues with tampering: https://serverfault.com/a/404885/146906

Overall this sounds to be frank, very fragile at best. You're relying on a great many potential entrypoints remaining closed for this to continue working - were any of them to change - say someone messing up a mail config and allowing external mail in, the whole thing fails.

I have a very hard time believing passwords have any place being in an email, ever... they have properties which mean they should almost always not mix. Even if a specific case is probably safe, it will be negatively educating users that the behaviour is sometimes ok, when it's usually extremely dangerous, even more so when it's being used like this to reset passwords.

Please do not do this.

Improve this answer
2
  • 2
    Exactly — regardless of any technical details, the worst part is telling your users to "email their password" — this should never ever be done, no matter the specifics of this scenario.
    – Joel L
    Dec 29, 2014 at 12:06
  • sasl_user is not obtained from the header but provided by postifx transfert pipe
    – Nigel
    Dec 30, 2014 at 14:04

You must log in to answer this question.

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